VPNXA Troubleshooting Guide

Define the scope first

The most common mistake when troubleshooting network issues is not a lack of tools, but changing too many variables at the start. A website fails to open, so someone immediately reinstalls the client, replaces the subscription, switches protocols and changes DNS. When the issue happens to clear, there is no way to know which change helped. A more reliable approach is to describe the symptom first, then establish a comparable baseline. VPNXA’s quick-start guide covers the main steps from activation to connection; this page is for connections that are already failing, unstable or behaving unexpectedly in a specific app.

Turn “it doesn’t work” into a testable symptom

First, identify the scope of the problem. A complete connection failure usually means the client remains stuck on Connecting or quickly returns a handshake, authentication or timeout error. If the client says Connected but websites will not open, some local proxy state has likely been established, so check the system proxy, DNS, routing rules or exit route. If only one website fails, do not start by changing the entire client; the site’s regional policy, cache, account region and browser extensions may all matter. If only one app fails, check whether it bypasses the system proxy, uses its own network stack or is missing its domain in the rules.

Next, determine whether the issue occurs on every network or only the current one. Turn off the VPN connection and open a regular website that is normally reliable. If that site also fails, restore the local network first instead of mistaking a local outage for a route problem. You can compare another network on the same device, or connect a second device to the same network. The first test checks whether the current access network imposes restrictions; the second checks whether the issue is limited to one device. VPNXA supports Windows, macOS, iOS, Android and Linux, and plans do not limit the number of devices, so using another available device for cross-checking is reasonable.

Change one variable at a time

Once you have a baseline, work through local network, client, subscription, route, system settings and target app in that order. Change only one item per test, then repeat the same test. For example, keep the webpage, test location and speed-test method unchanged. If switching routes restores access, keep the client and DNS settings as they are. If switching networks helps, inspect the original network’s gateway, authentication page or access policy. This produces a reproducible conclusion rather than a one-off success.

When recording symptoms, preserve the client’s complete error text instead of writing only “an error appeared.” Note the platform, selected route, current network type, approximate time, whether all websites are affected and whether the local network works with the connection off. Screenshots should show the error and route name, but hide your username, subscription details and access credentials. If logs contain a subscription URL, remove the token before submitting them.

Use system tools to locate the failing layer

Command-line tools can provide useful clues without complex parameters. First check whether the domain resolves, then inspect the proxy settings currently used by the system. If the domain resolves but a web connection cannot be established, focus on the proxy port, system firewall and route. If the domain does not resolve but a direct request to a known service still responds, focus on DNS. Commands vary by system; before running them, disable terminal-history syncing that could contain sensitive information, and hide any local username appearing in the output before submitting it.

nslookup example.com
ipconfig /flushdns

scutil --proxy
dscacheutil -flushcache

getent hosts example.com
env | grep -i proxy

These commands only inspect DNS resolution and the proxy environment; they do not prove that a particular route works. Always combine the result with the client status, browser behavior and network comparison. If the basic checks clearly point to a local network issue, fix the router connection, network authentication or system networking service first. If the problem appears only when the VPN connection is enabled, continue to the later sections. The process should narrow the search area, not repeatedly reinstall the software.

Cannot connect at all

When the client cannot complete a connection, first identify the stage where it stops. An immediate failure after clicking Connect often indicates that the subscription did not load correctly, the selected route was removed from the subscription, the client lacks system permission or another network tool is using the same proxy entry point. A timeout after waiting for a while is more consistent with the current network being unable to reach the route, unstable connectivity or a route that is unsuitable for the access environment. If the client reports authentication failure, check the panel login state and subscription validity before switching through many routes.

Verify the local network and system time first

Disconnect the client and confirm that regular websites and system network services work normally. Public networks sometimes require browser-based authentication first; if the sign-in page does not appear automatically, turn off the VPN connection and open a regular website again. A significantly incorrect system clock can also make secure connection checks fail. Let the system synchronize time automatically rather than guessing manually. After these checks, quit and reopen the client so it does not continue using an old connection created before authentication.

