VPN Troubleshooting Guide

Establish a reproducible troubleshooting baseline

Describe the symptom before guessing the cause

Connection problems often take longer to resolve because the issue is attributed to a route, client, or account from the outset, followed by several setting changes at once. The more changes made, the harder it is to tell what actually fixed the connection. A better approach is to record the exact symptom first: does the client show Connected, can the browser open ordinary websites, are only international services failing or every website, are other devices affected too, and does switching routes change the result? The more specific the symptom, the fewer branches remain.

Keep one test environment free of extra extensions and complex routing rules. Use a new temporary browser window, leave the client on its default rules, and temporarily disable tools that alter the network path. The goal is not to change your long-term setup, but to establish a simple baseline. If the baseline works, the issue is usually a conflict involving browser extensions, custom rules, app proxies, or multiple network tools. If the baseline also fails, continue with the network and subscription layers.

Narrow the fault to one layer

A connection has several stages: the local network sends the request to the client; the client decides whether to connect directly or use a proxy; a route from the subscription establishes the session; DNS resolves the domain; and the destination service returns the content. A failure at any stage can look like a website that will not open. Do not rely only on the client’s connection icon. It shows that a session was established, not that the browser, system proxy, DNS, and specific app are all using the same path.

Change one variable at a time

Compare results in this order: network, route, mode, then app. Keep the client and route unchanged while switching only the local network. Then keep the network unchanged while switching only the route. Adjust routing mode next, and inspect the individual app last. Repeat the same access test after each change and record the result. Do not reinstall the client, change DNS, switch routes, and restart the router at the same time; that leaves no useful conclusion.

Keep the test targets consistent too. Choose one ordinary website, one website that requires an international route, and one frequently used app as fixed samples. Do not rely on a service that is under maintenance, requires a fresh login, or returns region-specific pages as your only test. If ordinary websites work but international sites fail, check rules and routes first. If both fail, check the system proxy and DNS. If websites work but the app fails, the problem is likely at the app layer.

Confirm account and service facts first

ZVVPN registration requires only a username and password—no email address. After signing in to the user panel, confirm that the plan or data package is still available, then obtain the current subscription. Monthly plans include different data tiers, with data resetting each month on the activation date. Data packages remain available until used and never expire. If the subscription status shown in the panel differs from the client cache, trust the user panel and import it again instead of repeatedly connecting with stale data.

Coverage includes 120+ countries / 170+ routes, with support for Windows, macOS, iOS, Android, and Linux. There is no device limit. An unlimited device count does not mean multiple proxy clients should run on the same device; competing clients can fight over the system proxy or virtual network interface and are a common source of conflicts. For plan details, see Plans and Data Rules. For regions and route types, see Global Route Guide.

How to diagnose a complete connection failure

Tell “the client will not open” apart from “the route will not connect”

A client that will not start, opens to a blank interface, or reports missing network permissions is a different problem from a route timing out after you click Connect. For the first group, check installation integrity, system permissions, and security policies. Only then move to network and route diagnostics. If the client can display the regions in the subscription but no route can establish a connection, the subscription has at least been read successfully. Focus first on whether the current network restricts the connection method and whether another client is occupying the network interface.

Fully quit other proxy clients, network filters, corporate access tools, and traffic-analysis utilities before restarting the ZVVPN client. Closing a window may not stop its background service, so check the system tray, menu bar, or process manager to confirm that related programs have exited. Keep the default rules, import no extra configuration, and test another route in a different region. If one route fails but another works, the client itself is functioning and the issue is route reachability. If all routes fail, switch the local access network.

Switch networks to test the local access layer

Home broadband, office networks, public networks, and mobile networks may use different egress policies. When connections fail, the most useful comparison is not cycling through many routes, but switching networks while keeping the client and subscription unchanged. If the connection works on another network, the original network may have a routing issue, gateway cache, enterprise policy, or local device configuration problem. Restarting the network equipment, obtaining fresh network settings, and checking the system clock are often more useful than reinstalling the client.

