Troubleshooting Guide

Establish a reproducible troubleshooting method first

The most common reason troubleshooting fails is not the lack of an advanced setting, but changing too many conditions at once. If you switch routes, change modes, edit DNS, reinstall the client, and restart the router together, you may restore the connection without knowing which step worked. The next time the same issue occurs, you are still left guessing. A more reliable approach is to preserve the current state, change one variable at a time, and record the results before and after each change. Record more than “it doesn’t work”: note whether the client completed the connection, whether a browser can open a regular website, whether one app or all apps are affected, whether the symptom changes on another network, and whether the problem is concentrated on a particular route type.

Break the connection into several independent layers. The local network layer connects the device to the internet; the client reads the subscription, selects a route, and establishes the connection; the system proxy or tunnel layer takes over app traffic; DNS converts domain names into reachable addresses; the remote route forwards requests to the target service; and the target service may return different results based on region, account status, or access method. When the client shows “Connected,” it only means the handshake completed—not that every layer afterward is working. Conversely, a website failing to open does not by itself prove that the route is down, since browser cache, DNS resolution, and the target site’s status can create similar symptoms.

Start with a minimal test

A minimal test reduces a complex environment to one client, one route, one browser, and one clearly defined target. Temporarily quit other software that changes the network path, disable browser proxy extensions, and avoid running multiple acceleration clients at the same time. After choosing a familiar route, open a regular website first, then test the service you actually need. If regular websites work but a specific service fails, focus on region, routing rules, cache, or the target service instead of reinstalling the client again. If every website fails, check the system proxy, DNS, and local network.

Keep a control set

A comparison test should include both the disconnected and connected states. With the client disconnected, confirm that the local network can open websites that are normally accessible; then repeat the same test after connecting. If access fails even while disconnected, the issue lies with the local network or device system, so switching routes blindly will not help. If disconnected access works but everything fails after connecting, check client permissions, system-proxy conflicts, and DNS. If only some services fail after connecting, review the matched rules and exit region. Comparing devices is also useful: if another device works on the same network, the current device’s configuration is the likely cause; if several devices fail at once, the local network, route, or subscription status is more likely responsible.

First-time users should complete the main setup flow through the Getting Started Guide. This guide does not repeat every platform’s full installation process; it explains the reasoning behind common symptoms. To understand different regions and route types, also see the Route List. During troubleshooting, do not delete a subscription configuration that still works, and never paste the real subscription URL into a public webpage, search box, or public discussion. When submitting a ticket, describe only the subscription name shown in the client and the symptoms.

Cannot connect at all: check everything from the local network to the handshake

“Cannot connect at all” should be divided into several states: the client will not start, the subscription will not load, an error appears immediately after clicking Connect, the client remains stuck on Connecting, or it shows Connected but no traffic passes. These states may look similar but occur at different stages. A client that will not start points to system permissions or installation; no available routes points to subscription import; an immediate failure is often related to the route, time, permissions, or configuration; a prolonged Connecting state usually means the handshake has not completed; and Connected with no traffic requires checking the system proxy, tunnel permissions, and DNS rather than simply concluding that the route is unavailable.

Check the basic network and system time

Fully disconnect the client first, then use a browser to open websites that normally work. If the basic network itself is unavailable, reconnect to the current network or switch to another available network for comparison. Some public networks require browser-based login confirmation; until that step is complete, the acceleration client may not establish a stable path. The system date and time should also be set to automatic synchronization, since a noticeably incorrect clock can affect certificate validation and encrypted handshakes. After adjusting it, quit and reopen the client so it can reread the system’s network state.

Next, check whether the client contains selectable routes. If the route list is empty, the update time looks abnormal, or an error appears beside the subscription name, go directly to this page’s subscription update section. If routes are present, first test a familiar route in another region rather than clicking several nodes rapidly. Wait for the client to finish changing states after each switch, then test in a new browser window. An old tab may retain a previous connection, cache, or resolution result, so using it to judge a new route can lead to the wrong conclusion.

Rule out multiple clients and system-proxy conflicts