If the same device connects on another network, the subscription and client are probably working, so focus on the original network. Do not keep deleting configuration; compare whether the original network has an extra firewall, parental controls, enterprise policy or gateway filtering. If every network fails, check client permissions and the subscription. Desktop systems may require a network extension, virtual network interface or firewall permission; mobile systems display network-configuration authorization. After permission is revoked, the client may still show a route list while being unable to establish a real tunnel.

Check for client takeover conflicts

Running multiple proxies, filters, packet-capture tools or security apps on one device can create interface conflicts. During testing, fully quit any other program that can control system traffic and leave only the current client running. Closing a window may not quit the program; check the system tray, menu bar or background processes. Also pause standalone browser proxy extensions, which may send requests to a local port that no longer exists. Once the connection works, re-enable necessary tools one at a time to identify the conflicting component.

Stale system proxy settings are another common cause. After an abnormal client exit, the operating system may continue forwarding web requests to an old local proxy port. The client then fails to connect while the browser appears offline. Start with the client’s “Turn off system proxy” or “Restore network” function. If the client will not open, inspect the system network settings and confirm that a manual proxy is not pointing to an inactive local address. Do not delete every network interface without understanding whether enterprise networks, virtual machines or other business software depend on them.

Refresh the subscription instead of repeatedly importing an old copy

If the route list is empty, route names look wrong or selecting a route immediately produces a configuration error, open the user panel and fetch the subscription again. Both client downloads and subscriptions are provided through the panel; static marketing pages do not contain a real subscription URL. Preserve the complete address when copying it, do not pass it through chat apps and do not manually remove or edit parameters. Before importing, you may delete obviously duplicated or expired configurations in the client, but keep a backup of local rules. For the complete import process, return to the quick-start guide and follow the platform-specific steps again.

VPNXA covers 110+ countries and 210+ routes. One route failing to connect does not mean the entire subscription is invalid. Choose a backup route in the same region or test a nearby region. See the complete classification in the route list. For testing, start with the client’s default protocol and routing settings so custom parameters do not affect the baseline. Once the default setup connects, gradually restore your personal rules.

If you still cannot connect after all the steps above, stop sending repeated connection requests. Keep the failed route name, error message and comparison results, then prepare the details in the support-ticket section. Support needs to know the environment, the steps taken and the exact error that can be reproduced—not a vague statement that every route fails. A reproducible description determines whether troubleshooting starts with the subscription, route or local system.

Connected but websites won’t open

A Connected status only means the connection process reached some completed state; it does not prove that browser requests are correctly passing through the tunnel. When a website will not open, distinguish between a domain that does not resolve, a browser that is not using the proxy, a request rejected by the destination and a page whose resources only load partially. All may appear as a blank page or timeout, but the troubleshooting paths differ completely.

Compare the browser, system apps and a direct request first

Open a stable website in a regular browser window, then compare it with another browser or a built-in system network app. If only one browser fails, inspect its proxy extensions, secure DNS, cache and independent network settings. If every app fails, inspect the system proxy, DNS and route. A private window reduces cache and extension interference, but some extensions can still run there, so disable them explicitly in the extension manager.

If the browser says the proxy server refused the connection, it is usually being sent to a local port with nothing listening on it. Check whether the client enabled the system proxy and whether the port entered in the browser extension matches the one currently provided by the client. Do not copy a local port from another guide: different clients, modes and configurations may use different entry points. The most reliable source is the client’s current interface or its generated system proxy settings.

Identify DNS resolution problems

If the error says the domain cannot be found, the name cannot be resolved or DNS failed, query a regular domain first. If there is no result, clear the system DNS cache and restart the browser; if the issue remains, restore the client’s default DNS settings. Do not specify different DNS servers in the system, browser, router and client at the same time, as this makes the request path difficult to identify. Browser secure DNS may bypass system settings, so disable it temporarily during testing and decide whether to re-enable it after the connection is restored.

If the domain resolves but the webpage still times out, DNS is not the main issue. Switch to a backup route and check whether the rules mistakenly classify the destination as direct. Websites often use several domains for the main page, images, scripts and video. If the page opens but images or login components fail, related resource domains may not be using the same exit. Temporarily use global mode for comparison; if global mode works and rules mode fails, fix the rules instead of changing DNS again.

Handle cache, protocol and account-region differences

