Connection, Routes and Subscriptions
Complete Troubleshooting Guide

“Cannot connect at all” is not a single failure mode. The client may lack system network permission, may be connecting without completing the route handshake, or the current underlying network may be unable to reach the subscription service. The first step is not reinstalling; observe where the client stops. If it immediately returns to disconnected after you click Connect, permissions, configuration, or client state are likely involved. If it stays on Connecting for a long time, the route may be unreachable, the network switch may be incomplete, or the configuration may be invalid. If it shows Connected but no traffic passes, move to the next chapter and check website access and DNS.

Establish a repeatable baseline test

Temporarily disconnect the accelerated connection and confirm that the underlying network can open an ordinary website. This tests the local network itself, not international sites. If a basic website will not load either, address the router, public-network sign-in page, system network switch, or upstream network issue first. Public networks often require confirmation in a browser. If the confirmation page does not appear, disconnect and rejoin the network, then open an ordinary website to trigger it. Once the underlying network is working, return to the client and test the same route.

After confirming the underlying network is working, close and reopen the client. Check that the subscription exists, the route list is visible, and the system shows any network-permission request. After first use or a system-permission change, the client may need permission again to establish a network connection. If the request was denied, do not keep clicking Connect. Open system settings and check the client’s network extension, VPN configuration, or background permissions. Names differ by platform, but the test is the same: the client must be able to create a system-level network tunnel, not merely show a switch in its own interface.

When switching routes, change the path—not just the click

When a route fails, switch from the current route to another region or route type. a4VPN covers 90+ countries / 200+ routes, and the locations page identifies regions and route types. For troubleshooting, consult the server and route list, prioritizing a geographically reasonable route suited to the task. Clicking the same route repeatedly only repeats the same conditions; it cannot show whether the client or underlying network is working. If routes in several regions all fail but another underlying network works, the original network environment is more likely at fault. If different networks all fail, continue checking the subscription and client configuration.

When switching the underlying network, actively disconnect the client first. Wait until the system confirms the network has changed, then reconnect. If the tunnel remains active during the switch, the old connection may continue using an invalid interface, appearing connected while carrying no data. Switching routes alone may not help; disconnect fully, quit the client, and reopen it. The same sequence can help after system sleep or extended standby. Do not immediately delete the entire configuration.

Decide whether to re-import

If the route list is empty, route names look wrong, or all routes fail at once, retrieve the subscription again from the user panel and run an update. Only when the update clearly fails should you move to the subscription-update chapter. If the update succeeds but connections still fail, create a separate configuration for testing and keep the old one for comparison. This lets you compare results without deleting potentially useful evidence. After re-importing, confirm that the client selected the new configuration rather than continuing to use a route with the same name from the old one.

Reinstalling the client should be a late-stage step. It removes logs, permission state, and clues from the old configuration; the issue may disappear temporarily while the evidence is lost. Consider it only when the client will not start, the interface remains broken, configurations cannot be saved, or system-permission entries are damaged. First export non-sensitive diagnostic information, then uninstall and obtain the client from the user panel. Always obtain subscription content through the panel; do not mix unknown-source configurations into the same client.

A Connected status only means that the system has established some kind of network tunnel. It does not confirm that domain resolution, browser requests, or app routing are working. Start by answering two questions: can no websites open, or only a particular site? When a domain fails, does direct access to a known network resource fail too? The first question shows the scope; the second helps distinguish DNS from the data tunnel. Do not treat “connected” as the end of troubleshooting, and do not replace the account as soon as a webpage shows an error.

Rule out the browser first

Open the same page in a private window or compare with another browser. If the private window works, the cause is usually cached data, stale cookies, browser extensions, or the browser’s own Secure DNS setting. Disable extensions that rewrite network requests, then clear the target site’s cache and site data. There is no need to erase all browsing history: a full cleanup affects signed-in sites and provides no clearer diagnosis. If one browser fails while other applications work, focus on that browser rather than changing the system-wide proxy mode.

Some browsers use their own DNS-resolution policy, which may differ from the system DNS managed by the client. During troubleshooting, temporarily disable the browser’s independent Secure DNS so it follows system settings, then restore it afterward if needed. If the browser reports a certificate time error, check the system date and time zone first. A clock mismatch can break secure-connection validation; it is unrelated to route speed, and switching regions will not fix it.

