VPNZe Troubleshooting Guide

DIAGNOSIS BASELINE

Establish a troubleshooting baseline

Turn symptoms into testable statements

“The network is bad” does not point to a specific fix. Rewrite the issue with its scope, timing, and action—for example: the client cannot complete a connection; the client says Connected but no websites open; only one app fails; performance is normal during the day but lags at peak hours; switching to a mobile network restores access; or subscription updates fail while old routes still connect. The more specific the description, the easier it is to identify whether the problem is at the entry point, route, system, or destination service.

Also determine whether the failure is constant or intermittent. Persistent failures usually involve configuration, permissions, subscription status, or the network environment; intermittent failures are more likely related to temporary route instability, system sleep, network switching, or app caches. Do not draw conclusions from a single failure. Repeat the same action without changing settings and check whether the error message is consistent. If the message changes each time, check local network stability before reinstalling the client.

Divide the problem into layers

Prepare a minimal test environment

Reduce sources of interference while troubleshooting. Keep one client, one browser window, and one route under test; pause sync, downloads, and updates that continuously use the network. If multiple proxy clients are installed, exit the others first so they do not compete for the system proxy or virtual network interface. Browser extensions may also rewrite proxy settings, so retest in a separate window without extensions, but do not erase all personal data as a first step.

Test destinations in layers as well. Start with a regular webpage that is normally stable, then test services that require sign-in or depend on a particular region. If ordinary pages already fail, there is no reason to troubleshoot a streaming account or app region settings first. If ordinary pages work but one destination fails, the scope narrows to the destination service, app routing, account region, or exit route rather than the connection as a whole.

Record the pre-change state

Before switching modes or changing DNS, record the full route name, client mode, system network type, exact error text, and time of occurrence. Screenshots should include key status information but hide subscription content and access credentials. Do not paste a subscription URL on a public page or include a password in a ticket. VPNZe registration requires only a username and password, with no email address; support only needs information that reproduces the issue, not login credentials.

If the issue began after a client update, network switch, or system sleep, record the triggering action too. The trigger is often more useful than the final error. For example, if failure begins after waking from sleep and restarting the client restores access, check virtual-interface rebuilding first; if it begins after a network switch, check the old connection and DNS cache; if the route list becomes empty after changing subscriptions, check the subscription retrieval process first. A baseline is not extra work—it prevents intermittent issues from being misclassified as lasting failures.

CONNECTION FAILURE

How to troubleshoot when you can't connect at all

Distinguish “the client did not start” from “the route handshake failed”

A total connection failure usually has one of two similar-looking causes. In the first, the client core is not running correctly: it stops soon after launch, the system proxy toggle has no effect, virtual networking cannot be established, or the interface repeatedly reports a permissions issue. In the second, the client itself is working but the selected route cannot establish a session, leaving the connection process hanging, timing out, or returning a route error immediately. Check local permissions and software status for the first case; investigate the route and network environment for the second.

Exit the client completely, reopen it, and watch for the first abnormal message during startup. Do not focus only on the final error; later messages may be cascading results of the initial failure. If the client asks to create a system network configuration, follow the system prompt to authorize it. If authorization already exists but the state is abnormal, disconnect and exit the client before entering again instead of repeatedly clicking Connect. Rapid repeated clicks can start a new session before the old one is released.

Verify the basic network entry point

After disconnecting the acceleration connection, confirm that the current network can open common pages. If the basic network itself is unavailable, restore the router, wireless access, or wired connection first. If the local network requires a webpage confirmation before going online, complete that confirmation while the client is disconnected. Such entry pages often rely on local redirection and may not appear correctly when the system proxy is enabled, so do not mistake an incomplete entry step for a route failure.

Once the basic network works, test another route in the same client. Prefer a route in the same region but with a different route type to reduce regional differences. VPNZe offers 100+ countries and 250+ routes; the routes page identifies IEPL dedicated lines, relay, and direct connection types. For comparison, open the global routes page for type descriptions. If another type in the same region connects, the client and subscription are probably working; focus on the original route or the path from the current network to it.

