VPN Troubleshooting Guide

Build a reproducible troubleshooting method

Network issues are easy to misdiagnose because different layers can produce similar symptoms. A client may report a failed connection because the local network is temporarily unavailable, the system clock is wrong, the subscription is outdated, the route cannot be reached, or an old network extension still owns the interface. A client may show Connected while websites remain inaccessible because the browser proxy, DNS cache, routing rules or the app’s own connection pool is still using the old path. Effective troubleshooting is not repeated clicking; split the full path into steps and verify each input, process and result.

Record the original state before starting. Note the platform, client name, current network type, selected route, approximate time the issue began, the complete error shown in the interface, and whether ordinary websites work while the service is disconnected. Do not clear the configuration or reinstall immediately. Once the original state is overwritten, it becomes difficult to tell whether the issue came from the subscription, system permissions or route selection. If the interface allows log copying, save a text copy first. If you can only view the error, keep a screenshot with enough context, but cover usernames, passwords and subscription details before submitting it.

Narrow the scope with comparison tests

The key to comparison testing is changing one variable at a time. Keep the same device and client, then change the route to see whether the issue is route-specific. Keep the route unchanged and switch to another local network to determine whether the current connection affects access. Keep the network and route unchanged while testing the browser and another app to see whether the issue is limited to app routing. If you change the client, network and route together, even a recovery will not reveal which change helped, and the next similar failure will require starting over.

Also distinguish between “a connection cannot be established,” “the connection is established but carries no data,” “some destinations are inaccessible,” and “access works but is unstable.” These states point to different checks. For the first, prioritize permissions, time, subscriptions and protocols. For no data, check the default route, DNS and system proxy. For partial failures, check rules, region and app cache. For unstable performance, look at packet loss, path congestion, local wireless conditions and background restrictions. Replacing “it does not work” with a precise symptom is often the most important diagnostic step.

Protect the account and configuration first

ZJVPN does not require an email address; a username and password are enough to register, so keep them secure as important credentials for restoring access. Do not post credentials, the full subscription or links containing tokens in public discussions. A subscription URL functions much like an access credential. When taking screenshots, check that the address bar, QR code and logs do not expose the full content. Example configurations should always use clearly fake values, for example:

subscription: "https://example.com/sub?token=YOUR_TOKEN"
profile: "diagnostic-copy"
dns-mode: "system"

When copying a configuration for testing, keep an unmodified original copy and give the test copy a clear name. To restore it, exit the client first, then import the original copy so multiple network extensions do not remain enabled at once. If the issue began after a system update, client replacement or network change, record that change too. The order in which changes occurred is often more useful than a single error code.

After completing the basic record, move to the chapter for the matching symptom. If several symptoms occur together, start with the earliest failure: first resolve the inability to establish a connection, then address web access and DNS, and finally analyze speed and individual apps. Until the underlying connection is stable, upper-layer app tests usually provide little diagnostic value.

Cannot connect: check permissions through routes

“Cannot connect” means the client never reaches the connected state or immediately returns to disconnected after a connection attempt. First determine whether the failure occurs locally in the client or while establishing a session with the route. If no network-permission prompt appears after clicking Connect, or the client clearly reports insufficient permission, the issue is usually on the device. If the attempt continues for a while before timing out, the problem is more likely a path issue between the local network and the route. These cases require different troubleshooting orders; simply changing routes is not enough.

Confirm the local network and system basics

Disconnect ZJVPN and open an ordinary website that normally works. If ordinary websites are also inaccessible, restore the local network first because the accelerated connection depends on the existing access path. If the access network requires accepting terms or completing a sign-in page, authenticate while disconnected, then return to the client. Office, campus and hotel networks may apply different rules to different connection methods. You can compare with another permitted access network, but repeatedly deleting the subscription on the problem network will not repair the underlying connection.

Then confirm that the system is maintaining the date, time and time zone correctly. Secure connections validate certificate validity periods, and a significant clock error may appear as a handshake failure, certificate error or immediate disconnection. After correcting the time, fully exit and reopen the client so its network components reload the state. If the device has just resumed from sleep, wait for the system network to stabilize before connecting; virtual interfaces left over from sleep may be temporarily unavailable.

Check system permissions and conflicting components