Determine whether DNS or the tunnel is failing

When the error says “server not found,” “address could not be resolved,” or something similar, focus on DNS. On Windows, you can run the cache-flush command in a terminal; macOS and Linux also provide ways to refresh the system resolution cache. These commands clear only the local cache and do not change the subscription or account.

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux:
resolvectl flush-caches

After running the command, disconnect the client, reconnect, and test again. If the system says the command is unavailable, do not copy replacement scripts from unknown sources. Linux environments use different resolution services, so first check the current DNS source in network settings or restart the relevant network connection. If clearing the cache works but the issue quickly returns, the cache was only a symptom. Continue by checking the client’s DNS mode, whether another application rewrote the system proxy, and whether the local network is forcing an unusable resolution result.

Check the system proxy and routing mode

If all domains resolve but webpage requests wait indefinitely, check whether the client is using global mode, rule mode, or proxying only selected applications. In rule mode, the target domain may be classified as direct. Global mode can serve as a short comparison test to confirm whether the rules are involved, but it is not recommended as a long-term solution for every situation. If the page works in global mode, update the rules or check the target domain’s routing result instead of continuing to clear DNS.

A system proxy may retain an old address after the client exits abnormally. Typically, the client is closed but the browser still cannot connect. Reopening the client and disconnecting normally can sometimes restore the system settings. You can also open the system network-proxy page and confirm that it does not point to a nonexistent local proxy port. Check only for leftovers; do not enter server addresses found online at random. Some applications do not read the system proxy and accept only a system-level network tunnel. A working browser therefore does not prove that every application will work; move to the app-routing chapter for those cases.

How to assess a failure limited to one website

If most websites work but the target site does not, first switch to another route in the same region, then compare with a different region. The destination service may respond differently based on egress region, account region, cache state, or access frequency. A message saying the region is unavailable does not mean the tunnel is broken; persistent loading or a connection timeout points more toward the route path. Check the server page for route types, then choose a region suited to the destination.

If the target website works in a browser but not in its app, the issue is likely app routing or app cache. If the same target fails on every device using the same route while other websites work, record the target domain, route name, and time, then submit a ticket for the route to be checked. Do not write only “the website will not open”; support cannot tell whether all sites, one domain, the browser, or DNS is involved.

The full path for international access includes the local device, local network, underlying network, entry route, cross-border link, egress region, and destination service. Slowness can occur anywhere along that path, so a single speed test cannot represent route quality. A better method is to keep the test target fixed while changing the route, underlying network, and application scenario one at a time. Peak-hour lag also needs to be separated into sustained low speed, brief jitter, video buffering, and choppy calls, because each points to a different bottleneck.

Define exactly what “slow” means

A slow first page load is usually more affected by latency, DNS, and small-file requests. A low large-file download rate points more toward sustained throughput. Frequent video quality drops may reflect route fluctuation, the platform’s regional behavior, or player caching. Choppy meeting audio calls for attention to packet loss and jitter, not just peak bandwidth. Writing only “the internet is slow” can lead to the wrong route choice. Records should name the application, action, and result—for example, slow initial page load, video buffering, unstable file transfers, or intermittent meeting audio.

Disconnect the accelerated connection first and confirm that the local underlying network has no obvious problem. If the underlying network is already handling heavy downloads, cloud syncing, system updates, or sustained traffic from other devices, every route will be affected. Pause those tasks before testing again. On Wi-Fi, check that the signal is stable at the current location. Distance from the access point, multiple walls, or substantial interference should be addressed before judging an international route.

Compare routes instead of speed-testing blindly

Choose a geographically close route as the baseline, test another route in the same region, then compare with a region where the target service is located. Disconnect the old route before every switch, wait for the new connection to complete, and reopen the test page. Cached video segments or download connections may continue using the old tunnel, so start a new request after switching. If routes in the same region differ clearly, route selection can improve results. If every region is slow while the underlying network works, check the client mode, system resource usage, and duplicate proxies.