Check whether the subscription still contains valid content

An old route name in the client does not prove that the subscription is current. First check whether the subscription updated successfully, then confirm that the route list was not restored from an old cache. If the update fails, do not immediately delete the existing configuration; keeping it helps determine whether “the subscription cannot be retrieved” and “the route cannot connect” are separate issues. See the dedicated subscription-update procedure later. If the panel shows a plan status that needs attention, open the account overview instead of repeatedly importing the same old link.

If the subscription updates, the route list is complete, but no route connects, compare results across different access networks. The purpose is not to keep changing networks, but to determine whether the failure occurs only at the current entry point. If another network connects, the client and account usually have no fundamental problem; return to the original network and check proxy restrictions, DNS interference, gateway rules, or leftover sessions. If every access environment shows the same error, focus on the client core, system time, subscription content, and the first abnormal log entry.

Clear leftover state instead of reinstalling blindly

After a connection is forcibly interrupted, the system proxy, virtual network interface, and client process may fall out of sync. A safe order is to disconnect in the client, exit it, confirm that the system proxy has been restored, and then restart. If virtual networking behaves abnormally, switch temporarily to regular system-proxy mode for comparison. If regular mode connects, the route itself is available and the issue is concentrated in the virtual interface, permissions, or system network stack; do not keep switching routes.

Reinstall only after confirming damaged client files or a client core that cannot start. Before reinstalling, save necessary non-sensitive settings and confirm that the client and subscription can be retrieved again from the user panel. Do not download a program with the same name from an unknown page or import a configuration from an untrusted source. VPNZe supports Windows, macOS, iOS, Android, and Linux; client downloads are centralized in the user panel download area.

When to stop troubleshooting on your own

If different networks and route types all fail, while the logs continue to show the same handshake or authentication error, submit a ticket. Include the client platform, connection mode, full route name, time of occurrence, exact error text, and the results of “basic network works, another route tested, client restarted.” Do not write only “it won’t connect,” and do not send multiple screenshots without context. Support needs to know which step each screenshot represents to determine whether the issue is on the route side or in local configuration.

WEB AND DNS

Connected but websites won't open: DNS issues

First determine whether the problem affects the browser or the whole system

When the client says Connected but websites will not open, compare with another browser or a built-in system network tool on the same device. If only one browser fails, check its independent proxy, encrypted DNS, extension rules, and long-lived cache. If every browser fails, verify that the system proxy was actually written. If the browser works but other apps fail, go to the “App routing” section instead of spending too much time on DNS.

The wording on a browser error page matters. An unresolvable domain, connection timeout, certificate error, and reset connection point in different directions. Start with the DNS path for an unresolvable domain; a timeout is more likely related to the route, destination, or routing rules; for a certificate error, verify the system time and destination domain; for a reset connection, compare routes and network entry points. Do not classify every error as “the route has failed.”

Use commands to distinguish resolution from access

You can run resolution and response checks against a public test domain. The commands below contain no subscription information and do not change system settings. Command names vary by platform, but the goal is the same: first check whether the domain returns a resolution result, then check whether an HTTPS request can receive a response. Use command output only for diagnosis; it does not reveal the destination service's account status.

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

If the resolution command fails while route tests or other address-based connections in the client still respond, the issue is more likely DNS. If resolution succeeds but the HTTPS request times out, continue checking the system proxy, routing rules, and destination route. If the command line works but the browser fails, check the browser's own proxy and DNS settings first. If both fail, test the same way with another route and see whether the failure follows the route.

Why DNS can fail even when the connection says Connected

Domain resolution may use the system's default DNS, the client's built-in DNS, a virtual network interface, or the browser's independent DNS. When several paths coexist, the common issue is not “there is no DNS,” but that queries use a different exit path from the traffic, or an old cache retains a result unsuitable for the current route. After a network switch, wake from sleep, or client-mode change, an old DNS cache is especially likely to remain active.