Some websites return different content based on prior visits, account region, browser storage or exit location. If the page remains in its old state after switching routes, clear that site’s cache and site data or revisit it in a fresh private window. You only need to clear the current site, not all browser data. If the issue occurs after login but disappears after signing out, check whether the account region matches the selected route region. Changing the route changes the network exit, not the account’s own region.

When loading stops halfway, check whether every resource fails or only one type. The developer tools Network panel shows request status, but do not expand details containing account credentials or authorization headers when taking screenshots. If only large images, video or files fail, path quality, segmented connections or destination-service policies may be involved. If even text pages fail completely, the proxy or DNS is more likely. Switch to another route in the same region to test for a single-route issue; switch regions to check whether the destination applies regional policies.

Confirm that the system proxy is actually applied

On desktop systems, check the system network settings to see whether the proxy changes with the client toggle. A proxy entry appearing while connected and being removed after disconnecting is the expected takeover behavior. If nothing changes after connecting, check whether the client is in local-port-only mode; that mode requires separate configuration in the browser or app. If the proxy remains after disconnecting, run the client’s network-restore function. On mobile systems, check the network indicator in the status bar and confirm that another similar configuration is not enabled at the same time.

On managed enterprise devices, some proxy and network settings may be locked by policy. The client cannot override those policies, so apps may not be routed even when the interface says Connected. Do not remove configurations outside your personal control; ask the device administrator which network methods are permitted. On a personal device with repeated installations and removals, delete obsolete network configurations and reauthorize the current client, but first confirm that other work-related network services will not be affected.

If no browser or app can connect, DNS queries work, and the system proxy is correct, narrow the issue to the route or client tunnel. If switching routes and networks does not help, save the client log and submit a support ticket. Logs show more clearly whether requests entered the tunnel than webpage screenshots, but check them first for a complete subscription URL or other sensitive fields.

Slow speeds and peak-hour lag

Speed cannot be judged from one download result. Cross-border performance depends on local access, Wi-Fi quality, carrier routing, route distance, destination capacity and time of day. A single number on a marketing page cannot replace testing in your own environment. Keep the device, network, test target and method consistent; change only the route or testing time and see whether the result repeats reliably. See How to test VPN speed for a detailed method.

Establish a local baseline with the connection off

Turn off the VPN connection and confirm that the local network is not fluctuating noticeably on the same device. Weak Wi-Fi, a busy router or background file synchronization can make every route seem slow. During testing, pause cloud sync, system updates, livestreaming and large downloads, and move closer to the wireless access point. On desktop, use a wired connection for comparison. If wired is stable but Wi-Fi fluctuates, fix the local wireless environment instead of blaming the remote route.

Then connect to a geographically nearby route and repeat the same access test. A shorter distance often reduces round-trip time, but it is not guaranteed to be fastest at every moment. If a nearby route performs poorly, check the route types in the route list and try another entry in a neighboring region. Test real scenarios such as webpage loading, video startup and sustained transfer rather than only the status shown in the client.

Separate latency, jitter and sustained bandwidth

If a webpage takes a long time to respond but downloads run normally once started, latency or DNS is more likely. If video starts quickly but repeatedly lowers quality or buffers during playback, suspect insufficient sustained bandwidth, path instability or destination throttling. Calls and live sports are more sensitive to jitter: brief fluctuations can cause broken audio or a catching-up picture even when average throughput is sufficient. See the sports livestream route guide for the difference between real-time and on-demand scenarios.

Do not reduce every scenario to “fast” or “slow.” Record whether the first page load is delayed, whether video can hold the required quality, whether long-lived connections drop and which result improves after switching routes. This helps distinguish slow connection setup, insufficient sustained transfer and short bursts of instability. If one route responds quickly but large files are unstable, keep it for interactive use; use a steadier route for video or downloads.

Compare conditions during peak hours

A single test during quiet hours says nothing about peak-hour performance. Test during the period when the issue actually occurs, using the same device, target and route, then switch to a backup route. If every route slows at once and the local network also degrades with the connection off, the bottleneck is more likely local access or the carrier path. If only one route slows while nearby-region routes remain normal, avoid that route temporarily and record the symptom. If the destination itself slows during busy periods, use another stable target for comparison.