IEPL dedicated routes, relay routes, and direct routes use different path designs; none is guaranteed to be fastest in every situation. Dedicated routes focus on organizing the cross-border link, relays adjust the path through entry and exit points, and direct routes depend more on the public route from the underlying network to the destination region. Choose based on the use case and current performance. See the route list for available types, and keep stable alternatives rather than relying on one route permanently.

Record time and path during peak hours

If performance is normal during the day but clearly degrades at a regular evening time, test a backup route while the problem is happening instead of comparing after it has passed. Record the underlying network type, current region, route name, affected application, and what changed after switching. If one route remains unstable during peak hours, use a backup in the same region first. If the whole region is affected, try another entry path or a nearby region. This helps distinguish single-route congestion, regional path changes, and peak-hour fluctuations in the local underlying network.

Do not draw a long-term conclusion from one smooth session or one laggy session. The destination service may also adjust distribution nodes during busy periods, while streaming quality can depend on account region, the player, and caching policy. More useful records capture consistent results across several operations in the same scenario; no elaborate score is needed. It is enough to state which route, which application, what happened, and whether switching changed it.

Check device resources and duplicate tunnels

Running the client alongside another network tool can create duplicate proxies, route contention, or DNS-control conflicts. When troubleshooting speed, close other tools that rewrite system networking and keep only the current client. Power-saving mode, sustained disk activity, or high processor usage can also disrupt encryption and forwarding. Pause unnecessary synchronization and background updates, then see whether the connection becomes stable.

a4VPN supports unlimited devices, but multiple devices performing high-volume tasks on the same network still share the local access capacity. Unlimited devices describes the permitted device scope; it does not expand local bandwidth automatically. If pausing downloads on other devices restores speed, investigate local traffic allocation rather than treating it as an account device limit. If every device shows the same issue on the same route at the same time, organize the route records and submit a ticket.

For frequent disconnects, first distinguish a true tunnel drop from an application temporarily losing network access. If the client returns to disconnected and the system status icon disappears, the connection layer dropped. If it still shows Connected but webpages stop responding, the route may have stopped responding, the network interface may be changing, or DNS may not have refreshed. If transmission stops only after the app goes into the background, system background and power-saving policies are more likely. These symptoms require different fixes and should not all be blamed on the route.

Observe what triggers the disconnect

Record what happened before the disconnect. Common triggers include switching between networks, briefly leaving Wi-Fi coverage, waking from sleep, remaining locked without foreground activity, or the system reclaiming the client. If every network switch causes a drop, the old tunnel is not migrating cleanly to the new interface. Disconnect first, confirm the new network works, then reconnect. If the client offers on-demand connection or reconnect-on-network-change, enable it only after the basic setup is confirmed. Automatic reconnection should not hide an underlying network problem.

If the connection drops even while the device is idle, test different routes separately. If only one route fails, switch to a backup in the same region. If all routes fail, check fluctuations in the underlying network, sleep policies, and conflicts with other networking software. If another underlying network is stable, inspect the original network more closely. If both networks drop and the client logs show similar errors, then consider client configuration or system permissions.

Background policies and power-saving limits

Mobile operating systems restrict app activity based on battery level, temperature, background use, and long-term behavior. If background activity is blocked or the client is under an aggressive power-saving policy, the connection may be reclaimed after the screen locks. In system settings, allow the client to run in the background and check battery optimization, low-power mode, and background network permissions. Menu names vary, so the goal is to confirm that the client can maintain the system network tunnel with the screen off, not to find one exact menu label.

Do not add the client to an unknown “keep-alive” tool. Extra background utilities consume resources and may conflict with system network management. Prefer system-provided background permissions and the client’s built-in on-demand connection feature. If drops begin after a system upgrade, review permissions again because some network-extension authorizations may need confirmation. Preserve subscription information before reauthorizing so you do not delete configuration at the same time.

Desktop sleep, hibernation, and network recovery

Windows, macOS, and Linux reinitialize network interfaces after sleep. The client may retain an old status even though the original tunnel is unusable. After waking, wait for the underlying network to return, try a normal disconnect, and reconnect. If the disconnect button does nothing, quit and reopen the client. Force-quitting processes repeatedly can leave system-proxy state behind, so after reopening, complete one normal connect-and-disconnect cycle before judging whether ordinary networking has recovered.