Start with low-impact actions: close and reopen the affected browser window; disconnect and reconnect in the client; confirm that the browser is not forcing an independent resolver that conflicts with the current environment; only then clear the system DNS cache if necessary. Clearing the cache merely makes the system query again; it does not fix incorrect proxy rules. If access returns briefly after each clear and then fails again, inspect the DNS path instead of repeatedly clearing the cache.

Check the system proxy and virtual network mode

Regular system-proxy mode depends on apps actively reading the system proxy settings. Some command-line tools and standalone apps do not inherit them, so the browser may work while the command line fails. Virtual network mode takes over traffic at a lower level but depends on system permissions and interface state. If switching modes makes the issue disappear, the route itself is probably available and the difference lies in how traffic is intercepted. Keep the working mode and investigate proxy inheritance or permissions in the original mode instead of repeatedly switching regions.

Also check for a manually configured proxy address in the system. If the client has exited but the manual proxy still points to a stopped local port, every webpage may fail. Restore automatic settings or let the client manage them, then try again. Do not copy ports and addresses from random network tutorials; each client may listen locally in a different way. When checking the settings, use the values displayed by the current client.

When only a specific domain fails

If most websites work but one domain fails, compare its web and app versions on the same route, then retest with another route in the same region. A specific service may return different results based on exit region, account region, sign-in status, or cache. DNS is only one possible factor. Clearing that site's local cache is usually safer than wiping the entire browser, and you should verify that the entered address is the official domain rather than a redirect or an old bookmark.

If the issue occurs only on one route, include the full route name, failed domain, exact browser error, and comparison route in the ticket. If several domains fail to resolve, attach the resolution command result. Hide any local username or directory path in the output before sharing it. Do not submit the subscription URL; support does not need subscription credentials to assess the DNS path.

SPEED AND PEAK HOURS

Slow speeds and peak-hour lag

First define which action is slow

A slow first page load, video buffering, slow file transfers, meeting jitter, and interrupted AI Tools responses should not be judged the same way. Webpages care more about connection setup and small-request latency; video depends on sustained throughput and regional availability; meetings depend more on jitter and packet loss; file transfers are easily affected by per-connection limits and the destination server. Choose a test action that matches your real use instead of letting one speed-test page stand in for the entire experience.

Pause background sync and updates during testing. Keep the local network, client mode, destination service, and steps fixed; replace only the route. Let each test run long enough to show a stable trend rather than switching as soon as a page opens. If the local Wi-Fi connection is unstable, it will amplify route differences. Move closer to the access point or use a stable connection for comparison, but do not treat temporary test conditions as a service-speed guarantee.

Narrow the scope by region and route type

In general, start with a route near the destination service and with a sensible path from the local entry point. Distance is not the only factor, but crossing more network paths often adds uncertainty. For region-specific content, choose the corresponding region first; when region does not matter, compare nearby regions. Route type matters too: IEPL dedicated lines, relay, and direct connections have different path structures and may perform differently across access environments.

A useful comparison is not randomly switching among many countries, but comparing different types in nearby regions or nearby regions within the same type. This helps distinguish the effects of exit region, route type, and the destination service. The nodes page lists regions, cities, route types, and streaming labels. Filter first in Global Routes, then test in the client. Do not make absolute judgments from words such as “dedicated” or “direct” in a route name; the current access environment and actual use remain decisive.

Handle peak-hour lag

If performance is stable during the day but clearly degrades at peak hours, first check whether the local access network also slows at the same time. Disconnect the client and access familiar content to see whether the basic network shows latency or packet loss as well. If the basic network is affected, changing routes can only partly help; if it is normal while one route slows, compare different route types in the same region and record the time window.

Peak-hour issues often appear as sustained throughput decline or intermittent pauses. The former is more obvious when increasing video quality or continuously transferring a file; the latter is easier to notice in meetings, games, or short requests. Describe these separately in a ticket. “Peak hours don't work” does not show whether the issue is low sustained throughput, intermittent jitter, or destination congestion. State which actions are affected, whether every route is affected, and which route type changes the result.

Avoid letting the test method distort the conclusion