Windows and macOS must allow the client to create or use a virtual network interface. iOS and Android request permission to establish a VPN configuration on first use. On Linux, confirm that the client has permission to manage the network interfaces and routes it needs. After a permission has been denied, the client may not show the prompt again automatically, so check the relevant system settings. Once permission is enabled, disable other similar network tools before testing ZJVPN. Multiple tools changing the default route, system proxy or DNS at the same time can create a conflict where the interface looks normal but traffic uses the wrong path.

Check whether an old client, enterprise secure-access tool, packet-capture tool or virtual-machine network component is still running. You do not need to uninstall them permanently; during diagnosis, fully quit them and confirm that their network extensions are no longer active. If the connection works afterward, restore them one at a time to identify the conflict. If a firewall or security policy shows an access prompt, verify the program name and source before following organizational policy. Do not disable security protection entirely for testing. On managed devices, ask the device administrator to confirm the policy.

Verify the subscription, routes and protocol

Confirm that selectable routes actually exist in the client rather than seeing only an empty configuration name. If the route list is empty, its timestamp is not updating or all entries disappeared together, go to the subscription-update chapter first. When routes are present, compare routes in different regions. ZJVPN covers 90+ countries / 200+ routes; the goal is not to click through routes continuously, but to determine whether “all routes fail at the same stage” or “only one group of routes fails.” The former points more toward permissions, subscription or local-network issues; the latter suggests a path-specific issue. See the node page for route types and region-selection guidance.

If the client offers different connection modes, start with the subscription default. Do not manually change the port, transport method, encryption parameters or server name without understanding them; any mismatch with the subscription can cause a handshake failure. If you have edited the configuration manually, create a clean configuration and import the subscription again for comparison. If the clean configuration connects, the issue came from a local modification, so there is no need to keep suspecting the account or every route.

If connections time out on one network but work on another, record both network types and the failure time instead of writing only “the route does not work.” If other devices connect on the same network while the current device cannot, focus again on permissions, conflicting components and client configuration. If every route fails on the current device and other devices also fail on the same network, the local egress or network policy deserves closer attention. This cross-check can substantially narrow the scope of a support ticket.

Connected but no web access: check routing and DNS issues

A Connected status only means that the session has been established; it does not mean every type of traffic is entering that session correctly. When websites do not open, distinguish between failed domain resolution, an unchanged default route, a browser still using an old proxy, a destination rejecting the current region, and a local network that lost access during the switch. Declaring the route “dead” skips many verifiable steps. The most effective approach is to test domains, addresses, different apps and different routes separately.

First determine whether all destinations or only some are affected

Open several ordinary websites with different characteristics and check whether other apps can access the internet at the same time. If every website and app has no data, check the default route, system proxy and DNS first. If only the browser is affected while other apps work, check the browser proxy, extensions and secure DNS. If only one website fails, consider the destination region, the site’s own status, cache and routing rules. Do not use one website to represent the entire network path; maintenance at the destination can produce the same appearance.

Disable standalone proxy extensions in the browser and test in a new private window. Some browsers retain an old connection pool, so existing tabs may reuse connections created before the system route changed. Fully quitting and reopening the browser is more reliable than repeatedly refreshing the same page. If the private window works but a normal window does not, check extensions, cache, site data and the browser’s custom DNS instead of continuing to change routes.

Distinguish DNS and routing failures

DNS converts domain names into network addresses. When resolution fails, browsers often show messages such as server not found, domain not found or resolution timed out. A routing failure more often appears as a connection timeout after resolution succeeds. You can use built-in system commands to inspect the resolution result. The following commands contain no credentials and can be run in the appropriate platform terminal:

nslookup example.com

ping example.com

traceroute example.com

On some systems, the route-tracing command has a different name. If a command is unavailable, there is no need to install another tool; keep the browser error and client logs instead. Do not treat “the destination does not respond to ping” as proof of a route failure, since servers may ignore such requests. Focus on whether the domain resolves, whether the request fails immediately on the local device, and whether results change between disconnected and connected states—not on reaching a fixed number.

If the domain cannot be resolved but a known address accepts a connection, the issue is more likely DNS. Exit the client first, clear the system DNS cache, reconnect and test again. On Windows, run the following in a terminal:

ipconfig /flushdns