If the client must be restarted after every wake, check whether the system allows it to start at login and whether it can reconnect after network changes. Do not start multiple clients automatically; they may compete for the system proxy and routes. During troubleshooting, let only one client start automatically and run other network tools manually. On Linux desktops, also confirm that the graphical network manager and command-line network service are not managing the same interface twice.

Repeated reconnects without a complete drop

Logs may repeatedly show reconnects while the user notices only brief page pauses. This usually means the route heartbeat stopped responding, the underlying network had brief jitter, or the system switched between network interfaces. Peak speed may still look normal, so check for interruptions in meetings, real-time collaboration, or sustained downloads. Disable unused network interfaces to reduce automatic route changes—for example, temporarily turn off the Wi-Fi or wired connection you do not need—then test again.

If the issue occurs only on a particular public network, that network may restrict long-lived connections or reclaim idle sessions. Keep normal foreground activity and test different routes, but do not change low-level parameters whose meaning is unclear. If the same drops occur at home or work, record log times, network changes, and route names. A reproducible trigger is more useful for diagnosis than “it disconnects often.”

When to rebuild the system configuration

If the client’s connection status consistently disagrees with the system status, or the permissions page contains duplicate or invalid network configurations, quit the client first. Remove only configurations clearly belonging to the old client, then authorize the current client again. Before doing so, make sure you will not delete an active work or enterprise network configuration. If you cannot distinguish them, do not delete in bulk; submit a screenshot for guidance.

After rebuilding the system configuration, test one ordinary route first and leave complex routing and other network tools disabled. Once the basic connection is stable, restore the original settings one at a time. If the issue returns immediately, the problem is not just stale configuration; continue checking the underlying network or submit a ticket instead of repeatedly deleting and rebuilding.

A failed subscription update directly affects the route list, but it is not the same as a route connection failure. Updating requires the client to reach the subscription URL, retrieve configuration content, and parse it. Connecting uses configuration already stored locally. If old routes still connect while updates fail, the local cache remains usable and the problem is retrieving or parsing content. If the route list is empty and updates also fail, restore the subscription first instead of repeatedly switching between nonexistent routes.

Retrieve the subscription again from the user panel

Sign in to the user panel, confirm that the account and plan status are normal, and copy the current subscription from the panel. a4VPN does not require an email address for registration; a username and password are enough. If you forget your login details, use the account flow provided in the panel and never paste subscription content on a public page. Copy the complete URL, avoiding line breaks from chat apps, incomplete browser selections, or clipboard truncation. A subscription URL is an account credential and should not appear in ticket screenshots, public posts, or shared documents.

Before importing, create a separate configuration name and keep the old configuration for comparison. If the new configuration updates successfully, the old one may contain an expired URL or incorrect parameters. If both fail, continue checking network access and client parsing. Do not merge subscriptions from multiple sources before testing; conversion layers make it impossible to tell whether the original subscription works.

Example format, for identifying link structure only:
https://example.com/sub?token=YOUR_TOKEN

The value above is a dummy example, not a usable subscription URL. Obtain the real URL only from the user panel. When checking the link, confirm only that it is a complete secure URL and that its query portion has not been removed; do not modify its contents. Any request to submit a subscription to an external conversion site increases exposure risk and should be avoided during troubleshooting.

Identify the failed stage from the error type

If the client reports a network timeout, first confirm that the panel opens normally on the current underlying network, then test with another underlying network. If the panel works but the client times out during an update, check whether the client is incorrectly trying to update the subscription through the current proxy. When the old proxy is already invalid, this creates a loop. Temporarily disconnect, update over the underlying network, then connect the new route.

If the message says unauthorized, link expired, or empty response, copy the current subscription from the panel again instead of using an old URL from browser history. A parsing failure may mean that the client does not support the configuration format, the import method is wrong, or an intermediary tool rewrote the content. Obtain the client and subscription method suited to the platform from the panel, then re-import using Guides. iOS users can also read Complete Beginner’s Guide to Importing iOS Subscriptions, while Windows users can consult Windows Network Acceleration from Scratch.

Update succeeds but the route list does not change