Do not cycle through every region randomly during peak hours. Start by trying different route types in the same region, then nearby regions, and only then more distant exits. After each switch, fully end the old connection, wait for the client to complete the new one and reopen the test page. Existing browser connections may continue reusing the old path, so close relevant tabs or restart the target app when necessary to ensure requests use the new route.

Check client mode and system resources

Global mode sends more traffic through the tunnel, so background updates, sync and other apps may compete for bandwidth. With sensible rules, rules mode can process only the traffic that needs it. When troubleshooting speed, check the system Task Manager or Activity Monitor to confirm that no other process is transferring continuously. Power-saving mode, high temperature or limited system resources can also affect client encryption. Close unnecessary programs, connect stable power and test again.

If only the browser is slow while other apps work normally, check browser extensions, secure DNS, hardware acceleration and cache. If only one app is slow, see the app-routing section. If every app is slow on every route but the local baseline is normal with the connection off, submit the route name, destination service and reproduction steps from the same period. Do not attach only one speed screenshot; it cannot show the test environment, route or whether the issue is reproducible.

Frequent disconnects and mobile background drops

For frequent disconnects, first determine whether the tunnel is reconnecting itself, the device is switching networks, the system is stopping a background process or the client is exiting. On desktop, sleep/wake cycles, Wi-Fi changes and other network tools are common causes. On mobile, battery-saving policies, background permissions and network changes matter more. A briefly disappearing status-bar icon alone cannot show that the route is faulty; compare the timing with client logs.

Observe what triggers the disconnect

Record whether the drop always occurs after locking the screen, switching from Wi-Fi to a mobile network, waking the device or launching a large app. If it coincides with a network change, the old connection likely expired without being rebuilt successfully. Test in one network environment first to see whether the route remains stable without switching. If it does, enable the client’s automatic reconnect or on-demand connection option and check whether it recovers after a network change.

If disconnects also occur without changing networks, compare a backup route in the same region. If only one route drops, keep its name and use another route temporarily. If every route drops, inspect local Wi-Fi signal, router lease changes, system sleep and the client’s background permissions. If the local network itself briefly drops with the VPN connection off, fix local access first. Do not hide an unstable local network by continuously changing routes.

Mobile background policies

Mobile operating systems limit apps that remain out of the foreground to save battery. In system settings, allow background activity for the client and set its battery policy to unrestricted. Menu names vary by manufacturer and are usually found under app info, battery or background management. Adjust only the settings related to the VPNXA client; do not disable the entire system’s power-saving mechanism. If the system offers an “always-on” or on-demand network configuration, enable it only after confirming that the client is stable.

Some devices pause Wi-Fi after the screen locks and switch to another network when they wake. The old tunnel then needs a new handshake, so a brief interruption is part of the network transition. If the client does not recover automatically, open it and check whether it asks for authorization again. After a system upgrade, reset or reinstall, the old network configuration may no longer work; delete it and reauthorize the current client. Do not keep several similarly named old configurations, as they may compete for system control.

Desktop sleep, wake and interface changes

When a desktop wakes from sleep, network interface addresses and the default route may change while the client retains its pre-sleep connection state. The usual symptom is a Connected interface with no webpage access, restored after disconnecting and reconnecting. Enable automatic reconnect on network change if the client offers it; otherwise reconnect manually after waking. If this happens often, check for other software that creates virtual interfaces and confirm that it does not also modify the default route.

Switching from wired to Wi-Fi or changing access points can also invalidate an existing connection. During testing, keep one access method fixed. If the connection becomes stable, the route may not be the issue; focus on reconnecting after interface changes. If it still drops on a fixed network, inspect system and client logs around the event. Timeouts, network unreachable errors, a missing interface and a process exit point in different directions; do not label them all as an unstable route.

Distinguish an app disconnect from a tunnel disconnect

If only a video, call or game asks you to reconnect while the browser still works, the target app’s session may have ended rather than the entire tunnel. A changed network exit, account-region change or background process termination can invalidate a session. Restart the target app and establish a new session instead of reinstalling the client immediately. If the browser, system apps and target app all lose access, treat it as a full tunnel disconnect.

