Start with a reproducible diagnostic baseline
Troubleshooting most often fails not because the problem is complex, but because the description is too vague. “It won’t connect,” “it’s slow,” and “it drops sometimes” are impressions, not conditions that map directly to a specific failure layer. Before you begin, rewrite the symptom as something you can test repeatedly: which platform you are using, whether the connection is a home or public network, whether the client opens normally, whether the subscription list is visible, whether a route can be selected, whether the connection succeeds, and whether the browser and other apps are affected at the same time. Once these conditions are clear, you can quickly identify whether the issue lies with the local network, client, system proxy, name resolution, route exit, or target service.
Identify the scope first instead of reinstalling immediately
Close the client connection first and visit a local website that normally loads. If direct access is also unstable, address the router, Wi-Fi, system network, or ISP connection first. Accelerated access depends on the existing network path; replacing routes usually will not help when the local network itself is dropping. Once direct access is stable, start the client and test one route only. Do not enable browser extensions, other proxy tools, system-level filters, or multiple similar clients at the same time, as they may compete for the system proxy, virtual network interface, or DNS settings.
Next, distinguish between “every target fails” and “only one target fails.” If browsers, desktop apps, and system updates are all affected, check connection status, proxy mode, and DNS first. If only one website fails, the cause may be that site's regional policy, cache, login state, or a temporary service issue. If only one app bypasses the proxy, the issue is more likely a routing rule, the app's own network stack, or system permissions. The narrower the scope, the less appropriate it is to wipe all settings. Keep a known-good configuration for comparison.
Keep a comparison set of conditions
Choose one route that worked previously as a baseline, then choose another route from a different region or route type for comparison. See the Locations page for route types. Keep the device, client, and network unchanged while switching routes; then keep the route unchanged while switching the local network. This shows whether the problem follows the route or the network. If the failure follows one route, record its name. If it appears only on one network, focus on that network's resolution, routing, or access policy.
| Observed result | Most likely scope | Next step |
|---|---|---|
| Websites still fail after closing the client | Local or system network | Restore direct network access first |
| No route can establish a connection | Subscription, permissions, client, or network restrictions | Check the subscription and switch networks |
| Only one route fails | Individual route or exit status | Switch routes and record the name |
| Browser works but one app fails | Routing rules or the app's network stack | Open the app routing section |
Record verifiable facts only
Your record should include the platform, network type, status shown by the client, selected route, exact error message, whether the issue reproduces consistently, and what you have already tried. Do not simply write “I tried everything.” If the error can be copied, keep the complete text. If you can only take a screenshot, include the status and route name, but hide the username, subscription URL, and any credentials that could be used to log in. A subscription URL is an account credential and should not be posted in public groups or forums.
5TVPN supports Windows, macOS, iOS, Android, and Linux, and an account can be used on any number of devices. System proxy behavior, background policies, and virtual network implementations differ by platform, so an account working on one device but not another does not by itself indicate an account problem. The following sections highlight platform differences. If you are using a client for the first time and do not know where to obtain the subscription, return to the quick-start process instead of skipping the prerequisites in this troubleshooting guide.
Cannot connect at all: check everything from entry point to handshake
“Cannot connect at all” means the client opens and may show or let you select routes, but the connection always fails, quickly returns to a disconnected state, or remains stuck connecting. First determine whether the subscription content failed to load or whether the routes loaded but the connection handshake failed. The former usually appears as an empty route list, a missing subscription name, or an update error. The latter shows route names but never reaches a stable connected state. These symptoms require different troubleshooting sequences and should not be mixed together.
Confirm direct access, system time, and client permissions
Disconnect the client first and confirm that the direct network works. Then check that the system clock is set to synchronize automatically. Encrypted connections validate certificates against a time window, so a significantly incorrect clock can look like a route-related handshake failure. Also confirm that the client has permission to establish a system network connection. Desktop systems may ask to authorize a virtual network interface or proxy changes; mobile systems show a system confirmation prompt on the first connection. If it was denied, return to system settings and authorize it again.
If the client exits immediately after launch, fully terminate the process and reopen it instead of repeatedly clicking Connect. On Windows and macOS, make sure another similar client is not still running in the background. On Linux, confirm that the launch method has permission to operate network interfaces and routing tables. Do not delete all configuration at the outset, because doing so also removes subscription status and error records that could help diagnose the issue. Close conflicting programs first, then retest with the original configuration.
Check whether the problem follows the current network
Keep the device, client, and subscription unchanged, then test on another available network. If the other network connects, the account and basic client configuration are probably sound; the issue is more likely related to routing, DNS, protocol handling, or access policy on the original network. Restart the original network router, wait for it to obtain network parameters again, and then test different routes. Public networks sometimes require access confirmation in a browser first; until that confirmation is complete, the client may initiate a connection even though normal traffic has not been allowed.
If the connection fails on every network, try different routes. Do not switch repeatedly among neighboring routes; compare routes from different regions or route types instead. 5TVPN offers 120+ countries / 230+ routes, and the locations page describes the available regions and types. If only one route fails, use another available route rather than reinstalling the client repeatedly. If several route types fail across several networks, continue by checking the subscription status, system permissions, and client configuration.
Check for mode conflicts and leftover system proxies
Enabling system proxy mode alongside other network takeover tools can cause traffic to be forwarded a second time after the connection is established, resulting in connection failures or repeated retries. During troubleshooting, keep only one client running. Disable browser proxy extensions, developer debugging proxies, proxy features in network-filtering software, and manually entered system proxy addresses. Then exit the client, confirm that the system proxy has been restored, and restart it. If the client offers automatic takeover, let that one client manage the connection instead of combining manual and automatic settings.
https://example.com/sub?token=YOUR_TOKENThe value above is a placeholder-format example used only to show the structure of a subscription URL. A real subscription address must be obtained from the user panel. Do not replace the example and post it publicly. If the client requires a subscription import but you pasted an ordinary webpage address or lost characters from the beginning or end during copying, the routes will not load correctly. Copy the complete URL from the panel and import it again. Do not pass it through chat tools, as some may rewrite links or truncate special characters.
How connection entry points differ by platform
| Platform | Check first | Common leftovers |
|---|---|---|
| Windows | System proxy, virtual network permissions, and background clients of the same type | Proxy remains after exit |
| macOS | Network extension authorization, system proxy, and filter conflicts | Old network extension still enabled |
| iOS | System connection authorization and current network access status | Old configuration still occupying the connection |
| Android | System connection authorization, battery-saving policy, and always-on settings | Another app is occupying the system connection |
| Linux | Runtime permissions, routes, name resolution, and firewall rules | Routing rules remain after exit |
After these checks, if the failure occurs only on a specific network, include the network type and retest results in your ticket. If every network and multiple routes fail, attach the client's exact error message. Do not upload only a cropped screenshot saying “connection failed.” Support needs the platform, selected route, failure stage, and complete message to determine whether the issue involves subscription parsing, permissions, the network handshake, or the route entry point.
Shows connected, but websites will not load or DNS fails
When the client shows “Connected,” it only means that the connection channel has been established; it does not mean every type of traffic is entering the channel correctly. When websites fail to load, determine whether the system proxy did not take over, DNS did not resolve correctly, the browser retained bad cache, or the target website is temporarily unavailable. Repeatedly clicking Connect is not useful here because the connection stage is complete; the problem occurs later in the traffic path.
Use scope to confirm whether the proxy is working
Keep the connection active and test the browser and another app that uses the system network. If all apps fail, first check that the client is in the expected mode and that the system proxy was written successfully. If the browser works but other apps do not, the browser may be using its own proxy or DNS while system traffic is not being handled consistently. Conversely, if other apps work and only the browser fails, disable browser proxy extensions, privacy-network features, or custom resolution settings, then test in a new window without the old extensions.
You can also fully quit and reopen the browser. Browsers retain connection pools, name-resolution results, and site sessions; after a route change, an old connection may still point to the previous exit. Refreshing the page alone may not rebuild the underlying connection. If a new window works, the issue is usually the browser cache or an extension rather than the route. If multiple browsers show the same result, continue by checking the system proxy and DNS.
Identify name-resolution problems
DNS converts domain names into network addresses. When resolution fails, the client may already be connected while the page says the server cannot be found, the domain does not exist, or the lookup timed out; apps that use a known network address directly may still work. During troubleshooting, restore the system DNS to automatic, disable custom secure resolution in the browser, and let the client take over using its default behavior. Do not configure different resolution methods in the router, system, browser, and client at the same time, or requests may leave through different paths and become difficult to assess.
If you previously installed network filtering, parental controls, ad blocking, or enterprise access tools, their system resolution services may remain active even after the program exits. On desktop systems, check whether the current network adapter still points to a manually entered DNS address. On mobile systems, check whether the current Wi-Fi network has manual DNS or proxy settings. After restoring automatic configuration, disconnect and reconnect the network, then start the client. The order matters: restore the system network first, then let the client write its settings again.
Clear leftover routes after a successful connection
An abnormal client exit, interrupted sleep, or several tools taking over the network in turn can leave behind an old proxy or route. A typical symptom is that the client says Connected but no requests return correctly; after exiting the client, direct access is also affected. Properly disconnect and exit the client, then turn the current network connection off and back on so the system can obtain fresh routing and resolution parameters. Confirm that direct access has recovered before starting the client again.
Linux users running a command-line client should pay particular attention to the default route, policy routes, and name-resolution service still pointing to an interface that no longer exists. Do not copy cleanup commands from unknown sources. Check the current state first, identify which rules the client created, and clean them up through the client's own stop process. When running as a service, avoid starting a second foreground instance, as the two instances may modify routes and DNS independently.
How to assess a single website that will not load
A problem with one website does not mean the overall connection has failed. Try a different entry point on that site to see whether only the login page, video page, or asset domain fails. Then use a private window to rule out old cookies and cache, and select a route from another region. Some services provide different content based on exit region, while a login session may retain information from the previous region. After changing regions, reopen the page instead of continuing to use the existing tab.
If other websites work on the same route and the target site returns the same error in multiple browsers, record the domain, selected region, and exact error message. Do not include account passwords, personal information from the page, or subscription URLs in screenshots. For streaming region checks, see the Streaming access guide; for choosing an exit region, return to the Locations page to confirm the appropriate area.
Verification after recovery
After access is restored, do not immediately re-enable every extension and filter. Keep the default settings for a continuous session first, confirming that the browser, other apps, and wake-from-sleep behavior all work. Then restore extra tools one at a time and retest after each. Restoring everything together will make the source of a recurring problem impossible to identify.
If websites still never load after connecting while the client's connectivity check appears normal, state in the ticket whether “the connection succeeds but all websites fail” or “only specific domains fail,” and include what happened after restoring automatic DNS, disabling extensions, and switching routes. This is more useful for diagnosis than simply saying “DNS is not working.”
Slow speeds, reduced video quality, and evening congestion
Speed issues must first be separated into slow startup, insufficient sustained throughput, high latency, and unstable connections. A webpage that takes a long time to open may indicate DNS or latency; a file that starts quickly and then stalls may indicate link fluctuation or target-service throttling; video quality may drop because available bandwidth is low or because the player is responding conservatively to short-term variation. Calling every symptom a “slow route” can hide the part of the path that is actually affecting the experience.
Build a meaningful speed comparison
First confirm that the local network is stable with the client closed, then connect to a nearby route and perform the same task. Use the same device, network, target, and roughly the same time conditions. Do not compare a browser speed test with video loading and an app download, because each target has different server locations, throttling policies, and cache states. The goal is not a flattering number but identifying where performance is being lost.
If the direct connection already fluctuates noticeably, address the Wi-Fi signal, router load, or access network first. Move closer to the access point, reduce simultaneous network tasks, or use a more stable connection method. If direct access is stable but the connection slows it down, compare regions and route types. Greater physical distance usually means a longer round trip, so do not automatically choose European or US exits for Asian targets. For region-specific services, prioritize an exit that matches the service's region.
Retest evening issues across different times
When evening congestion occurs only during a particular period, do not dismiss it because one test at another time worked. Record the time, route name, target app, and exact symptom. When the issue appears, switch to another route in the same region, then compare a different route type. If multiple routes slow down at once and the direct network also fluctuates, the bottleneck may be the local access network or a public-network exit. If only one route remains abnormal, use an alternative and submit its name to support.
After switching routes, rebuild the target app's connection. Video players, downloaders, and browsers may continue reusing an old connection even after the client reports a route change. Pause the task, close the target page or app, switch routes, and reopen it. Switching routes without rebuilding the app connection can produce a misleading conclusion.
Latency and bandwidth are different metrics
Latency affects interactive response, such as a webpage's first response, live-stream interaction, remote control, and gaming. Bandwidth affects sustained transfers, such as HD video, large files, and system updates. A distant route may have ample bandwidth but slower interaction, while a nearby route may perform poorly for video if its exit does not match the target service. Choose according to the task instead of expecting one route to suit every situation.
| Symptom | What to watch | Priority action |
|---|---|---|
| Webpage opens slowly at first, then works normally | Resolution and round-trip latency | Check DNS and choose a nearer route |
| Video quality keeps dropping | Sustained throughput and fluctuation | Switch routes and rebuild the playback session |
| Buffering occurs only in the evening | Time period, local network, and route comparison | Compare different routes at the same time |
| Only one service is slow | Target service region and exit | Choose a matching region and clear the old session |
Check hidden device-side usage
System updates, cloud syncing, photo backups, game-platform updates, and HD video on other devices all use the same access network. During troubleshooting, pause these background tasks and check that no other device is continuously transferring data through the router. On mobile devices, also check whether photos or data are being synced or restored. If pausing background tasks immediately helps, the route is not the only bottleneck; manage local bandwidth allocation first.
Client mode also affects perceived performance. Global mode sends more background traffic through the route, while split routing handles only destinations that match the rules. If global mode causes a noticeable slowdown, check whether many system services, cloud-sync tasks, or local-network tasks are being taken over. After changing modes, confirm that the target app still uses the expected route; do not bypass the connection simply to gain speed.
Order of operations for streaming and heavy transfers
When video buffers, pause and resume to confirm that the player is not simply short on temporary cache. Then reduce usage on other devices, switch to another route in the same region, and fully restart the player. If instability occurs only at high quality, read the Streaming quality and bandwidth metrics guide to understand the relationship between bitrate, sustained throughput, and automatic quality reduction. That article explains the metrics; this page remains focused on troubleshooting.
When submitting a speed issue, do not provide only one speed-test screenshot. Include whether direct access is stable, the network type, route name, target service, time period, and whether switching routes helped. Third-party test targets follow a different path from real apps, so one result cannot represent every scenario. Reproducible conditions matter more than an isolated number.
Frequent disconnections and mobile background drops
For frequent disconnections, first determine whether the route session ended, the device changed networks, the system paused the client, or the client remains connected while the target app's session expired. Moving from Wi-Fi to a mobile network, entering a battery-saving state after locking the screen, or having the system reclaim background tasks can all require a new connection. Desktop sleep, network-adapter power saving, and switching from wired to wireless can produce similar symptoms. Only after identifying the trigger can you choose the right fix.
Look for a clear trigger first
Keep the device stationary and use the same network continuously to see whether disconnections still occur. If the connection remains stable, the issue is more likely triggered by a network change, screen lock, sleep, or background policy. Test screen-lock recovery, Wi-Fi switching, waking from sleep, and extended inactivity separately. Test one action at a time. If every screen lock requires reconnection, check background operation and battery-saving settings. If the issue occurs only during a network switch, it is a connection-migration problem; wait for the client to rebuild the channel instead of immediately wiping the configuration.
If the connection also drops while the device is stationary and awake, switch routes while keeping all other conditions unchanged. If the problem follows one route, record its name. If every route drops on one fixed network but works on another, check the original network's stability, router session persistence, and Wi-Fi signal. Public Wi-Fi may periodically require access confirmation, causing the client to lose its ability to transfer data suddenly.
iOS background activity and network switching
iOS manages background activity according to system resources, battery level, and network conditions. Confirm that the client's system connection configuration still exists and has not been replaced by another network tool. Check the connection before locking the screen; after unlocking, do not rely only on the status icon—open a webpage to verify access. If the icon remains but access fails, disconnect and reconnect. If the configuration disappears after every screen lock, check whether multiple competing connection configurations exist in the system.
When the Wi-Fi signal is weak, the system may switch between Wi-Fi and a mobile network. After the underlying network address changes, the existing connection must be rebuilt; a brief interruption is not necessarily a route failure. If it does not recover, temporarily disable automatic network-switching features for comparison or retest on one stable network. Do not assess route quality at the edge of Wi-Fi coverage, where local fluctuation can obscure the real result.
Android battery saving and background restrictions
Android background policies vary by manufacturer, but the diagnostic approach is the same: confirm that the client is not restricted as a background app, that battery-saving mode does not stop its network activity after the screen locks, and that the current client still owns the system connection permission. Add the client to the allowed-background list and disable automatic background cleanup for comparison. After testing, keep only the permissions required; there is no need to grant unrelated permissions for troubleshooting.
If the system offers always-on connectivity or an option to block traffic without a connection, understand the effect before changing it. Always-on connectivity attempts to maintain the client connection; blocking traffic without a connection may temporarily disable all network access when the client restarts or fails. During troubleshooting, use the client's default behavior first. Confirm basic stability before enabling stricter system policies, or a policy-induced outage may look like a route failure.
Desktop sleep and wake recovery
After Windows or macOS wakes from sleep, the network adapter, system proxy, and virtual network interface may recover in a different order. If the client still shows Connected but websites fail, disconnect normally, wait for the local network to recover fully, and reconnect. If direct access has not recovered, reconnect to the wired or wireless network first. Do not switch routes repeatedly while the system is waking and has not yet obtained valid network parameters.
On Linux, when a system service maintains the connection, confirm that the sleep hook can restore the service and routes after wake. If the client runs in a foreground terminal, closing the terminal or ending the session may terminate it as well. Identify whether the current client is a foreground process or a system service, and do not run both methods at once. If logs show a network interface disappearing, routes being rebuilt, or the resolution service restarting, attach the relevant time range to the ticket.
Distinguish a dropped route from an app reconnecting
Sometimes the client connection remains active while a live stream, chat, or remote session disconnects. These long-lived connections may be rebuilt after a brief network change, an app being paused in the background, or a target-service timeout. Test with an ordinary webpage at the same time. If it loads immediately, the route channel is still working and you should restart the target app session first. If the webpage also fails, check the client connection. Do not infer that the entire route dropped solely from an app's “reconnecting” message.
After comparison testing, if the issue consistently occurs during screen lock or wake on a specific platform, state the platform, trigger, client recovery behavior, and whether manual reconnection is required when submitting a ticket. If it happens only on one route, provide the route name. Support does not need your account password or real subscription URL; the reproducible trigger is what matters.
Subscription update failures, empty route lists, and abnormal device status
The subscription delivers the routes available to your account to the client. An update failure does not necessarily mean the account is invalid. The copied content may be incomplete, the client may have cached old data, the current network may not reach the subscription endpoint, or the client may not support the imported format. Check whether old routes still work before handling the update. If old routes connect but the update fails, connectivity is still available and the issue is concentrated in subscription retrieval or parsing. If the route list is also empty, verify the import process first.
Confirm the subscription source and account status
Obtain the subscription from the user panel, not from a forwarded link, public page, or old chat history. 5TVPN registration requires no email address; a username and password are sufficient, so store them securely. Sign in to the user panel, copy the complete subscription again, and return to the client to update it. When copying, do not select the explanatory text beside the address or manually remove characters that appear unnecessary.
If you cannot sign in to the panel, first confirm that the username is correct and use the account flow provided by the panel instead of repeatedly creating new subscriptions. If you can sign in but the subscription status is abnormal, check whether the current monthly subscription or data package is still available. Monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; data resets monthly on the activation date, and an upgrade difference is prorated across the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. These package facts are provided to help verify the panel status, not to encourage estimating remaining data from client cache.
Distinguish download failures from parsing failures
If a subscription update reports a failed network request, timeout, or inaccessible endpoint, the client has not received the subscription content. Without changing the account details, switch the local network or use a currently working route, then try updating again. If it reports an invalid format, empty content, or an inability to parse, the content was returned but the client could not recognize it. Confirm that you are using the import entry intended for the current client. Do not treat a webpage URL as a subscription or mix import methods intended for different clients.
Some clients accept a pasted link directly, while others use system sharing or an Import button. Follow the platform-specific steps in the Guides. After importing, first check whether the subscription name and route list appear, then select a route. Do not click Update repeatedly while the list has not loaded; concurrent requests can overwrite the message and hide the actual error.
Handle old cache and duplicate subscriptions
When a client contains multiple subscriptions with the same name, you may update an old entry and then select a route from another one. Confirm the name of the currently enabled subscription first, then disable duplicates. If an old subscription is definitely unusable, delete it and import again, but confirm that the new subscription entry has been saved before deleting anything. Do not delete the entire client data directory unless ordinary deletion and re-importing both fail and you have recorded the necessary information.
Unchanged route names after an update do not necessarily mean the update failed; the service may have changed internal route parameters only. Judge the result using the client's update time, update message, and actual connection behavior together. If the client offers subscription logs, record whether the request or parsing failed, but do not show the complete URL in public screenshots. If the credentials in a link are exposed, return to the panel and address account security instead of continuing to use that link.
Understanding unlimited devices and device status
5TVPN supports any number of devices; there is no fixed device quota for you to calculate. If a client reports too many devices or an abnormal signed-in device, first determine whether the message comes from the 5TVPN user panel or from the client's local configuration, app-store account, or system connection limit. Different platforms may allow only one app to occupy the system connection entry at a time. That is a device-level mutual exclusion and is not a subscription device-count limit.
Even with an unlimited device allowance, a system will usually let only one client take over the current network at a time. Before closing the current client, disconnect normally and then start the other client. A forced exit may leave behind an old proxy, connection configuration, or route, causing the new client to report that the connection is occupied or to fail. If multiple connection configurations exist on mobile, identify which one is currently enabled.
How to use cross-device comparisons
Unlimited devices provide a useful comparison: if the same subscription works on another device using the same network, the account and network entry are probably available, so focus on the original device's client and system settings. If the same device works on another network, the issue is more likely the original network. Only when every device fails to update on every network should you focus more closely on account status or submit a ticket. Do not copy a real subscription URL to an untrusted device.
If update failures continue, state the platform, the client's import entry point, the exact message, whether old routes still work, what happened after changing networks, and whether copying the subscription again from the panel helped. If the panel itself cannot be reached, explain the difference between direct access and an established client connection. This quickly separates account status, endpoint access, and client parsing issues.
Only one app bypasses the proxy: check routing and the network stack
When the browser works but one app cannot connect, the issue is typically local to that app. The route itself is probably available, but the target app is not using the same traffic path. Possible causes include a routing rule classifying the app or domain as direct, the app using an independent network protocol, the system proxy covering only some traffic, or the app retaining a session created before the connection. Do not change the account or reinstall everything first; compare behavior around the target app.
First check whether the app is reusing an old connection
An app that was open before the client connected may continue using its old connection pool. Fully quit the target app, confirm that its background process has ended, then connect to a route and reopen it. If the app recovers, the old session simply was not rebuilt. Video, chat, game launchers, and cloud-sync tools are especially likely to keep connections open, so switching routes may not change their exit immediately.
If reopening does not help, test the web version of the same service. If the web version works but the app fails, focus on app routing, system-proxy coverage, and app cache. If both fail, the cause is more likely the target service region, route exit, or DNS. Retest with a route matching the region instead of confusing an app issue with a regional mismatch.
Understand system proxy and virtual network modes
A system proxy generally affects only apps that follow system proxy settings. Some apps open network connections directly and ignore the system proxy, so the browser may work while the app's direct connection fails. Virtual network mode can take over more system traffic, but it requires system permissions and may conflict with firewalls, filters, or other network extensions. Check the client's current mode first, then decide whether to switch; do not blindly stack multiple takeover methods.
After switching to a broader mode, restart the target app and confirm that local services still work. Local-network printing, file sharing, and device management may require direct-access rules. Split routing is not meant to forward all traffic indiscriminately; it sends cross-border targets through the route while preserving local access. Keep rule scope as explicit as possible.
Check the rule match direction
If the client offers rule, global, and direct modes, use global mode briefly for diagnosis. If the target app works in global mode but fails in rule mode, the issue is concentrated in rule matching. If it also fails globally, continue checking the app protocol, route region, and system network. After diagnosis, return to the mode suitable for daily use instead of keeping a short-term test setting permanently.
Rules may match domains, network addresses, app processes, or target regions. One app often connects to multiple domains for login, APIs, images, video, and updates. Adding only the main site domain may allow the page frame to load while its content fails. Review the client connection log for requests appearing alongside the target app and confirm which are direct and which enter the route. Use logs for diagnosis only; do not publish account identifiers or complete request parameters.
App-level DNS and encrypted resolution
Some browsers and apps use their own resolution methods and may bypass system DNS. If other system apps work while the target app continues reporting domain errors, check whether it has independent secure resolution, private DNS, or experimental network features enabled. During troubleshooting, temporarily restore the defaults so the client and system use the same resolution path. Restart the app afterward so old resolution cache does not affect the result.
If Android Private DNS, browser secure resolution, and the client's remote resolution are enabled at the same time, they may create different exits. On iOS, some network extensions or content-filter configurations also participate in resolution. Desktop browser extensions may specify their own proxy. The same principle applies: reduce intermediate layers first, verify the default path, then restore additional features one at a time.
Differences among app stores, streaming, and AI tools
App stores may consider the account region, system region, and current exit together, so simply switching routes may not change content for an already signed-in account. Streaming services also retain regional sessions and playback cache, so reopen the app after switching routes. AI tools may distribute login, API, and static resources across different domains. If one part is missing from the rules, you may be able to sign in but not start a conversation, or open the page without receiving content.
For sports streaming and other real-time apps, also distinguish between “the app is not using the proxy” and “it is using the proxy but the latency is unsuitable.” The former will usually recover in global mode; the latter requires a nearer or better-matched route. Read the sports streaming route guide for the diagnostic order in low-latency scenarios. For iOS-specific import and system-configuration issues, see the iOS client and subscription import guide.
| Comparison result | Diagnostic direction | Recommended action |
|---|---|---|
| Web version works, app fails | App routing, cache, or an independent network stack | Restart the app and check takeover mode |
| Global mode works, rule mode fails | Rules do not match all required domains or processes | Review logs and rule direction |
| Recovers after changing regions | Exit region does not match the service region | Use a route matching the region consistently |
| App fails only after screen lock | App or client background activity was paused | Check background and battery-saving policies |
When submitting this type of ticket, provide the app name, platform, whether the web version works, the difference between global and rule modes, the route region, and whether fully quitting the app restores access. Do not write only “an app does not work.” The more clearly you show which path is affected, the easier it is to identify a rule or exit issue.
When to contact support and what to include
The goal of self-checking is not to make users solve every issue alone. It is to eliminate common local variables and describe what remains as reproducible technical conditions. After basic comparisons, submit a ticket through the user panel if multiple routes fail on different networks, subscriptions cannot be updated consistently, the same route shows the same issue on multiple devices, or the problem reliably follows one route. The 5TVPN ticket entry is in the user panel; do not publish account credentials before submitting.
When a ticket is appropriate
Submit a ticket when the client consistently reproduces the same error and you have already checked direct access, changed networks, changed routes, and restarted the client. Repeating the same steps will not add useful information. An empty route list that still fails after importing again from the panel, connections that cannot be established on different networks, a route that remains unusable, and the same subscription parsing error on multiple devices are all appropriate reasons to contact support.
For monthly subscriptions, data packages, payment status, or refunds, use the orders and ticket flow in the panel. 5TVPN supports Alipay, WeChat Pay, and USDT, and offers a 14-day no-questions-asked refund. State the status currently shown on the order page, but do not upload sensitive information from payment records. Check package details on the Plans page. Monthly data resets each month on the activation date, with upgrade differences prorated across the remaining days; data packages remain valid until used and never expire. If the panel differs from your expectation, attach a screenshot of the order status shown there.
What a useful support ticket should contain
The ticket title should describe the symptom and platform, such as “All websites fail after macOS connects” or “Android connection needs manual recovery after screen lock.” In the body, describe the situation where you first noticed the issue and whether it reproduces consistently. Then list the platform, network type, client mode, route name, exact error message, and comparison steps already completed. Finally, state which actions temporarily restore access and which have no effect.
Screenshots should include enough context. A client error screenshot should ideally show the connection status and route name; a subscription-update screenshot should show the update entry and error while hiding the complete subscription URL; a webpage error screenshot should retain the domain and browser message but remove personal information. If you provide logs, include only the relevant portion around the failure rather than a complete file containing long-term history, usernames, or request parameters.
Issue:
Platform:
Current network:
Selected route:
Client mode:
Error message:
Can the issue be reproduced consistently:
Result after changing routes:
Result after changing networks:
Result after re-importing the subscription:
Temporary workaround:Fill in the template based on the actual situation. For anything that does not apply, say so rather than guessing. In particular, do not decide on your own that it is a “server failure” and submit only that conclusion; include the evidence you observed. Support needs to know whether the issue follows the route, network, device, or app to decide whether to inspect the route entry point, subscription content, or platform configuration.
Information that should not be included in a ticket
Do not submit account passwords, complete subscription URLs, payment passwords, or login credentials for other services. Support usually does not need them to troubleshoot connectivity. If account confirmation is needed, submit through the signed-in user panel only. Do not forward ticket screenshots to public communities either, as they may contain usernames, order status, route names, or device information.
Logs may contain network addresses, visited domains, and local paths. Read them before sending and keep only the portion near the failure. If you are unsure whether something is sensitive, submit a written description and error screenshot first, then wait for support to tell you which diagnostic material is needed. The minimum-necessary principle protects the account and reduces irrelevant information.
How to retest after submitting a ticket
After submitting, keep the reproducible environment whenever possible. Do not immediately delete the client, reset the system, or replace every configuration. If support asks you to switch routes, update the subscription, or restore defaults, record the result after each step and reply in the original ticket. Do not create multiple tickets for the same issue, or the context will be fragmented. If the issue resolves by itself, add the recovery time and whether you changed the network or route so support can distinguish a temporary condition from a configuration change.
If support provides a temporary replacement route, first confirm that it reliably fixes the current scenario before deciding whether to continue investigating the original route. For evening congestion, mobile network changes, or a specific app, retesting must reproduce the original trigger. Confirming that everything works under different conditions does not prove the issue is fixed. Before closing the ticket, make sure the affected scope, current workaround, and reproducibility are clear.
Organize the configuration after troubleshooting
After the issue is resolved, delete duplicate subscriptions and unused old clients, restore necessary battery-saving and privacy settings, and keep one known-good route as a future baseline. Do not leave global mode, overly broad rules, or extra system permissions enabled solely for diagnosis. If the conflict involved a browser extension, network filter, or another proxy tool, record the combination so you do not enable it again at the same time.
Store the username and password securely. 5TVPN requires no email address for registration, so account recovery depends more heavily on keeping your own login credentials safe. Treat the subscription URL as an account credential as well. When using a new device, obtain it again from the user panel instead of relying on public chats or forwarded links. Get the client through the user panel.
Use this guide for systematic diagnosis. Follow the Guides for quick installation and first-time import; refer to the Locations page for regions and route types; and use the Plans page and user panel for pricing, data, and payment information. Following this order avoids unnecessary reinstalls and gives support enough context to identify the specific layer involved.