Running multiple clients that take over the network on the same device is a common cause of connection failures. One program may enable the system proxy while another creates a tunnel; after one is closed, its settings may not be restored, leaving the client apparently healthy while the system has no correct exit path. Quit all related programs and keep only the client currently in use. Then disable and re-enable its system proxy or tunnel mode once. If the client says it needs to establish a system connection or receive network permission, confirm that permission in system settings instead of repeatedly clicking Connect.

Security software, the system firewall, and managed networks may also prevent the client from connecting. Do not permanently disable protection features. A safer comparison is to switch briefly to another network: if the connection works there, the client and subscription are broadly functioning, so inspect restrictions on the original network; if it fails on every network, continue checking device permissions, client configuration, and routes. In workplaces or schools with explicit network policies, follow their requirements and do not attempt to modify policies on managed devices.

If multiple routes, different networks, and a restarted client all fail to complete the connection, stop reinstalling repeatedly. The more useful evidence is the exact error text, client type, operating system, selected route name, time of occurrence, and whether the basic network was working. Do not submit only a screenshot of the red warning area. Include the client status and route name, and copy any selectable error text. A ticket with this context is much easier to classify as a local-permission, subscription-parsing, or route-handshake issue.

Connected but websites will not open: proxy interception and DNS issues

If the client shows Connected while the browser reports that the server cannot be found, the connection timed out, or the page keeps loading, the problem has moved beyond the initial connection stage. Determine whether the request entered the client and, if so, whether it is stuck at DNS resolution, routing, or the target service. The most direct way to observe this is to open the client’s connection records or logs, then refresh a new webpage. If no new connection appears at all, the browser traffic is not being handled by the current mode; if the domain appears but the connection cannot be established, focus on the route and rules; if the log shows only resolution errors, address DNS first.

Check whether the browser is bypassing system settings

Some browser extensions configure a separate proxy, and certain browsers use their own secure DNS. They may bypass the system proxy or send DNS queries through a channel that does not match the current route. Start with a browser window that has no proxy extensions, temporarily disable extensions that modify networking, and let the browser follow the system network settings. If a regular window fails but a clean environment works, the issue is usually the extension, cache, or the browser’s own network policy rather than the subscription.

System proxy mode mainly handles programs that follow system settings; tunnel mode usually covers more traffic but requires system permissions. If the browser works while other software does not, the latter may not read the system proxy. If no program has traffic, check whether the client has actually enabled the relevant mode. Disconnect before changing modes, then reconnect after the switch so an old session does not continue occupying the network path. Do not enable system proxy and tunnel features in multiple clients at the same time.

Use commands to distinguish resolution from connection issues

The commands below use a public example domain and contain no subscription information. Query the domain first, then request the webpage response headers. If the domain query fails and the request also reports that it cannot resolve the name, the issue is concentrated in DNS. If the name resolves but the connection times out, continue checking the route, rules, and target service. Command-line output is only a diagnostic reference and does not represent the final browsing experience.

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

DNS cache may retain a resolution result from before the connection. After closing the browser, use the appropriate cache-flush command for your system, then reconnect and test again. Run commands in the system terminal; if administrator permission is required, verify the command before granting it. Flushing the cache does not change the subscription or plan.

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux:
resolvectl flush-caches

If a command is unavailable in the current Linux environment, do not install unrelated software just to flush the cache. Restarting the system network connection or client can also rebuild many temporary resolution states. On mobile devices, disconnecting and reconnecting to the current network, then quitting and reopening the client, can clear the session. Afterward, test in a new tab rather than repeatedly refreshing the page that kept failing.

When only some websites fail

When regular websites work but a specific service fails, first verify that the current exit region meets that service’s access requirements, then switch to another route in the same region. Clear the site’s cookies and cache, or use a private window to rule out an old session. If the target service also fails when disconnected, consider the service’s own status or the account status. If other devices can access it through the same route, focus on the current device’s browser extensions, DNS, and routing rules. If several devices behave the same way, include the route name, target domain, and error-page text in the ticket.