While monitoring, keep one stable webpage open as a reference. When the target app reports an error, refresh the reference page immediately: if it works, the tunnel is still active; if it also fails, check the client status. This simple comparison is more reliable than the status icon alone because some systems update icons late. If the client process was terminated, focus on background permissions. If it remains running but repeatedly rebuilds the connection, compare routes and network environments.

When submitting this type of issue, say whether the device was in active use, locked, asleep or switching networks when the drop occurred, and include log excerpts from before and after it. “It disconnects often” lacks a trigger and cannot be reproduced. If the issue appears only when a specific app is in the background, also say whether foreground use works normally so support can distinguish process termination from a route problem.

Subscription update failures and unusual device status

Subscription update failures usually occur while fetching the subscription, not during the route connection itself. Common symptoms include a network error during refresh, an unchanged route list, an empty import, old routes remaining or a configuration-parse error. Unusual device status may appear as a new device being unable to fetch configuration, an old session remaining active or multiple clients overwriting settings. VPNXA plans do not limit the number of devices, so a “device limit” message should not be read as a plan restriction; check local client limits, login sessions, old configurations or third-party software rules instead.

Fetch a valid subscription again from the user panel

Sign in to the user panel, confirm that the plan and traffic status are normal, then copy the current address again from the download or subscription area. VPNXA requires no email address; a username and password are enough to create an account. If you forgot the username or cannot sign in, use the panel’s support-ticket process instead of repeatedly creating similar accounts. Copy the subscription directly from the panel into the client, avoiding apps that may generate previews, truncate parameters or escape characters.

If the client cannot refresh, first sign in to the panel in a browser and confirm that the page itself is accessible. If the panel works but the client update fails, check whether the client is incorrectly sending the subscription request through a proxy that is not ready. Some clients offer “update through proxy” and “update directly” options; start with the default. If the current proxy is inactive, disconnect before updating. Never paste a real subscription URL into a public checker or include the complete address in screenshots or public logs.

Clear old caches and duplicate configurations

An unchanged route list may mean the client is still using cached data. Refresh the subscription manually, then fully quit and reopen the client. If several configurations have the same name, confirm that the enabled one is the newly updated copy. Back up local rules if needed, then delete duplicates so the client cannot switch back to an old configuration at startup. If the client shows the subscription update time, use it to confirm that the refresh completed, but do not rely only on a “Success” message; check that the route list matches the panel’s current content.

When configuration parsing fails, do not edit the subscription manually. Adding line breaks, deleting parameters or importing a webpage response as a configuration can all corrupt the format. If copying it again still fails, test with another supported client. If the other client imports it, the original client may need compatibility or cache troubleshooting. If no client can import it, preserve the exact error and submit a support ticket. Get the client download through the user panel, not an installer from an unknown source.

Handle device status and login sessions

If a new device cannot sign in while an existing device works, confirm that you entered the same username and check whether the password manager filled in an old account. Sign out and enter the credentials again instead of relying on saved, incorrect credentials. If every device cannot sign in, the account status or password is more likely at fault. Payment and plan information can be checked on the pricing page; the user panel remains the source of truth for the actual account status.

If a third-party client shows a device-limit warning, first identify whether it comes from the client, the operating system’s network configuration or the service response. VPNXA’s stated policy is that there is no device-count limit; the client may limit saved configurations, while the operating system may retain old network settings. Removing invalid configurations, signing out of old sessions and importing again is usually better than creating more accounts. If the server returns a clear error, capture the complete response area, hide the username and subscription token, and submit a support ticket.

Traffic resets and traffic-pack boundaries

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 is prorated by the remaining days. Traffic packs cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. If the client can update the subscription but cannot connect, check the current plan and traffic status in the panel instead of mistaking depleted traffic for a configuration issue. If the page and local client are out of sync, refresh the panel first, then update the subscription again.

Do not calculate the reset date or remaining traffic yourself. Monthly plans follow the activation date, and the panel is the authority for the specific account status. After a mid-cycle upgrade, remaining days are prorated by the price difference, so an old expiry value cached by the client may be temporarily inaccurate. Fetch the subscription again and restart the client before checking. If the panel itself shows incorrect information, attach a screenshot of the order-status page to the ticket, hiding payment details and personal sensitive information.