An incorrect system clock can affect secure session establishment. Set the date, time, and time zone to automatic synchronization, then fully quit and reopen the client. On managed devices, also check whether the organization installed network profiles or certificate policies. Do not delete management settings from a work device without permission; ask the network administrator what is allowed. On a personal device that previously had an older client installed, check whether an obsolete virtual network interface is still enabled.

Confirm permissions and the virtual network interface

On Windows and Linux, confirm that the client has permission to create a network interface and modify routes. On macOS, iOS, and Android, the system usually asks to add a network configuration on the first connection. After one refusal, the client may still let you click Connect even though the system will not create the interface. Open the system network or privacy settings and check whether the ZVVPN network configuration exists and is enabled. If duplicate configurations exist, quit the client first, remove only entries clearly belonging to an old installation, and request authorization again from the current client.

Validate the subscription and routes separately

A subscription can update successfully without every route being reachable from the current network. Likewise, one failed route does not mean the subscription is invalid. First check whether the client lists the routes, then review the update time or result, and finally test different regions separately. If the list is empty or the update reports an error, go to the subscription section. If the list is complete but every route fails, continue with network and permission checks. If only a few routes fail, use other routes for now and keep the failed route names for a support ticket.

Do not copy an expired subscription string from chat history or an old device over the current configuration. Retrieve it again from the user panel’s download or subscription entry and load it through the client’s import function. The sample address below is for understanding the format only and is not a real subscription:

https://example.com/sub?token=YOUR_TOKEN

After importing, start with the client’s default group instead of adding complex rules immediately. If the default configuration connects, restore personal rules gradually. This helps distinguish a service configuration issue from local customization. Treat the subscription link as a credential and keep it out of screenshots, public documents, and shared configuration repositories.

Connected, but websites will not open

A connected status does not prove traffic is using the route

When the client shows Connected, it usually means only that a session exists between the client and one route. Whether browser requests enter that session also depends on the system proxy, virtual network mode, browser settings, and routing rules. First open the client’s connection log or status page and keep it visible, then visit an ordinary website. If the visit creates no new log entry, browser traffic may not be reaching the client. If a request appears but is marked Direct or Rejected, check the rules. If it is forwarded but receives no response, inspect DNS and the route.

Some browsers allow their own proxy settings, and extensions may take over network traffic. Create a temporary browser environment without extensions and let the browser follow the system network settings. If that works, restore extensions one at a time rather than enabling them all at once. Browsers with a manually entered proxy address should also have the old setting cleared, so requests are not sent to a local port that no longer exists.

Verify DNS resolution and web requests separately

Web access has two stages: resolving a domain into an address, then sending a request to that address. Resolution failures often appear as “server not found.” Request failures are more likely to appear as prolonged waiting, a reset connection, or an abnormal certificate page. You can run the following general checks in a system terminal; the sample domain contains no account information:

nslookup example.com
curl -I https://example.com

If domain lookup fails while the client route remains stable, handle DNS first. If the domain resolves but the request fails, check the system proxy, route, and browser. If a command-line request works but the browser fails, the issue is more likely to involve a browser extension, cache, separate proxy, or security policy. Command-line tools vary by operating system, so you do not need to install another tool; two different browsers can provide the same comparison.

Check the routing mode and destination domain

Routing mode determines where requests go based on the domain, address, or app. Outdated rules, incorrect rule order, or custom entries overriding default rules can send a destination website through the wrong path. Temporarily switch to a mode that sends test traffic through the route, then reopen the page. If it works, the route and website are reachable and the fault lies in rule matching. After verification, do not leave test mode enabled permanently. Find the rule assigned to the domain, correct it, and restore your normal mode.

A webpage often loads its main domain alongside domains for static assets, authentication, and media. Adding a rule only for the main domain can leave the page frame visible while images, the login button, or the content area stays blank. The browser developer tools network list can show which domain failed, but do not share a complete request URL containing login parameters, session identifiers, or subscription data publicly. For a support ticket, keep the domain and redact query parameters.

Clear stale state after switching connections