Users sometimes confuse DNS leak-test results with a website not opening. The former concerns where DNS requests travel; the latter concerns whether the domain resolves and the connection completes. Troubleshoot availability first, then inspect the resolution path based on the client mode. Frequently switching among unfamiliar DNS addresses adds variables and can turn a simple route issue into a combined DNS-and-route problem. Restoring the client’s default settings is usually a more reliable baseline than trying random parameters one after another.

Slow speeds and peak-hour lag: separate bandwidth, latency, and congestion

Slow performance is not a single metric. A webpage that takes a long time to show its first screen is usually more affected by latency, DNS, and connection setup; slow large-file transfers point more toward sustained bandwidth; repeated video buffering is also shaped by the target platform, adaptive quality, and route stability; and long waits after typing in an interactive tool may indicate sensitivity to round-trip latency. Describe exactly what is slow before choosing a test. Summarizing the entire experience with one speed-test result often mixes together target-service issues, wireless fluctuations, and route congestion.

Compare under matching conditions

Before testing, pause system updates, cloud-drive synchronization, and background downloads, and make sure no other device is continuously using the local network. With the client disconnected, complete one real task—for example, open the same regular webpage or download the same public test file—then repeat it after connecting. Use the same device, local network, and target for both tests; do not use wireless in one and switch networks in the other. Then change only the route without altering other settings. This is the only reliable way to identify whether the bottleneck is local access, a particular route, or the target service.

When choosing a route, consider geographic distance and purpose rather than popularity of the region name alone. A nearby route is usually a useful baseline; for services with regional requirements, choose an exit that meets them. Dedicated, relay, and direct routes have different path characteristics, so their names cannot prove that one type will be better at every time of day. Check the available regions and route types on the Route page, then validate them one by one on the current network. Avoid switching through too many routes in a short period, because cache, old connections, and target-service sessions may continue using the previous path.

How to assess lag that occurs only at peak hours

If performance is normal during the day but noticeably slower in the evening, first check whether the local network is congested at the same time. Disconnect the client and access locally available services, observing whether webpages, downloads, and video all slow down together. If the basic network has deteriorated, switching remote routes can only help partially. If the basic network is stable but one route repeatedly lags, compare a different path type or a nearby region. If only one video platform buffers while regular websites and downloads work, the issue may be concentrated in the target platform’s path, regional detection, or content-delivery node rather than all routes.

Client mode also affects performance. Rule mode sends only matched traffic through the route and suits everyday use, but an incorrect rule may send related domains through different exits. Global mode is useful for checking whether routing is the cause, though it may not be suitable as a permanent default. During troubleshooting, briefly switch to Global mode for comparison: if Global works but Rule mode fails, inspect the rules; if both modes are slow, continue comparing the route, local network, and target service. Restore the mode suited to everyday use after testing.

Do not change large numbers of low-level parameters just to chase a peak speed-test result. Parameters interact with the local carrier network, system implementation, and client mode, and a poor combination may reduce stability. A more useful goal is completing real tasks consistently: predictable webpage responses, no frequent video quality drops, and no long stalls during file transfers. If several time periods, networks, and routes all remain abnormal, include the test purpose, route name, network type, time period, before-and-after differences, and client logs in the ticket. A speed-test screenshot can supplement the report but cannot replace these conditions. For another self-test method focused on stability, see Connection Success Rate and Disconnect Rate: A Hands-On Comparison.

Frequent disconnects and mobile background dropouts

For frequent disconnects, first distinguish between a route session interruption and the client being paused by the system. The former usually means the client remains in the foreground while its connection status changes or the log shows reconnect attempts. The latter is common after locking the screen, switching apps, or enabling power saving; when you return to the client, the system has stopped its background activity. The remedies differ: compare networks, routes, and switching conditions for session interruptions; check system permissions, battery policies, and persistent-connection settings for background suspension.

Record what triggers the disconnect

Do not record only “it disconnects often.” Note whether the disconnect occurs while idle, after locking the screen, during a network switch, during video playback, during file transfer, or after the device wakes. If it disconnects every time the device switches networks, the underlying network interface has changed and the client usually needs to establish a new session. If it drops periodically on the same network, compare route and local-network stability. If it drops only after the screen locks, check background permissions first. The clearer the trigger, the easier it is to reproduce and diagnose.