The client may store multiple configurations. One configuration was updated, while another is currently enabled. Check the active configuration name, the latest update result, and whether the selected route belongs to the same source. Give the new configuration an easy-to-recognize name and confirm that the route list changes after switching. Do not rely on route names alone; similar names may exist in different configurations.

Some clients cache route groups. After an update, return to the configuration page and enable that configuration again, or close and reopen the client. If the list is still unchanged, check the update log to confirm that new content was actually retrieved rather than merely showing a completed task. Completion may only mean that the request ended; the response could still be empty or fail to parse. The exact error text is more useful than a screenshot of a generic “Failed” button.

Where plan traffic and update issues differ

Monthly subscription traffic resets each month on the activation date, and an upgrade mid-cycle applies the price difference to the remaining days. If the panel status does not match expectations, refresh the panel and confirm the current plan instead of repeatedly updating the client. Traffic packages remain valid until used and never expire. A failed update does not automatically change account status through re-importing. Account status and client cache are separate layers: the panel displays the subscription and plan, while the client reads and uses the configuration.

If the plan was just changed and the panel shows the update while the client still shows the old status, retrieve the subscription again and update the configuration. If the panel itself has not changed, submit an order and account ticket instead of adjusting DNS or routes. A screenshot of the order-status page is sufficient; do not attach complete sensitive payment-account information.

If the browser works but one application cannot connect, the underlying connection and route are usually available and the issue is concentrated at the application layer. Applications handle network settings differently: some follow the system proxy, some use the system network tunnel, some resolve DNS themselves, and some cache regional or network results from first launch. For a single-app issue, do not start by reinstalling the entire client. First confirm whether the app’s requests enter the current tunnel.

Use global mode for a short comparison

If the client offers rule mode and global mode, switch briefly to global mode and restart the target application. If it works in global mode, the route itself is available; the original rules may not match the request, or the app may use a domain not covered by the current rules. Update the rules, check the app’s domain group, or use the client’s app-routing feature. Restore the original mode after testing rather than treating the temporary comparison as a long-term setup.

After switching modes, fully quit and reopen the target application. Many apps keep long-lived connections, and changing the proxy mode in the background does not rebuild them automatically. Returning to the main screen may leave the app running in the background on the old path. On desktop, quit from the menu; on mobile, end the app task before reopening. Re-login is not the first step unless the app explicitly reports an account-region or session error.

System proxy versus system-level tunnel

A client that only sets the system proxy mainly affects applications willing to read that setting. Some games, meeting tools, store apps, and software with its own network framework may ignore it. A system-level network tunnel usually covers more traffic, but it can still be affected by routing rules. If the target app does not read the system proxy, choose a client mode that supports system-level interception or add the target program to the proxy scope through app routing. Use the current client’s own entry points rather than copying configuration names from other software.

On Windows and macOS, also check whether the app reaches the network through a separate service process. Adding only the foreground program to a rule may leave its background updater connected directly. Linux applications running in containers, sandboxes, or separate network namespaces may not see the desktop session’s system proxy. In that case, inspect the network exit of the actual runtime environment instead of switching ordinary browser routes again.

App cache, region, and account status

Streaming, store, and content apps may cache their regional decision. After switching routes, the app may still use the old session result. Fully quit the app, clear its cache or site data, connect to a route in the target region, and reopen it. Do not delete all app data at the start, as this signs you out and removes offline content. Prefer the app’s built-in cache-clearing option, or clear only data related to the target service.

If the website works but the app continues to show a regional restriction, check whether the app-store region, account region, and current egress region match. A network route changes the connection path but cannot automatically change regional information in the destination account. For related choices, see iOS VPN recommendations: comparing clients, regional restrictions, and subscription methods to understand the boundary between client and regional settings.

When the app has no traffic at all

Check whether the target program is listed as direct or excluded in the client’s app list. An old exclusion may remain locally after a rule update. Temporarily add the app to the proxy scope and restart it. If the client provides connection logs, check for requests from the app at launch. No request usually means the app is not using the current tunnel; a request that fails points more toward DNS, the route, or the destination service.

Security software and the system firewall may separately restrict the client or target app. Do not permanently disable all protection. Check recent block records and validate only the specific client process and target app. If disabling one protection restores access, create the necessary rule according to the software documentation and re-enable protection. A ticket cannot reveal local firewall details remotely, so include the error and app name rather than only a screenshot of the client home screen.