After frequent switching between direct access and a proxy, the browser may retain old connections, DNS cache, or site sessions. Close all tabs for the target website, then quit and reopen the browser. If the problem remains, clear that site’s cache and site data instead of wiping all browsing history first. Clearing site data may require another login, so make sure the account credentials are safely stored.

When the system wakes from sleep, switches from wired to wireless, or moves between access points, old connections may continue using an invalid path. Disconnect the client first, wait for ordinary network access to return, then reconnect. Do not repeatedly click Connect before the system has a valid network; the client may create several incomplete sessions that make the logs difficult to interpret.

Verify the egress change without relying on one page

When confirming that a route is active, do not rely only on the client icon or a single website that may cache regional information. Compare egress details before and after connecting, and check whether DNS requests follow the expected path. See The Complete Guide to Checking Exit IP and DNS for the full method. If the egress has changed but the website still will not open, the issue is not that traffic completely bypassed the route; return to the rules, destination service status, and browser layers.

A destination website may return different results based on account region, browser storage, or content licensing. A correct route region does not guarantee that an old session changes immediately. You can sign out of the destination account, clear that site’s data, and sign in again, but do not repeatedly alter account details while troubleshooting. If multiple devices show the same result on one route and switching routes restores access, record the destination domain and route region for further route-side analysis.

Slow speeds and peak-hour lag

First determine whether the slowdown is local or on the international path

Speed issues require controlled comparisons. Disconnect the client and confirm that the current network can open ordinary websites and download regular content. Then connect to a route and repeat the same test with the same device, network, and destination. If direct access is already unstable, address wireless signal, the router, the broadband egress, or background system usage first. An international route cannot repair packet loss or interference in the local access layer; switching routes blindly only hides the real cause.

Wireless networks are especially sensitive to distance, obstructions, interference, and power-saving policies. During testing, move closer to the access point and pause cloud sync, system updates, video uploads, and other sustained bandwidth use. If possible, compare once over a wired connection. There is no need to chase a particular speed-test number; watch whether initial page load, sustained downloads, and video buffering improve together. Route comparisons only become meaningful after the local baseline is stable.

Keep the task consistent when comparing routes

Route selection is not determined by geographic distance alone. The paths from you to the entry point, from entry to exit, and from exit to the destination service all affect the result. Start with a geographically nearby region, then choose a route in the same region as the destination service and test the same task. After switching routes, end the old download or playback session and reopen the content so the old connection does not continue using the previous path.

If a route responds quickly for webpages but slows during sustained large-file transfers, the path may be stable while available bandwidth is limited. If downloads are acceptable but webpages pause frequently, packet loss, DNS delays, or connection reuse may be involved. If only video quality drops, also consider the platform’s bitrate, adaptive behavior, and regional detection. For streaming quality checks, read Why Video Quality Drops and How to Choose a Route.

Judge peak-hour performance over time, not from one result

Peak-hour lag usually follows a clear time pattern. When the problem occurs, keep the current route and compare it with a route in another region. Also check whether ordinary local network access worsens at the same time. If every route and direct task slows down, the local provider’s egress or home network deserves priority. If only a specific route degrades at fixed times, switch to another route and record the recurring time period and route name.

Do not judge stability by refreshing repeatedly for a short time. A page refresh may hit cache, and a speed-test page may select a different target each time. It is more useful to watch a full video, sustained download, remote meeting, or continuous AI Tools conversation for recurring pauses. Keep the test close to real usage, but do not run several high-bandwidth tasks at once or you will not know which one affected the others.

Check the protocol, mode, and device performance

Different connection methods behave differently depending on system resources, network conditions, and routing policies. If the client offers multiple connection methods, compare them one at a time after the default configuration fails, and record each result. Low-performance hardware, a system that has not been restarted for a long time, and many background network filters can also make encryption and forwarding the bottleneck. Closing unrelated programs and restarting the client is often more effective than repeatedly changing routes.