On desktop systems, sleep and wake rebuild the network interface. After waking, an old connection may still appear active but no longer transmit data. In this state, disconnect and reconnect in the client before restarting the system. If that restores service, the issue is related to session resumption after sleep. If it does not, quit the client, confirm that the basic network works, and start it again. Similar behavior can occur when connecting a dock or switching between wireless and wired networks.

Mobile background permissions

Mobile operating systems restrict background apps according to battery policies. In system settings, allow the client to maintain the necessary background activity and confirm that its system-connection permission is still valid. Settings names vary by system, so do not rely on one fixed menu path. Look under app information, battery management, or system connection settings for options related to background activity, auto-start, and battery restrictions. After changing them, reopen the client, connect, lock the screen, and return to the browser to test whether access remains continuous.

If the connection indicator in the system status bar disappears after the screen locks, the client or system connection was likely stopped. If the indicator remains but apps cannot access the network, the cause may be a network switch, DNS, or an expired session. Check background policies in the first case; in the second, disconnect and reconnect once, then inspect the network. Do not run multiple persistent network tools at the same time, as they may compete for the same system connection permission and replace one another in the background.

Compare the route with the local network

On the same network, switch to another route. If the disconnects stop, the original route or path deserves closer inspection; if several routes disconnect, switch the local network for comparison. Stability on another network usually points to the original network quality, routing equipment, or access policy. If no network is stable, check client permissions, system time, conflicting software, and subscription settings. If the same account is stable on another device, prioritize the system policies on the affected device. 14VPN supports Windows, macOS, iOS, Android, and Linux, and background-management behavior differs by platform; desktop persistence logic cannot be applied directly to mobile.

When handling network instability, avoid enabling an overly aggressive automatic route-switching strategy. Excessively sensitive switching can amplify a brief fluctuation into repeated reconnects and interrupt downloads, meetings, or long-lived connections. Fix one route first to confirm baseline stability, then decide whether automatic selection is needed. The ticket should state whether the client was still running when the disconnect occurred, whether the system connection indicator remained visible, whether the network changed, whether the app was in the foreground or background, the route name, and whether reconnecting restored service immediately. If logs are available, capture the adjacent lines before and after the failure, removing any subscription URL before submitting.

Subscription update failed: handle the URL, network, and cache in layers

A failed subscription update and a failed route connection occur at different stages. The subscription delivers route configuration to the client; the route connection uses imported configuration to establish a session. Therefore, an old route that still connects but cannot update does not mean the entire service is immediately unavailable. An empty route list does not prove that all remote routes are down; it more likely means the subscription was not read successfully. Preserve any configuration that still works. Create or reimport a new entry first, confirm it works, and only then remove the old one.

Confirm the subscription retrieval path first

The client and subscription must be obtained from the user panel. After signing in, open the relevant download page and copy or import the subscription for the current platform. Do not use links from search engines, old chat messages, or other people. Marketing pages do not provide static installers or real subscription URLs. To retrieve it again, visit the User Panel download entry. No email address is required for registration; a username and password are sufficient. Store your sign-in details securely so you do not keep trying an outdated subscription because you cannot access the panel.

When copying a subscription, make sure it contains no extra spaces, line breaks, or punctuation. Some apps include punctuation at the end of a link, which makes the request URL invalid. Paste it into a local plain-text editor first to check both ends, then import it into the client. Do not send the link to a public online tool for verification. Example URLs in tutorials or documentation are for demonstrating the format only, for example:

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

This example is not a real subscription and cannot be used to connect. Obtain the real URL only from the user panel and store it on a controlled device.

Determine whether the download or parsing failed

Errors mentioning a timeout, connection failure, or domain resolution mean the client did not successfully download the subscription content. Check the basic network, system time, and DNS first. Errors such as invalid format, empty content, or unrecognized data mean the response may not be subscription content, or the client and import method may not match. Return to the panel and choose the import entry for the correct platform instead of manually editing URL parameters. If the panel opens in a browser but the client never updates, check whether another proxy setting is affecting the client and try updating after disconnecting the current session.