DNS management on macOS, iOS, Android and Linux depends on the system version, network-management service and client implementation, so do not copy commands that do not apply. A general approach is to disconnect, close the client, switch networks once and establish the connection again. Linux users can first inspect the current resolution state and default route, then identify which service is managing them:

resolvectl status

ip route

Prevent multiple DNS sources from overwriting one another

The client, operating system, browser and local network may all provide DNS. If the browser has independent secure DNS enabled, it may bypass the resolution path assigned by the system. If the client enables virtual DNS while the system network service overwrites settings whenever the connection changes, resolution may work immediately after connecting and fail later. During diagnosis, reduce variables first: set the browser to follow the system, use the client’s subscription defaults, and remove obsolete manually entered addresses from the system adapter. Once the basic path works, restore custom settings one at a time.

If only specific domains resolve to unexpected addresses, clear the browser and system caches, then retest with another route. If different devices on the same access network show the same abnormal result and switching networks restores access, inspect the local DNS source. If the same device fails on every network while other devices work, the issue is more likely the browser, hosts file, security software or DNS configuration on that device.

Check the system proxy and default route

Some clients forward browser traffic through the system proxy, while others take over system routing through a virtual interface. After an abnormal client exit, the system proxy may remain set to a nonexistent local port, preventing websites from opening even after the service is disconnected. Check whether the proxy is still enabled manually in the system network settings. Do not enter public proxy addresses from random tutorials. Normally, the current client should manage this automatically. Reopening the client and disconnecting normally is usually more reliable for restoring the original settings than force-quitting the process.

If only local-network devices are inaccessible after connecting while the internet works, the global route may be taking over local addresses. Check whether the client offers a LAN bypass or routing option, and test with the default rules. If both internet and LAN traffic fail, return to the default route and virtual-interface checks. Internal domains on managed networks may be resolvable only through the organization’s DNS; failure to resolve them after connecting to an external route is a network-boundary issue that should be confirmed with the administrator.

Layered diagnosis for slow speeds and peak-hour congestion

Speed cannot be judged from a single test result. Cross-border access passes through local access, the carrier egress, the route entry, an interregional path, the destination service and its content-delivery network. A change at any layer can affect the experience. Peak-hour buffering may also come from competition on the home Wi-Fi, a busy destination platform or a distant selected region. The goal is not a flattering number, but identifying whether the bottleneck is consistent, which destinations are affected and which changed condition improves it.

Establish comparable test conditions first

While disconnected and connected, access the same stable destination separately, keeping the device location, access network and test content consistent. Do not use several speed-test sites at once or directly compare results from different regions, files and times. Browser downloads, cloud sync, system updates, video playback and heavy traffic from other devices consume local bandwidth; pause them before testing. On Wi-Fi, stay near the access point to rule out obstructions and frequent roaming.

If the disconnected state is already slow, address the local network first. If disconnected access is normal but every route is slow and switching access networks restores performance, the original local egress is more likely responsible. If only one regional route is slow and a nearby region works, choose a more suitable route for the task. If only one content platform buffers while ordinary websites, file downloads and other video services work, consider the platform’s regional service, cache nodes and account region rather than generalizing the issue to the entire network.

Understand latency, throughput and stability

Latency affects interactive response, throughput affects sustained transfer, and stability determines whether jitter, retransmissions and pauses occur. A slow first page load may involve DNS or initial-connection latency; repeated video buffering after playback starts is more consistent with sustained throughput or packet loss; choppy audio in a meeting depends more on stability than short-term peak bandwidth. A fast one-off download cannot prove that a real-time app is stable. Record symptoms in the context of the actual use case instead of submitting only a speed-test screenshot.

Route distance usually affects the round-trip path. For destinations in Japan, a nearby region that supports the destination is generally a sensible choice; for European destinations, the nearest entry point may not produce the shortest path to the destination. ZJVPN covers 90+ countries / 200+ routes. Refer to the regions and route types in the node guide, then compare with the actual destination. Frequent switching interrupts connection pools and content caches, so after each change, wait for the app to establish a new session before observing a complete period of use.

How to document peak-hour issues