Different speed-test targets sit on different networks, so their results cannot represent every website. Browser-based tests are also affected by page scripts, extensions, device performance, and concurrent connections. A more useful approach is to compare real tasks: does the same video play continuously at the same quality; does the same file transfer steadily from the same source; does the same meeting environment still reconnect frequently? Speed tests can help, but should not be the only evidence.

Do not run several speed tests at once. Concurrent tasks compete for bandwidth and can make a route look worse than it is. Close the pages after testing to prevent background transfers. If the client shows connection logs, check whether reconnects or route changes occur during lag, but do not draw conclusions from one instantaneous event. Stability requires comparing timing and repeated behavior.

Check device resources and mode

Power-saving state, busy background tasks, an abnormal virtual network interface, or deep traffic inspection by security software can all reduce speed. Close unnecessary tasks first, then compare regular system-proxy and virtual network modes. If one mode is stable while the other continually lags, the difference is more likely in the local traffic-processing chain. Keep the working mode and note the difference in a ticket; that is more useful than simply asking for a “faster route.”

If only one app is slow while the browser and other apps work, go to the App routing section. If every app is slow on every route while the basic network is normal, submit the route and environment details. VPNZe monthly subscription traffic resets each month on the activation date; check the panel if you need to verify plan status. Do not consume large amounts of traffic through repeated speed tests, and do not confuse remaining plan traffic with the performance of one route.

DISCONNECTION AND SLEEP

Frequent disconnects and mobile background drops

Identify when the disconnect occurs

For frequent disconnects, first find the trigger. Common triggers include device sleep, screen-off, switching between Wi-Fi and mobile networks, recovering from a weak-signal area, the client entering the background, and power-saving policies. If it happens after the same action every time, it is easier to locate than a random disconnect. Record the last action before the drop, not just the state seen after reopening the app.

If the device disconnects while idle but stays stable during active use, check background permissions and power-saving policies first. If it happens only after a network switch, check whether the client can establish a new session and whether the old virtual interface was released. If it disconnects repeatedly without an obvious trigger, compare another route in the same region to see whether the issue follows the route. These three cases require different priorities.

Mobile background policies

Mobile operating systems pause apps based on battery, memory, and background activity. After the client enters the background, the interface may still say “Connected” even though the system has reclaimed the actual session. When returning to the foreground, check whether the client reconnects automatically, whether the network indicator in the status bar returns, and whether the destination app needs to send its request again. Do not assume the app is still running merely because its card remains in the task list.

In system settings, allow the client the background activity it needs and avoid placing it under overly restrictive power-saving rules. Menu names vary by system, so look for settings related to “background activity,” “network connection,” and “power-saving restrictions” rather than relying on a fixed path. After changing them, lock the screen and resume to repeat the action that used to trigger the disconnect. If the issue stops, the trigger is confirmed; if it continues, check routes and network switching.

Handle stale sessions after a network switch

When a device switches from one access network to another, its local address, gateway, and DNS path all change. An old session may not be reusable, so the client must establish a new connection. If every page stalls after the switch, disconnect and reconnect in the client first instead of immediately clearing the configuration. If reconnection restores access, the subscription and route remain valid; the issue is concentrated in session recovery after the network change.

If every network switch requires a device restart, inspect virtual network mode. Temporarily use regular system-proxy mode for comparison; if it recovers normally, focus on the virtual interface state. Conversely, if certain apps fail after switching only in regular mode, they may not have reread the system proxy. Include this mode difference in the ticket to reduce repeated questions from support.

Distinguish a route drop from an app freeze

An app that does not load after returning to the foreground does not necessarily mean the route has disconnected. Open a regular webpage in the browser first. If the browser works, the system connection is still active and the app is more likely holding an old connection, DNS result, or session. Fully exit and reopen the app; this is usually more targeted than switching routes. If every app fails, return to the client and check its connection status and logs.

Video and meeting apps are especially likely to keep long-lived connections. After a network change, an old connection may not rebuild promptly, leaving the picture frozen or messages stale while newly opened webpages work. Restart the target app to verify. If that does not help but switching routes does, record the original route and destination service; if restarting the client is what restores access, record the client mode and trigger.