When a router forwards traffic for the whole home, its processing capacity, firmware network stack, and rule complexity directly affect speed. If a single-device client works normally but the whole-home setup is noticeably slower, locate the issue in the router rather than the route. See Real-World Comparison of Whole-Home Acceleration Setups to weigh firmware requirements, routing maintenance, and device load.

Data status can also affect the diagnosis

Monthly plan data resets each month on the activation date. Plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. When upgrading mid-cycle, the price difference is prorated across the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. If a connection suddenly stops or a task cannot continue, confirm the current status in the user panel before mistaking plan status for route-speed fluctuations.

If you need to change plans, review the original rules on the Plans page. Payment methods are Alipay, WeChat Pay, and USDT, with a 7-day no-questions-asked refund policy. Do not change plans based on one speed test alone. Confirm the local network, destination service, and route differences first, then consider a different tier only when your data needs have changed.

Frequent disconnects and automatic reconnects

First note what happened immediately before the disconnect

Frequent disconnects do not have a single cause. Sleep, screen lock, wireless switching, system updates, router redialing, and the client being stopped in the background can all interrupt a session. Do not record only “it disconnected again.” Note what happened beforehand: did the device just wake from sleep, move between access points, switch between wired and wireless, or start a high-volume transfer in an app?

If the connection fails after every wake-from-sleep event but remains stable during normal use, check the order in which the system restores networking and the client’s automatic reconnect behavior. If it disconnects regularly while idle, check power saving, background restrictions, and the route. If it disconnects only while moving, network switching is more likely. Once the trigger is clear, reproduce it with the same action instead of waiting for an intermittent failure.

Re-establish the session after a network change

When a device switches from the home network to another network, its local address, default gateway, and egress path all change. An old session usually cannot move directly to the new path, so the client must detect the change and reconnect. If the client still shows Connected but access fails, disconnect it manually, confirm that ordinary network access has returned, and reconnect. Do not repeatedly toggle the client during the switch, or the system may retain several temporary interface states.

In environments with multiple wireless access points, a device may roam repeatedly when signal levels are similar. The wireless icon may look unchanged even though the underlying connection has switched. Test temporarily while staying near one access point, or compare another network. If the fixed environment is stable and disconnects occur only while moving, improve local wireless coverage and roaming before changing remote routes.

Close programs that compete for the network interface

Multiple proxy clients, corporate access software, filtering tools, and virtual-machine network components may modify routes at the same time. They may not appear in the foreground, while background services can still rewrite system settings when the network changes. During troubleshooting, keep only one client active and confirm that related processes have exited. If stability returns after closing a conflicting program, decide which tool to keep for daily use rather than letting several tools overwrite one another based on startup order.

Browser extensions usually do not disconnect the underlying session, but they can create the impression that “every website suddenly stopped working.” To determine whether the connection truly dropped, check the client status and another app at the same time. If the client still shows normal requests and only the browser fails, return to browser settings. If every app stops at once and the client status changes, it is a connection-layer disconnect.

Power-saving and background policies can terminate connections

Laptops and mobile devices may restrict network activity after the screen turns off to save power. Allow the ZVVPN client to run in the background and avoid modes that actively clear background processes. Permissions may also need to be confirmed again after a system update. If disconnects always occur after the screen locks, check background permissions first, then whether the client supports automatic reconnect. Do not disable the device’s entire security lock just to keep a connection; adjust only the background network settings for the client.

Desktop systems may also power down idle wireless adapters or virtual network interfaces. Check power and network settings for energy-saving options, and compare operation while plugged in and on battery. If interruptions occur only on battery, power management is more likely. If both states behave the same, inspect the route and network.

Use logs to distinguish an active close from a timeout

The exact error text in the client log is more useful than a generic “connection failed” message. An active close often accompanies sleep, an interface shutdown, revoked permission, or user action. A timeout is more often linked to an unreachable network or interrupted route response. Authentication or subscription errors belong in the subscription section. When copying logs, keep only the relevant lines before and after the failure, and redact subscription links, tokens, and account details.