Peak-hour issues are time-dependent; a normal result submitted during the day cannot reproduce them. Run the same task during a normal period and an affected period, recording the route name, access network, destination service and approximate time. If switching to another route immediately helps during the affected period while ordinary local internet remains normal, provide both routes as a clear comparison for support. If every route and ordinary network access slow down together, local access congestion is more likely.

Do not “stress-test” a route by repeatedly refreshing large downloads or running multiple speed tests at once. This makes the local environment another variable and may consume plan traffic. Monthly subscription traffic resets each month on the activation date; traffic packages remain valid until used and never expire. Before troubleshooting, open the account overview to check current usage and avoid confusing traffic status with a speed issue. Verify plan details on the plans page.

Streaming and large-file scenarios

Streaming apps often cache the previous session’s region and content-delivery node. If the video quality or catalog does not change after switching routes, fully quit the app, clear the appropriate cache and reopen it instead of switching routes repeatedly during playback. For platform selection and regional availability, continue with the streaming guide. If the main issue involves network extensions, system permissions or Apple services coexisting on a Mac, see the checks in Mac VPN recommendations and buying guide.

For large downloads, observe sustained stability rather than the initial burst. The download source may limit speed by account, region or server. Compare different sources, but do not use test files from unknown sources. If web browsing is normal and only one source is slow, check the destination first. If several reliable destinations remain slow on the same route, organize the route, time and destination type in a support ticket.

Frequent disconnects and mobile background drops

For frequent disconnects, first distinguish an intentional disconnect from an interruption. Intentional disconnects commonly follow sleep, network changes, battery-saving policies, client automation or user actions. Interruptions may result from changing wireless conditions, a local egress reconnect, a route-session issue or a crashed network extension. Both may appear simply as “Disconnected,” but their log timelines differ. Record what happened on the device before the drop, not only the error afterward.

Observe what triggers the disconnect

First determine whether the drop is associated with locking the screen, sleep, switching Wi-Fi, leaving the app, connecting an external network or system recovery. If it happens after every screen lock, check background operation and battery restrictions. If it occurs when switching from Wi-Fi to a mobile network, treat it as an interface change and see whether the client reconnects automatically. If it still disconnects periodically with the screen on and network unchanged, inspect the route, client logs and system network components. Recording the triggering action is often more useful for reproduction than counting drops.

On desktop platforms, sleep pauses network interfaces. After wake, the old session may be invalid and the client must establish a new connection. If the interface still says connected but carries no data, disconnect manually and reconnect rather than restarting immediately. If recovery fails after every wake, check for other network extensions and whether another program overwrites the system proxy before the client restores it. Managed devices may reapply security policies after waking, so consider the organizational environment.

Mobile background policies

iOS and Android manage background processes based on battery, memory, network state and app activity. After the client is suspended, the interface may retain an old status even though the connection needs to be rebuilt. In system settings, allow the client to run in the background normally and keep it out of lists that force-stop apps. Battery-saving policies vary by Android manufacturer, so follow the Battery and Background management settings on the device. For related basics, see Android VPN setup and verification guide.

Do not enable several automatic-connection rules at the same time. If system on-demand connection, client startup auto-connect and network-change auto-connect are all active, they may trigger one another when the interface changes, creating a connect-disconnect loop. During diagnosis, keep one automatic policy and temporarily disable the others. After manual connections are stable, restore automation one setting at a time. If the issue occurs only on a specific Wi-Fi network, check whether it requires reauthentication or reclaims idle connections.

Distinguish route drops from local interface resets

When a route drops, logs commonly show a remote close, handshake timeout or reconnection process. A local interface reset is more likely to coincide with a network change, disappearing route, address update or restart of the system network service. You do not need to interpret every log line; keep the continuous section before and after the drop. Do not capture only the final line, since it may show merely a failed retry while the actual cause appears earlier.

Change routes on the same network and observe. If every route drops after screen lock, sleep or a network change, address system policies first. If only one route drops while the device remains active and others are stable, record its name and use another route temporarily. If switching access networks resolves the issue, inspect the original network’s signal, authentication and egress changes. If several devices on the same access network drop together, the local network or upstream path is more suspect.

Recover without creating a connection loop