Only voice, images, or sign-in fail

One application may use different domains for sign-in, images, messages, voice, and updates. If text messages work but images do not load, the whole app cannot be declared unavailable. Record the failed feature and find the corresponding request in the routing log. If global mode works but rule mode does not, the issue is a domain group or routing-coverage mismatch. If both modes fail, compare another route and underlying network.

If the sign-in page loops, the verification page is blank, or the authorization window cannot return to the app, use the system default browser to complete authorization on the same route and disable extensions that block cross-site cookies or callback URLs. Do not submit sign-in requests repeatedly, as the destination service may impose a temporary restriction. Wait until it allows another attempt, then complete one sign-in flow on a stable route.

a4VPN supports unlimited devices, so normal use should not require deleting old devices because of device count. If the client shows “too many devices,” “authorization issue,” or a similar message, first confirm whether it comes from the a4VPN user panel, the current client, or the destination website. Third-party apps may limit their own signed-in devices, which is unrelated to the acceleration subscription. Screenshots should include the surrounding interface showing which app issued the message, not just the error line.

Confirm that the same account is signed in

With multiple devices, the most common confusion is that different devices imported subscriptions from different accounts, or one device is still using an old configuration. Sign in to the user panel, verify the username and plan status, and retrieve the subscription again from that same account. a4VPN does not require an email address; a username and password are enough to register. Use the username to identify the account, not the configuration name on the device, since configuration names can be changed.

If one device works while another cannot update, first check the affected device’s client, network, and subscription import rather than assuming an account-wide failure. If every device shows the same account-status message, review the plan and traffic information in the panel. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and a mid-cycle upgrade applies the price difference to the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, valid until used and never expiring. See the pricing page for options and status details.

Check local network capacity even with many devices

Unlimited devices does not mean that each device’s application traffic is independent. Downloads, cloud sync, video playback, and system updates across multiple devices on the same underlying network share local resources. If “everything lags as soon as multiple devices connect,” pause high-traffic tasks on the others and retest with one device. If performance returns, the bottleneck is local capacity or traffic scheduling, not device authorization.

If different devices on different underlying networks cannot connect to the same route at the same time, switch routes and record the result. If each recovers after switching, the original route may be at fault. If every route fails, check whether the account subscription updates normally. Do not repeatedly change the password to test routes; a password change affects sign-in state but will not fix client DNS, routing, or permissions.

When payment and plan status are out of sync

a4VPN supports Alipay / WeChat / USDT. If the panel has not changed after payment, refresh the user panel and check the order status before submitting another payment. A completed status on the payment channel does not necessarily mean that the panel has received the final status. Creating repeated orders makes reconciliation harder. For a ticket, provide the publicly visible order reference, payment time range, and panel status; redact sensitive payment details.

If you are not satisfied with your first payment, you can request a full refund within 14 days. Refunds are handled at the account and order level; deleting the client or changing routes will not resolve them. State the order and usage issue when applying so support can verify it. Do not interpret the refund commitment as an automatic account-deactivation rule in this troubleshooting guide; the panel and ticket result determine the account status.

Configuration differences across platforms

Windows / macOS / iOS / Android / Linux are all supported, but client configurations should not be assumed to be fully portable. A local configuration exported from one platform may include platform-specific paths, app rules, or permission state and may not work when copied to another. The safer approach is to obtain the appropriate client from the user panel on each device, then import the subscription from the same account. This keeps route content consistent while platform permissions and local settings remain separate.

A successful connection on one device proves that the account and subscription worked at that moment, but not that another device’s system permissions are correct. For comparison, use the same route, underlying network, and target website. If only the platform differs, focus on client mode and system permissions. If the platform is the same but the network differs, compare the underlying networks first. Narrow variables layer by layer instead of exchanging large numbers of configuration files.

Signs of an unknown device or leaked configuration

If you suspect that a subscription was copied into an environment you do not control, update the account credentials in the user panel and retrieve the subscription again. Remove the old configuration from devices you no longer use. Do not send the complete subscription to someone for testing or upload it to an online converter. In a ticket, state only why you suspect exposure and when you noticed it; do not paste the sensitive URL again.