If the log is very large, clear only old entries that can be safely removed, reproduce the failure once, and export the log immediately. Keep the reproduction simple—for example, leave one fixed webpage open, then lock the screen, switch networks, or trigger sleep in the known way. A clear timeline makes it easier for support to determine the order of system events and the disconnect.

Subscription update failures and configuration errors

First determine whether the subscription cannot download or cannot be parsed

Subscription updates usually fail at one of two stages: the client cannot retrieve the subscription, or it retrieves the content but cannot parse it. The first often appears as a failed network request, invalid address, or timeout. The second may appear as a configuration format error, empty content, or an unsupported field. The troubleshooting order differs: for a download failure, check the current subscription entry in the user panel and the local network. For a parsing failure, check the import method, client type, and remnants of an old configuration.

Do not edit characters in a subscription link manually or extract the link from a screenshot. Copying can introduce spaces, line breaks, or punctuation, especially after passing through a chat app. Use the copy or import entry directly in the user panel and create a new subscription item in the client. If the new item works, remove the old one afterward; do not delete the only working configuration before you have a comparison.

Confirm the current account status and subscription source

ZVVPN registration requires only a username and password—no email address. If multiple usernames are saved on the device, first confirm that the signed-in account owns the active plan or data package. Similar usernames, an old browser session, or a client still using another account’s subscription can make the panel and client disagree. Sign out of the user panel, sign in again, and retrieve the subscription from the current page to reduce account mix-ups.

A subscription address is sensitive credential data and should not be shared through public screenshots, forum attachments, or shared documents. If you suspect it has been exposed, use the available security-management function in the user panel and import it again. A support ticket does not need the full subscription address; provide the update error, client platform, and exact error text. If account verification is needed, support should handle it through the ticket context rather than requesting public credentials.

Clear stale cache instead of stacking imports

Importing the same subscription repeatedly can create several groups with identical names, while the client continues using the old group and makes the update appear ineffective. Record the source of the currently selected group, trigger an update manually, and check whether the route list changes. If duplicate subscriptions are clearly shown, keep the item just imported from the panel, disable the old one, and test. Remove the old item only after the new one is confirmed usable.

Some clients cache the last successfully updated content. When the current download fails, the list may remain visible even though its update time has not changed. Do not treat “the routes are still visible” as proof of a successful update; check the update result or log. If cached routes still connect, you can use them temporarily while investigating the update request. If the cache also fails, check both account status and network.

Use a basic network to verify the subscription request

A subscription update is itself a network request. If the current system proxy is broken, the client may try to update its subscription through the faulty proxy, creating a loop. Disconnect first so the system returns to ordinary network access, then update the subscription; alternatively, try another working network. If the update works while disconnected, the subscription address is valid and the problem is the current proxy or rules. If it still fails on another network, verify the panel entry and client import method.

A browser opening the user panel does not guarantee that the client can download the subscription, because they may use different network paths and certificate environments. Conversely, a successful client update does not prove that the browser proxy works. Record the update test separately rather than combining it with website access results.

Restore custom configuration from the smallest possible set

If the default subscription parses correctly but adding personal rules causes an error, reduce the custom content to the minimum and restore it section by section. Common issues include inconsistent indentation, duplicate fields, rules referring to nonexistent groups, and invisible characters in the text. When a configuration is sensitive to spaces and hierarchy, use a plain-text editor instead of a rich-text editor and keep a copy from before the changes.

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
test-domain: example.com

The example above is structural only. It is not a complete configuration for any client and contains no real credentials. In actual use, follow the client’s built-in import flow and do not assemble this service’s subscription content manually. If the client reports unsupported fields, return to the import entry designed for that client instead of repeatedly editing the service subscription.

Separate plan status from client errors

Monthly plan data resets each month on the activation date. Data packages remain available until used and never expire. When upgrading mid-cycle, the price difference is prorated across the remaining days. If the panel status is unexpected, review the plan rules and order record before submitting a billing ticket. A client parsing error cannot be fixed by paying again, and a normal billing status cannot repair a local format error; handle the two issues separately.