For issues such as a paid plan not activating, inconsistent plan status or traffic not displaying according to the stated rules, do not try to fix them by paying again. VPNXA supports Alipay, WeChat Pay and USDT, and offers a 30-day no-questions-asked refund. Support should verify order and account status on the backend. Provide only the order identifier, payment method and problem page; never submit a payment password, complete transaction credentials or any secret that could access the account.

An app bypasses the proxy and DNS issues

When the browser works but one app cannot connect, routing is the most likely issue. The app may ignore the system proxy, open connections directly or use different domains and transport methods from the browser. DNS problems can also undermine rule matching: an unresolved domain, a cached result or separate resolution paths in the browser and client can make the same site appear to connect directly sometimes and through the proxy at other times.

Confirm whether the app follows the system proxy

After connecting, use a browser to confirm that the tunnel works, then launch the target app. If the browser works but the app does not, check whether the client offers a virtual network interface or enhanced mode. With only a system proxy configured, apps that follow it work normally while apps that connect directly may bypass it. Before enabling a virtual interface, quit other network tools of the same type and grant the system permissions requested by the client. Test the target app again without changing rules or DNS at the same time, so you can identify which change mattered.

Some apps read network status at launch, so switching proxies while they are running may not take effect immediately. Fully quit and reopen the app instead of merely returning to the desktop. On desktop, also check whether it remains in the tray or menu bar. If restarting fixes the issue, the old session did not update after the network change; if it still fails, inspect rule matching. Account region, app-store region and the app’s own cache may affect content, but those are separate from proxy takeover.

Use global mode to check for missing rules

After confirming that the local network and route work, briefly switch to global mode for testing. If the target app works in global mode but not rules mode, the rules do not cover a required domain or address. Check the client connection log, identify the domains the app accesses at launch and add suitable rules. Keep rules specific to clear domains; do not send large amounts of unrelated traffic through the proxy for one app. Switch back to rules mode and test again.

An app often relies on separate domains for login, APIs, images, updates and media. Adding only the main domain may show the home page while login or content loading fails. Start with the failed step and observe requests: if launch fails, check authentication and configuration domains; if the page is blank after login, check API and static-resource domains; if playback fails, check media-delivery domains. Do not copy an unfamiliar rule set wholesale, as overly broad rules add unnecessary traffic and may send local services through the tunnel.

Resolve inconsistent DNS paths

The client, system, browser and router can all participate in DNS. Reduce the number of layers during testing: restore the client’s default DNS first and temporarily disable the browser’s independent secure DNS. Clear the system cache and restart the target app. If this restores access, re-enable the original settings one at a time to identify the conflict. DNS resolution alone does not mean the result suits the current exit; in rules mode, resolution and proxy policy for related domains generally need to align.

You can use system lookup tools to compare results, but there is no need to chase one fixed address. If the lookup returns results while the browser still reports a name error, the browser may be using its own cache or resolver. Close all browser processes and reopen them, or clear only the target site’s data. If system lookup also fails, check whether the local network blocks custom DNS and try automatic DNS again. Do not copy an address from a public guide into every device; different environments can make that approach more complicated.

nslookup example.com

ipconfig /flushdns

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

resolvectl flush-caches
getent hosts example.com

Check hosts, filtering rules and security software

The system hosts file, content filters, firewall and security software may block a domain before the proxy is involved. If only a specific domain fails, check for a matching hosts entry. Back up the file before editing it, and remove only entries that you clearly added yourself and that are no longer needed; do not overwrite the system file in bulk. If security software offers web filtering or encrypted-connection inspection, temporarily pause the relevant module for comparison. Once the conflict is confirmed, create a sensible exception for the client instead of leaving protection disabled.

Browser extensions can also change DNS or the request path. Outdated ad-blocking, privacy or proxy-extension rules may block login components or scripts. Comparing with a browser profile that has no extensions is faster than guessing one by one. If the clean profile works, restore extensions individually. The goal is to identify the specific conflict, not permanently disable every security setting.

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

Prevent DNS issues from being mistaken for route problems

A brief recovery after switching routes does not necessarily mean the original route was faulty. Route changes often rebuild the connection and refresh caches; the effective change may have been DNS state. To verify this, clear the cache and restart the app while staying on the original route. If access returns, organize the DNS settings first. Conversely, if the same DNS settings work on every route except one, the issue is more likely related to that route’s exit or the destination’s policy.