After updating credentials, sign in and import again on devices you control, then monitor the panel status. If only a third-party app reports a device restriction, address that app’s account first rather than changing a4VPN credentials by mistake. The title, app name, and complete message from the interface are key to distinguishing the two.

The goal of troubleshooting is not to make users solve every low-level issue themselves, but to turn a vague “it does not work” into information that can be located. If the issue remains reproducible after comparing the underlying network, routes, subscription, and client, submit a ticket. A well-structured ticket lets support determine whether to check the account, route, or client without repeatedly asking about the environment. The ticket entry is in the user panel; after signing in, submit a ticket.

When it makes sense to submit a ticket directly

Several underlying networks and routes in multiple regions all fail, while client permissions and subscription updates work normally; the same destination service consistently fails on multiple devices using the same route while other sites work; a subscription retrieved again from the panel still will not update and returns a clear unauthorized or parsing error; plan, traffic, order, or refund status differs from the panel; or one route disconnects repeatedly under reproducible conditions. These cases go beyond simple local steps, and repeated reinstalls will only destroy evidence.

If the issue occurs on only one device while others work, you can still submit a ticket, but state the platform, client source, connection mode, and steps already completed. Support may first need to rule out system permissions and local conflicts. If only one third-party app is affected, include its name, the failed feature, and the browser comparison; do not write only “everything else works.”

What a ticket should include

Write a direct symptom in the title, such as “Windows route list empty after subscription update,” “iOS connection stops after screen lock,” or “Same-region video buffers during peak hours.” In the body, state the platform and underlying network first, then the current route, client status, exact error text, and reproduction steps. List the actions already tested and whether each one changed the result. This order makes the problem boundary clear to support.

Screenshots should show the full interface context, including the app name, error location, and current status, but redact subscription URLs, access tokens, passwords, sensitive payment details, and other private content. Include only the log sections around the failure; do not upload a full configuration export. If the client can generate a redacted diagnostic log, prefer that. If you cannot confirm that it is redacted, ask in the ticket which fields are needed.

Issue:
Platform:
Underlying network:
Current route and connection mode:
Exact error message:
Steps to reproduce:
Actions already tried:
Result after switching routes:
Result after switching the underlying network:
Time range when the issue occurred:
Attachment notes:

How to provide useful timing information

Do not write only “just now” or “recently.” Include the time zone and approximate time, and say whether the issue is continuous, occasional, or concentrated during peak hours. Route logs are usually searched by time, so a clear range reduces the effort needed to investigate. If the issue is triggered by locking the screen, switching networks, opening an app, or updating a subscription, put that trigger before the time information.

If the issue has resolved by itself, you can still submit a record, but state the last action taken before recovery and whether you switched back to the original route to retest. Do not combine unrelated symptoms in one ticket; for example, describe order status and an app-routing issue separately. Different issues may be handled by different teams, and separating them makes the outcome easier to track.

How to verify after support replies

After receiving advice, make only the changes requested in the reply, then test using the original reproduction steps. If you also add other changes, the result cannot be attributed reliably. Report what you changed, what result changed, and whether the original symptom can still be reproduced. If support recommends switching routes, name the route before and after. If re-importing is recommended, state whether the new configuration updated successfully and whether the route list appeared.

After recovery, keep a brief conclusion—for example, stale configuration, an underlying-network switch, an app rule, or a particular route. If a similar symptom appears later, check that layer first, but do not assume the cause is identical. Network failures often look alike; reliable conclusions still depend on controlled comparisons.

Build your own minimal troubleshooting record

Daily use does not require a detailed report. Keep a few stable facts: commonly used routes, workable backup routes, client mode, network environments that trigger issues, and the actions that restore service. When something goes wrong, return to this baseline and decide whether the route, system, or target application changed. For remote meetings and collaboration, the route-selection methods in Remote-work VPN route testing: how to choose routes for meetings and collaboration can help you prepare a backup path in advance.

If the basic setup is not complete, return to Guides and review the main workflow. To compare plans and traffic rules, see the pricing page. To confirm regions and route types, see the server page. Reviewing quick-start setup, route selection, plan status, and troubleshooting separately reduces irrelevant changes and makes it easier to provide an accurate ticket summary.