Desktop sleep and wake

After a desktop sleeps, the network interface and client core may recover in different orders. After waking, do not immediately switch routes repeatedly. Wait for the basic network to return, then check the client status. If the system proxy is still enabled while the client core has not recovered, every webpage may temporarily fail. Reconnect in the client first; if that does not help, exit it, confirm that the system proxy is restored, and reopen it.

If sleep-related failures persist, compare regular proxy and virtual network modes and inspect the first post-wake abnormal log entry. Capture only the portion near the failure, not the entire history file. Hide local directories or account identifiers before sharing. When contacting support, “stable during continuous use, fails after sleep and wake” is more precise than “disconnects sometimes.”

A comparison path for random disconnects

When there is no clear trigger, hold one route steady and observe; after a disconnect, switch to another type in the same region. If the disconnect follows the original route, submit its details; if every route disconnects, compare the access network and client mode; if it happens on only one device, check that device's permissions, power-saving settings, and system network state. VPNZe supports unlimited simultaneous devices, so focus on abnormal sessions or client state rather than guessing a fixed device limit.

SUBSCRIPTION UPDATE

Subscription update failures and abnormal route lists

Protect the working configuration first

When a subscription update fails, do not delete the existing configuration first. If the old configuration still connects, it remains a useful comparison and shows that the client core and local permissions are broadly working. Deleting it turns “update failed” into “no routes are available.” Record the current configuration name and last working state, then run the update separately.

If the client supports multiple configurations, keep the old one and create a test configuration. If it does not, first confirm that you can sign in to the user panel and retrieve the subscription again. Subscription content is account-delivery information and should not be pasted into public tools, search boxes, or third-party checkers. An example format is for understanding structure only and cannot replace the real content generated by the panel.

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

Determine whether it was “not retrieved” or “could not be parsed”

Update failures generally occur during the request or parsing stage. During the request stage, the client cannot obtain a subscription response; common signs include a timeout, network error, or access denial. During parsing, a response may have arrived but its format is not accepted by the current client, producing an invalid configuration, empty route list, or field error. The evidence differs: preserve the exact network error for the first case, and the parsing message and client type for the second.

Confirm that the basic network works, then try updating in the client. If the client needs the current route to access the subscription and that route has failed, a dependency loop may result. Disconnect and update over the basic network first; if that cannot complete, retrieve it again through the user panel. Do not click Update repeatedly across different networks, or you will not know which request produced the result.

Retrieve it again instead of manually repairing the subscription URL

A subscription URL may contain account-identifying information. Do not delete or alter characters manually, and do not apply another site's format. Sign in to the account overview to confirm service status, then retrieve the current content from the panel's download or subscription entry. VPNZe requires no email address; registration uses a username and password. If you have forgotten or confused the username, follow the existing panel process instead of creating multiple accounts to test the same subscription.

When copying, avoid including leading or trailing spaces, line breaks, quotation marks, or extra text added by chat apps. If the client supports scanning and pasting, choose the method less likely to corrupt the content. After pasting, first confirm that the configuration name appears, then update it. If the import succeeds but the route list is empty, record the client message; do not append parameters to the subscription URL yourself.

When the update succeeds but the content does not change

Sometimes the client reports a completed update but still shows old routes. The cause may be a cache, an unselected configuration, an unrefreshed interface, or an update applied to another configuration with the same name. Confirm the currently active configuration, then close and reopen the configuration page. If several names look alike, temporarily rename the test configuration to distinguish it, but do not edit route fields.

If the route list contains entries but selecting one still points to the old route, disconnect the current session, switch the configuration and route, then reconnect. Some clients retain the existing connection until its session ends, so changing the list selection alone may not immediately change the active exit. Retesting through the full disconnect-select-reconnect sequence prevents the interface choice from getting out of sync with the actual session.

Platform differences

Submit a subscription issue ticket