If the update succeeds but the route list does not change, the client may still be showing cached data. Check the subscription’s update time or refresh the list manually, then fully quit and reopen the client. Do not create multiple subscriptions with the same name in succession, or it will be difficult to tell which one is actually in use. Give the retained subscription a clear name and remove the old entry only after confirming the new configuration works. Before deleting anything, make sure it is not the only working configuration.

Check subscription status and traffic

If the panel shows an abnormal plan status or the current traffic allowance has been used up, client updates and route use may be affected. Check the current subscription in the panel first. 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 mid-cycle upgrades are prorated by the remaining days. Usage-based packages that remain valid until depleted and never expire are also available: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. Compare options on the Plans page instead of inferring account status from a cached name in the client.

If retrieval, switching networks, correcting the time, and reimporting through the matching platform method still fail, include the client name, operating system, exact error text, subscription update time, whether the panel opens normally, and whether old routes still work. Do not include the real subscription URL or a complete configuration file. If support needs to verify the account, provide the username and issue description; never put the password in the ticket.

An app is not using the proxy: check the mode, rules, and process

When a browser works but one app cannot connect, the issue is typically traffic interception or routing. First confirm whether the app follows the system proxy. Browsers commonly read system settings, while games, command-line tools, some desktop apps, and software with its own network stack may not. Under system-proxy mode, a working browser does not prove that the other app is being handled. Tunnel mode generally covers more traffic but depends on system permissions. The goal is not to edit rule files immediately, but to first prove whether the app’s connection enters the client.

Observe connection records and processes

Open the client’s connection records and clear them—or note the current last entry—then trigger one clear request in the target app. If the client shows the corresponding domain, address, or process, the traffic has entered the client; check whether it matched a direct or proxy rule. If no new record appears, the current mode is not handling the app, or the app is using another network interface. In clients that show processes, confirm that the record belongs to the actual executable rather than the launcher. Some apps separate the interface process from the network process, so setting a rule only for the launcher may have no effect.

Temporarily switching to Global mode is a useful comparison. If the app works in Global mode, the route is available and the issue is concentrated in rule matching; if it still fails, check the app’s own settings, target region, DNS, and route. Restore the original mode afterward. If the client supports rules by domain, process, or application, prefer readable conditions with a clearly defined scope and avoid broad wildcards. The wider the rule, the more likely it is to redirect unrelated traffic.

Check the app’s internal proxy settings

Some apps have their own proxy options. They may be set to direct connection or may retain a local address from an old client, bypassing the current system settings. Restore the app to follow the system, or configure it with the local proxy information provided by the current client. Do not copy ports or addresses from another tutorial; these values depend on the current client settings and can only be verified locally. If the app supports automatic detection and manual proxy settings, start by testing with system settings.

Command-line tools may also read environment variables. In the terminal, check whether proxy variables remain in the current environment:

Windows PowerShell:
Get-ChildItem Env: | Where-Object Name -Match 'PROXY'

macOS / Linux:
env | grep -i proxy

If the output points to an old client that has already been closed, clear the relevant variable in the current terminal session or system environment settings, then reopen the terminal. Do not copy an unknown removal command directly; confirm the variable name and source first. If no related variable exists and command-line requests still do not enter the client, compare with tunnel mode or configure the local proxy according to the current client’s documentation.

Domains, regions, and cache

An app may connect simultaneously to login domains, API domains, static resources, and long-lived connection services. Adding a rule only for the main domain can leave the interface working while content fails to load. While observing connection records, collect related domains throughout the full operation and check that they use a consistent exit. Do not bulk-add rules from old domain lists found online, since service domains change. Current connection records are a more reliable basis.

If the app requires a particular exit region, choose a route that meets its service conditions and clear the app cache or sign in again before testing. An old session may retain the region information from before the connection. For networking considerations in AI image tools and the Discord ecosystem, see Midjourney Acceleration Requirements Explained. If the app still fails in Global mode while the browser can access related pages through the same route, submit the app name, platform, failed action, exact error text, current mode, and connection records in a ticket instead of writing only “this app doesn’t work.”