When repeated reconnections occur, disable auto-connect first, disconnect manually, wait for the system network to recover, then establish one connection again. Do not rapidly toggle the switch; concurrent connect and disconnect requests can leave the interface state behind the system state. If the client cannot stop, exit it normally and confirm in the system VPN settings that the configuration is disconnected. Restart the device only when a network interface clearly remains stuck and ordinary websites are also affected.

If a restart restores service temporarily but the issue returns whenever a particular app runs or a certain network is used, continue comparing the trigger conditions. A restart only clears the current state; it does not prove the root cause is fixed. Include both “a restart restores service” and “the issue returns after the trigger” in the ticket to help distinguish leftover resources, client conflicts and route issues. If the system was recently updated, note the before-and-after difference without speculating about a specific version defect.

Subscription update failures and device checks

A failed subscription update may appear as an inability to download the configuration, an empty route list, an unchanged update time, an immediate format error after import, or old routes remaining while new content never appears. Distinguish account access, the subscription URL, client parsing, local cache and plan status. A subscription is the configuration entry point, not the route connection itself. If the subscription content was not retrieved correctly, testing routes further is not meaningful.

Confirm the entry point and account status

Get the subscription through the user panel rather than chat history, old screenshots or an outdated URL saved on a public page. ZJVPN does not require an email address; a username and password are enough to register. If you forget the login details, follow the account process provided in the panel instead of creating many duplicate accounts. After signing in, check the overview and plan status, then use the client download page to find the configuration method for the current platform.

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 packages include ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain valid until used and never expire. During troubleshooting, only confirm that the current plan is active; do not manually calculate remaining time or guess the traffic status. If plan details differ from expectations, compare them with the plan details before submitting order information.

Safely re-import the subscription

Rename or export the current configuration as a backup, then create a blank configuration and import the latest subscription. This helps determine whether the issue comes from an old cache or the subscription content. Do not manually overwrite server addresses or protocol fields in the old configuration, and do not merge nodes from different services into one configuration and ask support to diagnose it. A mixed configuration makes it impossible to tell which item generated a request.

When copying the subscription URL, make sure it contains no extra spaces, line breaks or truncation by a chat app. Paste it directly into the client’s subscription-import field, not into a browser search box, and never publish it on a public page. If the client supports QR import, still confirm that the QR code came from the signed-in user panel. After an import failure, save the complete message and distinguish a failed network request, authorization failure, empty content and format-parsing failure; each points to a different next step.

If the browser can access the user panel but the client cannot update the subscription, check whether the client is being affected separately by the system proxy, DNS or firewall. Disconnect the existing connection and update over the ordinary network first. If a connection is required before updating, select an available route and try again. After a successful update, confirm that the route list actually refreshed rather than relying on a “Complete” message. The client may retain an old configuration copy; identical names do not guarantee identical content.

Cache, time and format issues

A system clock error can cause the secure connection for a subscription request to fail, similar to a route handshake issue. Correct the time, fully exit the client and try again. If the client downloaded web-page text instead of a configuration, the sign-in session may have expired, the URL may be incomplete or the request may have been redirected. Do not import page source as a configuration. If the logs show a format error, retrieve the original subscription again from the user panel instead of manually editing encoding, quotation marks or indentation.

Cache clearing should be limited. Delete the cache for the individual subscription first rather than clearing all client data, which may contain other valid configurations and rules. Before reinstalling, confirm that the username and password work and export any non-sensitive settings you need to keep. After reinstalling, import only one clean subscription for verification, then restore custom rules one at a time after it works.

Unlimited devices does not mean one configuration can be copied without limits

ZJVPN allows unlimited simultaneously connected devices, but each device should use the correct platform client and a currently valid subscription. If a message such as “device limit exceeded” appears, do not assume it is a plan restriction because the stated policy is unlimited devices. First confirm whether the message comes from the ZJVPN user panel, the current client or another mixed configuration. An old client, another service’s configuration or a local rule may display its own limit text. Keep the screen and configuration name where the message appeared so support can identify its source.

If a subscription fails on multiple devices at once, check the account and subscription entry point first. If only one device fails, prioritize that device’s cache, permissions and client. When importing across platforms, do not copy an entire locally exported configuration from one platform, since it may contain paths, interface names or rules recognized only there. Get the import method for Windows, macOS, iOS, Android or Linux separately from the user panel.

One app does not use the proxy: check app routing