When the issue affects only one website or app, state in the ticket whether the browser works, whether global mode works, whether rules mode fails, whether system lookup resolves the domain and whether the target app was fully restarted. This lets support decide whether to start with the route, rules or DNS instead of repeating basic steps already completed.

When to contact support and ticket details

The goal of self-checks is not to make users handle all the technical work, but to narrow the issue to something support can reproduce quickly. Submit a ticket for account-status problems, a plan not activated after payment, a mismatch between panel information and the order, persistent failure on every route across multiple networks or a clear server-side error from the client. An occasional issue on one route can be handled by switching to a backup; if the issue is reproducible, affects multiple routes or involves account data, stop repeatedly changing local settings.

When to submit a support ticket right away

If the panel cannot show a completed order, the plan status is incorrect, traffic data clearly will not refresh or every supported client fails to parse a newly fetched subscription, support should verify the account and subscription. The same error across multiple devices, networks and routes also indicates that the issue is beyond one device’s settings. Reinstalling at this point may erase useful logs, so save the evidence first.

Security-related anomalies should also be reported promptly, such as subscription content changing without your action, an unfamiliar login session or a password that will not update normally. Change the account password and sign out of old sessions before submitting a ticket. Do not send your current password, complete subscription URL, payment password or an account-access token in the ticket. Support does not need these secrets.

What to include in the ticket

Start with a clear subject, such as “Windows: all websites fail to resolve after connecting” or “iOS: connection does not recover after locking the screen.” State the platform, client source, current network environment, selected route, approximate time the issue first appeared and whether it reproduces consistently. Then describe the sequence: open the client, select the route, click the control and note the result. Finally, list the checks already completed—switching networks or routes, refreshing the subscription and clearing the DNS cache—and the result of each.

Copy the error exactly instead of quoting one line. Screenshots should include enough context to show whether the message came from the client, system or target app. Keep only the log lines around the incident, and search them first for a subscription URL, username, local directory name or other sensitive information. Fully cover tokens in subscription URLs. If the log is long, include the approximate time of the issue so support can locate it.

Additional material by issue type

Connection failures need the client error text, route name and network comparison. Inaccessible websites need DNS lookup results, system proxy status and whether another browser works. Speed issues need a direct baseline from the same period, selected route, real usage scenario and backup-route performance. Frequent disconnects need the timing relative to screen lock, sleep or network changes. Subscription update failures need panel accessibility, the client error and a comparison with another client.

If an app bypasses the proxy, say whether the browser works, how global and rules modes differ, whether the target app was fully restarted and whether related connections appear in the log. For DNS issues, include the lookup command and result, but not the entire system network configuration. For a device-status warning, identify the interface that displayed it and confirm that the same account is being used. This prevents support from mistaking a local client message for a plan restriction.

How to stay productive while waiting

If only one route is affected, temporarily use a backup region from the route list. For speed issues, choose a nearby region and keep the stable route rather than relying on frequent automatic selection. For rule issues, you can temporarily use a verified working mode, but record the temporary change and restore and retest it after support replies. For account or order problems, do not pay again or create multiple accounts to work around the status; that only makes verification harder.

Keep client logs and screenshots until the issue is resolved. When support suggests new tests, perform one change at a time and report what changed before and after. If the issue resolves on its own, add the recovery time, route in use and any setting changes. These details help distinguish a route switch, cache refresh and local network recovery in intermittent cases.

Review after the issue is resolved

After recovery, undo temporary settings that are no longer needed. For example, turn off global mode used for comparison, remove duplicate subscriptions, restore a sensible background policy and re-enable security tools that have been verified not to conflict. Do not keep multiple unknown DNS sources, proxy extensions or obsolete network configurations. The fewer configurations you have and the clearer their roles, the easier future issues are to isolate.

Record the final effective action locally, such as “restored after reauthorizing the network extension,” “restored after clearing the old system proxy” or “restored after adding the resource domain to the rules.” Do not include a real subscription URL or credentials. If the same symptom returns, first check whether the trigger is the same, then reuse the relevant fix instead of repeating every step unconditionally.