This service supports unlimited devices, but each device should use a valid subscription obtained from the current account, and it should not be shared publicly. An unlimited device count does not remove the need to protect the subscription. If import fails on a new device, first confirm on a working device that the panel entry is still available, then compare the clients and import methods used on both devices.

When one app bypasses the proxy or drops in the background

If websites work but an app fails, check the app’s network model first

If the browser works but one app does not, the underlying route is usually not completely broken. The app may use its own proxy setting, a fixed network interface, special domains, long-lived connections, or requests that ignore the system proxy. Watch the client while launching the app and check whether any requests appear. If there are no records, the app traffic may be bypassing the current proxy mode. If requests appear but are marked Direct, check routing rules. If they use the route but return an error, inspect the region, cache, and account status.

Before testing, fully terminate the app process instead of simply returning to the desktop or home screen. Many apps retain old connections and continue using the previous path after a route switch. End the process, reopen the app, and perform the same action. If the service has a web version, open it in a browser for comparison. If the web version works but the client app fails, focus on the app. If both fail, return to the route, DNS, and destination service.

Use a temporary global test to locate a routing error

In rule-based mode, an app may access several secondary domains while only some requests match correctly. Temporarily send all test traffic through the route and restart the app. If it works, the route can communicate with the app’s service and the problem is rule coverage. Check the domains and matched rules in the client log, add the necessary domains to the correct group, and restore your normal mode. Temporary global mode is for diagnosis, not a replacement for a clear long-term routing setup.

Do not infer every domain from the app name. Login, content, images, updates, and push notifications may use different domains, and those domains can change after an app update. Recording the new requests generated when the failure occurs is more reliable than copying a complete rule set of unknown origin from the internet. After adding rules, verify login, content loading, and uploads one by one instead of checking only whether the home page opens.

In-app proxy settings may override the system path

Some desktop apps offer Follow System, No Proxy, or manual proxy options. If a local address was entered previously, the app may keep trying to connect to that old address even after ZVVPN takes over the system proxy. Prefer Follow System or automatic mode during troubleshooting, and clear obsolete manual settings. Fully restart the app afterward so it reads the network settings again.

Command-line tools and development environments may also read proxy environment variables. An old variable can keep sending requests to another local port. Check proxy-related environment variables in the current terminal, but do not paste a complete environment containing credentials into a support ticket. For verification, open a new terminal without custom startup scripts and run a standard request. Also inspect project-level settings in development tools, since they can override system and terminal settings.

For mobile background disconnects, check system scheduling first

Mobile systems restrict background activity after the screen turns off, especially during power-saving, low-battery conditions, or long periods without opening the app. Allow the ZVVPN client to run in the background and prevent automatic suspension. Setting names vary by device, but the comparison is the same: test with the client in the foreground, then repeat after locking the screen. If the foreground is stable but the background disconnects, focus on system scheduling. If both fail, check the route and network switching.

Do not enable multiple apps that use the system network configuration at the same time. Mobile systems generally allow only one such connection to remain active, so launching another client may replace the current connection. If the status-bar icon disappears or the client says another service has taken over, quit the conflicting app and reconnect. If the problem remains after restarting the device, remove only network configurations clearly belonging to an old client, keep the current one, and confirm its name.

Push, voice, and real-time connections need a continuous path

Instant messaging, voice calls, remote desktops, and online collaboration rely on long-lived connections. Network changes, background suspension, and route changes all require the session to be rebuilt. If text messages work but calls disconnect easily, test on a fixed network and temporarily disable policies that automatically switch routes. If only push notifications are delayed, check app notifications and background permissions instead of assuming a route failure.

AI Tools may use both ordinary web requests and continuous output connections. If the page opens but an answer stops midway, first check whether the local network changed, the browser entered a sleep state, or the route is unstable, then compare another route in the same region. Do not refresh the page, switch routes, and sign in again in the same test; otherwise you cannot distinguish an expired session from a network interruption.

DNS issues, device conflicts, and support tickets

Recognize the typical signs of a DNS problem