If only one app is inaccessible while the browser and other apps work, the entire route usually has not failed. Common causes include the app bypassing the system proxy, routing rules sending its domains directly, an independent DNS service, an existing connection that was not rebuilt, or extra account- and region-based checks by the destination. Focus on confirming which path the app actually uses instead of repeatedly changing accounts or routes.

Start with a browser comparison

Find the app’s official website or a web entry point for the same service and open it in a browser on the current route. If the website works but the app does not, the basic route and destination domain are at least partly reachable, so check the app itself next. If both fail, the issue is more likely related to the destination region, route, DNS or service status. If the app has no web entry point, use a comparable network request for contrast, but do not draw conclusions from an unrelated website.

Fully quit and reopen the app. Many apps reuse connections created at startup and do not rebuild them immediately after a route change. Returning to the home screen may not terminate the process; mobile devices may retain a background session. After reopening, wait for the sign-in state and content to refresh before observing the error. If restarting the app restores access, the issue was connection caching and there is no need to keep changing routing rules.

System proxy, virtual interfaces and app bypasses

In system-proxy mode, only apps that follow the system proxy settings automatically enter the proxy path. Some apps create network connections directly, which is why a browser may work while an app connects directly. Virtual-interface mode usually covers more system traffic, but exclusions, LAN bypasses and app allowlists can still affect it. If the client offers global, rule-based or direct modes, briefly use the mode with the clearest coverage for comparison, then restore the rule mode suited to daily use.

Do not use global mode permanently to hide incorrect rules. If global mode works but rule mode fails, check the logs to see which rule matched the destination domain. A rule set may lack a new domain because of caching or an outdated update, or it may send content and sign-in domains through different routes. Apps often connect to authentication, API, image and media domains in addition to the main domain; handling only the main domain can allow sign-in while content still fails to load.

Identify routing results through logs

Open the client log, clear old entries, launch the target app and reproduce the issue once. Look near the reproduction time for domains, connection results and rule names. When the log is large, do not copy a full day; keep the continuous section immediately before and after launching the app. If there are no requests from the app at all, it may be bypassing the current proxy method or the log level may not record traffic. If requests appear as direct connections, check the rules. If they enter a route and time out, compare other routes and destination regions.

time: "REPRODUCE_TIME"
application: "TARGET_APP"
route: "RULE_OR_DIRECT"
result: "COPY_THE_VISIBLE_ERROR"

The text above is a record-keeping template, not client configuration to import. Do not add broad matches based on scattered rules found online; overly broad domain suffixes or process rules may redirect unrelated apps. Save the original rules before editing. Afterward, test only the target app and verify that ordinary websites, LAN services and other common apps are unaffected.

Account region, cache and destination restrictions

Some content services consider not only the current network region but also the account region, billing region, app-store region and historical cache. If the original content remains after changing routes, routing may not be the cause. Fully sign out of the account and app, clear the appropriate cache, then test with a route matching the target region. For streaming, see the regional and quality guidance on the Streaming page. For AI Tools, see the AI Tools access guide.

If an embedded web page opens inside the app but media, uploads or real-time features fail, different functions may use different domains or transport methods. Record exactly which step fails: sign-in, list loading, images, playback, upload or real-time connection. Do not write only the app name. Specific stages allow support to investigate the route logs and rules instead of repeating generic cache-clearing advice.

Platform permissions and local-network exceptions

Android per-app proxy settings, iOS system network extensions, macOS network filters and Windows firewall rules can each affect specific programs. Check whether the target app is excluded, whether it is allowed only on certain network types, and whether security software has a separate rule for it. Linux users should also check containers, sandboxes and namespaces; an app running in isolation may not use the host system’s default proxy.

LAN apps should usually remain direct, such as apps for local storage or printers. Forcing all local traffic through a route to fix an internet app may break LAN services. When editing rules, distinguish target domains from local addresses. After recovery, verify both the target app and LAN access so that fixing one path does not create another conflict.

When to contact support and what to include in a ticket

The goal of self-checks is not to make users solve every issue alone. It is to rule out quick local checks and give support reproducible conditions. Submit a ticket when the account, order or subscription entry point is abnormal, or when the issue remains reproducible after basic comparisons. An effective ticket describes facts, timing and comparison results; it does not need a guessed technical cause. “The server is broken” does not help locate the issue. Stating the platform, route, access network, destination, triggering action and resulting error makes resolution much more efficient.