Include the platform, client type, update method, exact error, time of occurrence, and whether the old configuration still connects. If the update succeeds but the route list is empty, describe the configuration name and interface behavior. Screenshots with sensitive content hidden are acceptable, but do not attach the subscription URL, password, or complete configuration file. Support needs to assess delivery status and compatibility, not take over the account.

If the issue involves plan status, include what the panel shows. Monthly plans are ¥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 charges the difference based on the remaining days. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire. Troubleshoot based on the actual plan shown in the panel; do not calculate the remaining period yourself.

APPLICATION ROUTING

What to do when a specific app doesn't use the proxy

First prove that the system connection still works

When an app cannot access a service, open a regular webpage in a browser on the same device and route. If the browser also fails, return to the Websites and DNS section; if it works, the route and basic proxy are at least partly functional, narrowing the scope to the target app, routing rules, proxy inheritance, and app cache. Do not delete the entire subscription because one app fails.

Then compare the service's web and app versions. If the web version works but the app fails, common causes include the app not reading the system proxy, retaining a session created before the connection, using an independent network interface, or being classified as direct by a routing rule. If both versions fail only for one service, check the route region, destination service status, and account region.

Understand system-proxy and virtual network modes

System-proxy mode applies only to apps that actively follow system settings. Browsers usually do, but some apps, command-line tools, games, and software with their own network stack may ignore them. Virtual network mode takes over traffic at a lower level and usually covers more apps, but requires system permissions and is more affected by security software, routing tables, and sleep recovery.

The clearest comparison is to keep the route unchanged and switch only the traffic-capture mode. Disconnect before switching, reconnect afterward, then fully exit and reopen the target app. If the app works in virtual network mode, the original issue is more likely proxy inheritance; if both modes fail, continue with routing rules, DNS, and the destination service. Do not change the route at the same time, or you will not know which change helped.

Check what the routing rules matched

Rule mode decides whether traffic uses the proxy or a direct connection based on domains, addresses, apps, or rule sets. A destination service may use its main domain, sign-in domain, static-resource domain, and API domain. If only some are routed through the proxy, pages may load while sign-in fails, images remain blank, or messages cannot be sent. Check the client's connection records to see which domains the target app accessed and which path each received.

To test whether rules are responsible, temporarily retest in global proxy mode. Global mode is for diagnosis and may not be suitable as a permanent setting. If global mode works but rule mode fails, inspect the matching rules; if both fail, the issue is not simple routing. Restore the original mode after testing and record the result. Do not mass-delete rules without understanding them.

Handle app cache and stale connections

A session established by an app before connecting to the acceleration service may continue using its original path. Returning to the desktop and reopening it may not rebuild the connection; fully exit and restart the app. If it offers sign-out or cache clearing, start with the lower-impact restart and sign in again only when the account session is clearly abnormal. Do not delete all local data first, as that can create new sign-in and synchronization problems.

A network switch may also leave the app with an old DNS result. If the browser works while the app continues to fail, disconnect the client, close the app, reconnect, and then launch the app. This lets it create its first connection on the new network path. If it still fails, compare another route in the same region. If switching routes restores access, record the original route and app; if only reinstalling the app helps, the cause is more likely local app state.

How region relates to the destination service

Some streaming and online services return different results based on exit region, account region, content licensing, and sign-in status. A route that opens regular webpages does not guarantee access to content in every region. Choose the region that matches the destination service and use the streaming labels on the nodes page as a guide. Labels such as Netflix, Disney+, and YouTube help filter routes, but the destination service may still decide based on the account and content.

If an app says a region or piece of content is unavailable, do not treat that as a connection timeout. A region notice means the app received a response; check the route region, account status, and cache. For a timeout, check routing and the network first. Quote the exact error accurately rather than writing only “access failed.” The precise error type helps support distinguish a destination-service restriction, a route-label change, and a local rule issue.

Command-line tools and development environments

Command-line tools usually do not automatically inherit the proxy settings of desktop apps. Check the local proxy information provided by the current client, then configure environment variables or parameters according to the tool's own documentation. Do not copy a listening address from another client or mistake a subscription URL for a proxy address. For a temporary test, use a browser that supports the system proxy to verify the route before configuring the tool.