DNS problems often appear as unresolved domains, long waits before the first page opens, intermittent “server not found” messages, or local-network resolution results after connecting to a route. Unlike a completely unreachable route, the client may remain connected and apps using cached addresses may continue to work while newly opened domains fail. Test domain lookup and web requests separately to identify the failing stage.

Disconnect the client first and confirm that domains resolve normally on the ordinary network, then reconnect and repeat the same lookup. If resolution works while disconnected but fails after connecting, check the client DNS mode, system network settings, and custom rules. If both states fail, repair the local network first. Do not specify multiple conflicting DNS sets in the system, browser, client, and router at once; that makes the request path difficult to identify.

Clear stale resolution state and rebuild the network

After switching networks or routes, the system and browser may continue using old cache entries. Quit the target app, disconnect the client, wait for ordinary network access to return, and reconnect. If the system offers a DNS-cache clearing function, use the built-in method. If you are unfamiliar with commands, restarting the network connection and app can also provide a clean comparison. Do not copy commands with system-modification privileges from unknown scripts.

A browser with its own secure DNS setting may not follow the system or client configuration. During troubleshooting, temporarily let the browser follow the system settings and check whether the issue disappears. If it does, choose a long-term setting based on what the client supports. DNS on managed devices may be controlled by organizational policy and should not be changed without approval; pass the failed lookup details to the network administrator.

Unlimited devices do not prevent configuration conflicts

ZVVPN supports unlimited devices, so the current account can be used on Windows, macOS, iOS, Android, and Linux. Each device still has its own client, permissions, cache, and network environment. If one device works and another fails, do not assume an account device limit. Compare the subscription update time, client mode, local network, and system proxy on both devices.

Running multiple clients on one device is different from using the service on multiple devices. The former may compete for the system proxy and virtual network interface; the latter does not share local configuration. When devices behave differently, connect the failing device to the same network used by the working device and test a route in the same region. If the result remains different, the device is more likely responsible. If it changes with the network, inspect the access environment.

When to stop local trial and error

After checking the basic network, other routes, system permissions, subscription updates, and DNS, submit a support ticket if the issue remains reproducible. This is especially important when the same error appears on multiple devices, networks, and route regions. Reinstalling and clearing cache again usually adds no useful information. The purpose of a ticket is not to prove that many fixes were attempted, but to provide a path support can reproduce and assess.

Handle billing and refund questions directly through a support ticket. The service terms state a 7-day no-questions-asked refund policy; follow the Refund Policy for the actual request. Payment methods are Alipay, WeChat Pay, and USDT. For order issues, include the status and payment method visible on the order page, but do not submit payment credentials, complete transaction keys, or unrelated account material.

What an effective support ticket should include

Write the symptom directly in the subject, such as “Subscription updates, but every route fails to connect” or “The system terminates the connection after screen lock.” In the body, list the platform, network type, exact client error text, failed route name, destination website or app, the action being performed when it first occurred, and the comparisons already completed. State any difference after switching networks or routes.

Include only the log lines around the failure. Screenshots should show the client status and error, but redact the username, complete subscription address, tokens, sensitive order details, and other personal information. Do not send a cropped red warning with no context or upload a full screen of unrelated chat history. Exact error text is usually easier to search than an image, so copy it separately as well.

Keep a minimal record after recovery

After the issue is resolved, record the final effective action and the key symptom before recovery. For example: “It recovered after closing the duplicate client,” “The route list updated after reimporting the subscription,” or “The connection stayed up after allowing background operation.” There is no need to keep complete sensitive logs, but retain the issue type and solution path. If a similar symptom appears later, you can test the same branch first instead of changing every setting from scratch.

If the reason for recovery is unclear, undo unrelated changes step by step and confirm which settings are actually needed. Accumulated temporary rules, manual DNS settings, and duplicate subscriptions make future problems harder to diagnose. A stable configuration is not necessarily the one with the most options; it has a clear network path, a known subscription source, one client responsible for the connection, and an explainable purpose for every customization.