When to submit a ticket directly

Submit a ticket directly if the user panel does not correctly show the active plan, the order status and payment record do not match, the subscription entry point returns a clear authorization error, or the account process fails despite a confirmed username and password. Payment methods are limited to Alipay, WeChat Pay and USDT. For payment issues, provide the order details and status screenshot from the panel, but never send a payment password, private key, recovery phrase or complete payment credential. To verify a plan, compare it with the monthly and traffic-package details on the plans page.

For connection issues, a ticket is appropriate when ordinary websites work while disconnected, the system time and permissions are correct, a clean subscription was imported, and the same error persists after changing both route and access network. If one group of routes reproduces the same issue across multiple networks while others work, include the working routes as a comparison. For speed issues, provide at least the normal and affected periods, destination type and selected route instead of a single screenshot that cannot be reproduced.

For a specific app, complete a browser comparison and restart the app first. If the logs show that requests enter the route but the same step still fails after changing routes, submit the target app, failed function, destination region and redacted logs. If the logs contain no requests at all, a local routing or proxy-coverage issue is more likely; also state the client mode and whether the app is excluded.

Ticket information checklist

Use the following template to organize the ticket body. Replace the uppercase text with your own description, but do not include usernames, passwords, the full subscription URL or other sensitive credentials:

Issue type: CONNECT / DNS / SPEED / SUBSCRIPTION / APP
Platform: PLATFORM
Client: CLIENT_NAME
Selected route: ROUTE_NAME
Time observed: REPRODUCE_TIME
Symptoms: VISIBLE_ERROR_AND_FAILED_STEP
Disconnected state: NORMAL_OR_ABNORMAL
Route change result: CONTROL_RESULT
Network change result: CONTROL_RESULT
Already tried: ACTIONS_ALREADY_TAKEN
Attachments: REDACTED_SCREENSHOT_AND_LOG

How to redact logs

Before submitting, search the logs for the subscription URL, token, username, password, QR-code content and local file paths. Delete the entire subscription URL or replace it with “hidden”; do not cover only the end, because the beginning may also contain account information. Whether a public IP address needs to be covered depends on the issue type. If unsure, state in the ticket that the logs were redacted and let support request the minimum additional information. Also check browser tabs, notification bars, clipboard pop-ups and other app windows in screenshots.

Logs must retain their context. Copying only the line “connection failed” is usually insufficient; include the continuous sequence from initiating the connection, selecting the route and setting the handshake, routing or DNS through the failure. Do not upload long logs unrelated to the issue, since excessive content can bury the key events. The best range is to clear the log before reproducing, perform one complete action, stop immediately after failure and export it.

How to verify after support replies

After receiving guidance, still perform one action at a time. If support suggests re-importing the subscription, keep the old configuration and test a new clean one. If it suggests changing the route, keep the network and destination unchanged. If it suggests adjusting routing, save the current rules first. After recovery, retest the original failure condition to confirm that the issue is actually gone rather than that the destination service briefly recovered. Reply with the verification result in the original ticket instead of opening several identical tickets and scattering the context.

If the suggestion does not work, add the result, time and new logs directly; there is no need to resubmit the entire background. If the failure condition changes—for example, from being unable to connect at all to being connected with a DNS issue—state clearly that the symptom changed and return to the corresponding chapter for a fresh basic comparison. The evolution of the issue is itself an important clue.

Close out the configuration after troubleshooting

After the issue is resolved, delete invalid configurations created during testing, restore necessary auto-connect and routing rules, and confirm that the system proxy, DNS and LAN access are in the expected state. Keep one clean subscription configuration as a baseline, but do not store the subscription text in a public cloud document or chat group. When using multiple devices, confirm separately that Windows, macOS, iOS, Android and Linux have no leftover conflicting components.

If the issue was related to an incorrect configuration, record the final working setting name, steps taken and trigger conditions for future maintenance. When similar symptoms appear again, first verify whether the trigger is the same instead of mechanically repeating every step. For long-term users, a short, accurate and verified local record is more reliable than collecting large numbers of tutorials from unknown sources.