Development tools may read proxy environment variables at startup, so changing system settings while they are running may have no immediate effect. Close and reopen the terminal or development tool, then run the test command again. If the browser works, the command line fails, and reopening restores it, the process had inherited an old environment. If it still fails, check whether the tool bypasses the proxy, whether a custom certificate chain is involved, and which component performs DNS queries.

ACCOUNT AND SUPPORT

Device status, plan checks, and support tickets

How to assess a “device limit exceeded” message

VPNZe supports unlimited simultaneous devices, so normal use does not impose a fixed device-count limit. If the client shows a session anomaly, authorization failure, or duplicate-login message, do not assume that a fixed device limit has been exceeded. First confirm that the active subscription belongs to the same account, the device time is correct, the subscription has been updated, and no historical configuration or content from another account was imported.

When multiple devices have problems, distinguish an issue with the same subscription delivery from an issue with the same network environment. If all devices use the same access network and fail together, switch networks for comparison; if devices on different networks show the same subscription error, check the account and configuration; if only one device fails, prioritize its client, permissions, and system network. Unlimited devices does not mean local configuration differences can be ignored.

Check plan and traffic status

Connection failures can sometimes be confused with plan status. Open the user panel to check the current service status, traffic, and billing period instead of guessing from a stale route list in the client. Monthly plans are ¥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 charges the difference based on the remaining days. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire.

If the panel is normal but the client says the subscription is invalid, retrieve the subscription again and update the configuration; if the panel says the plan needs renewal, visit the plans page to compare options, then continue from the user panel. Payment methods include Alipay, WeChat Pay, and USDT. Describe plan issues and route failures separately: the former concern panel status and orders, while the latter concern routes, networks, and error logs. Mixing them into one vague description slows verification.

Complete the minimum checks before submitting

Before opening a ticket, answer at least these questions: does the basic network work while disconnected; does the issue affect every app or only one; have you tested another route in the same region; have you compared system-proxy and virtual network modes; can the subscription update; and was the issue triggered by sleep, a network switch, or peak hours? You do not need to change every setting—complete only the comparisons relevant to the symptom.

If you cannot connect at all, include the client startup state, route name, and first error; if websites do not open, include the browser error and DNS check; if speeds are slow, include the real use case, time window, and comparison route; for frequent disconnects, include the trigger and recovery method; for subscription-update failures, include the request or parsing error; for a single-app failure, include the browser-versus-app comparison.

What a useful support ticket should contain

Do not submit passwords, subscription URLs, complete configuration files, or screenshots containing access credentials. Capture only the log entries near the failure and label each excerpt with the action it corresponds to. If one ticket contains unrelated issues, separate them by symptom and state which ones can be reproduced independently. Support works from the reproduction path; it does not need remote device access or an account password.

When to contact support promptly

The same error appears across multiple access networks, platforms, and routes; panel status clearly conflicts with client status; the subscription cannot be retrieved repeatedly and the old configuration has also stopped working; a specific route behaves abnormally across different devices; or the client core still cannot start after permissions are checked. In these cases, random setting changes are unlikely to help—submit a ticket directly.

If the issue is limited to one browser cache, one app's stale session, or an interface that failed to recover after sleep, follow the relevant section first. If it occurs only at a particular time, record that time before submitting so the issue can be reproduced. The ticket entry is in the user panel. Registration requires no email address; the account flow uses a username and password.

Wrap up after troubleshooting

After recovery, undo temporary changes one by one and keep only settings confirmed to work. If you used global mode temporarily, restore the mode needed for daily use; if you created a test configuration, remove it after the main configuration is stable; if you disabled other network tools, restore them one at a time and watch for the issue to return. This helps identify the real cause instead of permanently stacking temporary changes.

Keep a short record of the original symptom, confirmed cause, effective action, and current route type. If a similar issue appears again, first check whether the trigger is the same instead of mechanically repeating every step. Network failures can look alike while having different root causes. The reliable method is always to separate the layers first, then compare them with the smallest possible change.