Device messages, account checks, and effective support tickets

14VPN supports unlimited devices. If the client shows “device limit exceeded,” “abnormal session,” or a similar message, do not conclude that the plan has a device limit. First determine whether the message comes from the current client, the target service, or a system network component. Some target services limit their own login sessions, while some clients describe configuration conflicts, duplicate authorization, or old connections as device issues. These messages are not equivalent to a 14VPN plan restriction. Preserve the complete message, identify which app displayed it and what action triggered it, and check whether it remains after signing out of the target service account.

Rule out mixed accounts and configurations first

Confirm that the current device imported a subscription obtained from the user panel under your own account. Do not mix historical accounts, someone else’s configuration, or a subscription from an unknown source. Multiple devices can use the same account’s valid subscription, but each device should import it from a controlled source, and the real subscription URL should never be shared publicly. If one device is abnormal while others work, retrieve the subscription again from the panel and create a clearly named new configuration on the affected device. Delete the old configuration only after the new one is confirmed to work. If all devices show the same account-status issue, check the subscription status and traffic in the panel instead of reinstalling on each device.

If panel sign-in fails, first check the username and password. Registration does not require an email address, so the username is the account identifier. Do not repeatedly edit different configurations on multiple devices before reporting the issue, as this destroys the comparison conditions. Choose the easiest device to reproduce the issue as the primary test environment and keep another working device as a control. Payment-related issues should state the selected plan and payment method; the site supports Alipay, WeChat Pay, and USDT. Do not send payment passwords, account passwords, or the complete subscription URL in a ticket.

When should you stop troubleshooting on your own?

Submit a ticket once the issue remains reproducible after comparing the basic network, another network, another route, a single-client environment, and a restart. It is also appropriate to contact support when the account status disagrees with the panel, the subscription cannot be retrieved repeatedly, multiple routes fail across different networks, or the same error occurs on multiple platforms. If the issue appears only with a browser extension, a particular target-service account, or a managed network, address that environment first, since support cannot remotely change a third-party service’s status or an organization’s network policy.

Preparing ticket attachments

Screenshots should include enough context: client status, route name, error message, and the action being performed. Cropping unrelated desktop content protects privacy, but do not submit only a title-less error dialog. Text logs are more useful than a single screenshot for analyzing the connection process; capture the adjacent lines before and after the failure. Before submitting, search for and remove real subscription URLs, access tokens, passwords, and other credentials. If the log is long, reproduce the issue once and export the content around that action.

When describing time, state the time period and time zone. When describing the network, say whether it is home, office, public, or another access environment; no detailed address is needed. Use the complete route name shown in the client. For speed issues, describe the specific task—initial webpage loading, sustained download, video buffering, or interactive latency—and include the comparison before and after connecting. For disconnects, state whether the screen was locked, the network changed, the device was asleep, or the app was running in the background. For subscription issues, state whether the download failed, parsing failed, or old content remained after refreshing.

Issue type:
Operating system and client:
Route used:
Is the basic network working:
Action taken and exact error text:
Can the issue be reproduced consistently:
Result after changing routes:
Result after changing networks:
Troubleshooting steps completed:
Attachments:

Keep the test environment reasonably stable after submitting. If support asks you to reproduce a step, test under the specified conditions and report the result; do not change the client, rules, DNS, and network equipment simultaneously while waiting. Verify one hypothesis at a time so the logs and feedback correspond. To submit a request through the user panel, use the Support Ticket entry. If the issue ultimately concerns plan selection, see the Plan Details; 14VPN offers a 7-day no-questions-asked refund, with the specific terms governed by the site’s Terms page.

The goal of system troubleshooting is not to memorize every command, but to establish a reliable order of judgment: confirm the basic network, then the subscription and client, followed by traffic interception, DNS, routes, and the target service, and finally narrow the scope through comparison tests. When the symptoms, conditions, and results after each change are recorded clearly, most vague “it occasionally stops working” issues can be turned into specific, reproducible problems that can be addressed.