A VPN that worked yesterday can stop connecting for several different reasons: the current network may be blocking or interrupting the connection, the subscription may no longer be available to the client, the operating system may have denied a permission, or the selected protocol and route may not suit the present network. Reinstalling the app immediately is rarely the best first move. A more reliable approach is to identify the exact stage that fails: opening the client, updating the subscription, establishing a connection, applying the system proxy, or loading a specific website or application.
This guide follows that order. It covers quick checks for Windows, macOS, Android, iOS, and Linux, as well as common third-party clients such as Clash Verge, sing-box, and Shadowrocket. The goal is not to force one protocol or one mode to work everywhere. The goal is to narrow the problem down, change one variable at a time, and keep a clear fallback plan if the first route does not respond.
Check the local network and account status first, then refresh the subscription, verify permissions, change the route, and only afterward switch protocols or clients. If one route fails but another works, the problem is usually route-specific rather than a completely broken account.
Identify Where the VPN Fails
“The VPN is not working” can describe several completely different symptoms. The client may open normally but show no routes. It may display routes but fail during connection. It may report a successful connection while the browser still uses the local network. A website may load but an application may not, or only one domain may be unreachable. These cases require different fixes, so begin by recording what you can actually observe.
90+
Countries covered
200+
Available routes
5
Main platform groups
1
Variable to change at a time
There are four useful failure categories. A subscription problem appears when the route list is empty, outdated, or unable to update. A connection problem appears when the client repeatedly times out, refuses a handshake, or disconnects immediately. A system-routing problem appears when the client says connected but applications continue using the original network. A destination problem appears when ordinary websites work but one service, region, or application still fails.
Before changing settings, note the client name, operating system, selected route, selected protocol if visible, and the exact error message. Avoid posting a complete subscription URL or a full configuration file in a public forum. Subscription URLs can contain account credentials, and configuration files may include access tokens. If you need help, redact those values while keeping the general error text and client version visible.
- ✅ Check whether the client itself opens without crashing.
- ✅ Check whether the subscription refreshes and displays route names.
- ✅ Check whether the client reports a successful connection.
- ✅ Check whether the system proxy or virtual interface is enabled.
- ✅ Test more than one destination instead of judging the connection from one website.
- ❌ Do not change the client, protocol, route, and DNS settings all at once.
- ❌ Do not publish the full subscription link when asking for troubleshooting help.
A useful first test is to disconnect, close other proxy or VPN applications, and reconnect with one ordinary browser window. If the browser works but a desktop application does not, the application may ignore the system proxy or require a virtual network interface mode. If nothing works, continue with the account and network checks below.
Check the Network and Account Status
The local network is the simplest cause to eliminate. Switch temporarily between Wi-Fi and mobile data, or try another trusted connection if one is available. This does not prove that the original network is permanently blocking anything; it only tells you whether the failure follows the device or follows the access network. Public Wi-Fi, school networks, office networks, hotel networks, and captive portals may restrict unknown traffic, UDP, long-lived connections, or encrypted tunnels.
Complete any captive-portal login before starting the client. A network that requires a browser confirmation page may allow ordinary web access only after that page is accepted. Also check whether the device has a restrictive firewall, security suite, DNS filter, parental-control profile, or enterprise management policy. Do not permanently disable security software as a first response. If a controlled device blocks the client, ask the administrator or use an approved network instead.
Next, sign in to the user panel and confirm that the account and plan are active. If the account page cannot be opened, distinguish between a panel-access problem and a client-connection problem. If the plan is active but the client cannot refresh the subscription, the subscription address may be incomplete, outdated, or unreachable from the current network. Copy it again from the panel rather than relying on an old message or screenshot.
Subscription links should be treated as private account information. Import them directly into a trusted official client or a compatible client such as Clash Verge, sing-box, or Shadowrocket. A conversion website may expose the URL and its access parameters to a third party. If the client has an old subscription entry, remove only the outdated entry after saving any custom settings you still need, then import the current source again.
| Observed symptom | Most likely area | First action |
|---|---|---|
| Client opens but shows no routes | Subscription or parsing | Copy the current subscription again and refresh it |
| Routes appear but every route times out | Local network or protocol | Test another network, then try another route |
| Client says connected but browser uses the old network | System proxy or routing mode | Enable the appropriate proxy or virtual interface mode |
| Browser works but one application does not | Application routing | Check process rules and whether the app honors system proxy settings |
| Only one service fails | Destination or exit address | Try another region or route before changing the whole client |
Make sure the device date and time are correct. Significant clock errors can interfere with certificate validation and encrypted handshakes. Also check available storage and background restrictions on mobile devices. A client that cannot write its subscription database, or an Android system that repeatedly stops a background service, may appear to have a route problem when the underlying issue is local device management.
Apply Platform-Specific Quick Fixes
Windows
On Windows, first check whether another VPN, proxy client, or corporate security tool is already controlling the system proxy. Running Clash Verge, an official client, and another proxy utility at the same time can create conflicting routes, ports, or virtual adapters. Close the other clients completely, including their tray processes, before testing again.
Review the Windows proxy settings and compare them with the mode selected in the client. A client using system-proxy mode may not affect applications that use their own proxy settings. A client using a virtual network interface mode may require permission to install or operate its adapter. If Windows displayed a permission prompt during installation, refusing it can leave the application open but unable to route traffic correctly.
Check Windows Defender Firewall or another security product for a blocked client process. Prefer allowing the trusted application through the firewall rather than turning the firewall off. If the client has a connection log, look for repeated timeout, DNS, handshake, or permission messages. Those terms are more useful than a generic “failed” status when deciding whether to change the network, route, or protocol.
macOS
On macOS, review System Settings for VPN profiles, network extensions, filters, and login items associated with the client. A system update or a newly installed security tool may require network-extension approval again. If a client reports that it is connected but Safari or another application remains unchanged, check whether the client is using a system proxy, a network extension, or only an application-local proxy.
Remove stale duplicate profiles only when you know which profile belongs to the current client. Deleting every network profile at random can create a second problem. Quit the client, reopen it, and grant the requested permission when macOS asks. If the client is an official application, use its own update and repair options where available. If it is a third-party client, confirm that the imported configuration matches the protocol it supports.
Android
Android commonly stops background services through battery optimization, background-data limits, or vendor-specific task killers. Open the application settings and allow the client to run as required by its connection mode. Also check whether another application has taken control of the Android VPN slot. Android generally permits one active VPN service at a time, so a second VPN or filtering application can prevent the intended client from connecting.
When importing a subscription on Android, confirm that the client has received the complete URL and that the route list is populated after an update. If the list is present but traffic does not pass, accept the Android VPN permission prompt and inspect whether the client is set to route only selected applications. A per-app list can easily exclude the browser or include only one test application. Test with a simple browser request before adjusting advanced routing rules.
iOS
On iOS, the client normally needs permission to add a VPN configuration. If that permission was declined, open the client again and look for its connection or profile authorization flow. Check Settings for an existing VPN profile and make sure another VPN application is not active. iOS may also stop a connection when the profile is incomplete, the subscription has not been refreshed, or the selected application mode excludes the app being tested.
Use a trusted network to refresh the subscription, then reconnect after the route list has updated. If a browser works but a particular application does not, inspect the client’s rule or per-app behavior before assuming that the route is unavailable. iOS applications can use their own networking behavior, and not every application responds to a simple browser-style proxy setting.
Linux
Linux troubleshooting depends heavily on the desktop environment and the client type. An official client, sing-box, and a graphical client such as Clash Verge may use different methods: system proxy variables, a local SOCKS or HTTP port, a TUN interface, or policy-routing rules. Confirm which method is enabled before testing. A route can be healthy while the shell, browser, or application is simply not configured to use the client’s local endpoint.
Check whether another service already occupies the local port, whether the user has permission to create a TUN device, and whether the firewall permits the required traffic. If you use systemd to start a client, inspect its service status and logs rather than launching a second copy manually. For command-line tools, verify proxy environment variables and remember that some programs ignore them entirely. Start with one application and one routing method, then expand the configuration after the basic connection is confirmed.
When the client says connected but only some applications work, investigate proxy scope, virtual-interface permissions, per-app rules, and application behavior before replacing the subscription.
Change the Route, Protocol, and Connection Mode
If the subscription is current and the client can display routes, change the selected route before changing the entire configuration. A single route may be temporarily unavailable, congested, incompatible with the current access network, or unsuitable for the destination. Select another region that is logically close to your target service, connect again, and test the same browser or application. Keep the test consistent so that the result tells you something useful.
Route names alone do not guarantee identical behavior. Providers may offer direct routes, relay routes, or different transport arrangements. IEPL, BGP, and CN2 are routing or connectivity descriptions, not universal guarantees of speed for every destination. A route with a premium-sounding label can still be unsuitable for a particular network or service. Compare connection success, stability, DNS behavior, and application compatibility rather than choosing only by name.
Protocols also behave differently. Shadowsocks is commonly used as an encrypted proxy protocol with a lightweight client model. VMess and Trojan are proxy protocols with their own authentication and transport arrangements. Hysteria2 uses QUIC-based transport and may behave differently from TCP-oriented options on networks with loss or strict UDP handling. WireGuard is a VPN protocol that creates a virtual network interface and has a different configuration model from subscription-based proxy profiles. A client must support the protocol and its required transport; importing an incompatible profile will not be fixed by repeatedly pressing connect.
When switching protocols, change only the protocol or route first and keep the same destination test. If the new option works, record the original failure message and return to the original setting only if you need to compare. If every protocol fails on one network but works on another, focus on network restrictions or DNS interception. If every network fails with one profile but a freshly imported profile works, focus on the subscription entry or profile data.
Connection mode matters as much as protocol. Global mode sends a broad range of traffic through the selected route, while rule mode or split tunneling sends only matched destinations through it. A browser may work in global mode while a game launcher, terminal, or streaming application bypasses the route in rule mode. Conversely, global mode can expose local services or make domestic applications behave unexpectedly. Use the narrowest mode that meets your purpose, and confirm the active route with the client log or an external address check.
Refresh DNS and Application Routing
DNS problems often look like a failed VPN. The tunnel may be established, but the device may still use an unreachable or filtered resolver, or the client may be configured to send DNS outside the intended route. If the client provides a DNS mode, choose a documented option supported by that client and test again. Avoid adding several public DNS addresses at random, because inconsistent resolvers can make results harder to interpret.
On desktop systems, restart the affected application after changing proxy or DNS settings. Many applications cache DNS results, maintain persistent connections, or read proxy settings only when they start. A browser tab that was opened before the connection change may continue using an old connection. Clearing every cache is not always necessary; closing the application fully and reopening it is a more controlled first step.
Check routing rules when only a few domains or applications fail. A rule may classify a destination as direct, send it to a rejected category, or match an outdated domain list. In Clash Verge, inspect the active mode, rule provider status, and selected proxy group. In sing-box, inspect route rules, DNS rules, and the selected outbound. In Shadowrocket, inspect global, configuration, and proxy modes, along with any per-domain rules. The labels differ, but the diagnostic question is the same: which outbound path receives this traffic?
If a configuration has been heavily customized, create a clean test profile from the current subscription rather than debugging every rule at once. Keep the original profile for backup, import the source into a separate test configuration, and use a simple global or broadly routed test only long enough to identify whether the base connection works. Once confirmed, restore rule-based routing gradually. This separates a damaged custom rule from a route or account failure.
- ✅ Restart the browser or application after changing proxy, DNS, or TUN settings.
- ✅ Confirm whether the destination is matched as proxy, direct, or rejected.
- ✅ Test a clean profile when a customized configuration behaves unpredictably.
- ✅ Keep a backup of working rules before editing advanced settings.
- ❌ Do not assume a connected icon means every application is routed.
- ❌ Do not combine multiple DNS overrides while diagnosing one failure.
Know When to Stop Changing Settings
Contact support when the account status is active, the current subscription has been imported into a compatible client, several routes have been tested, and the result is still consistently failing. Support can investigate account-side status, route availability, or configuration compatibility more efficiently when the report includes controlled observations instead of a long list of random changes.
Prepare the client name, operating system, approximate time of the failure, selected route, protocol if visible, and the exact error message. State whether the subscription updates successfully, whether routes appear, whether the client reaches a connected state, and whether the failure affects all applications or only one. Mention whether another network changes the result. Never include the full subscription URL, password, access token, or an unredacted configuration file.
If only one destination fails, report that separately from a complete connection failure. Include the selected exit region and whether other destinations work. If all routes fail only on one Wi-Fi network, say so clearly. If a third-party client fails but the official client works, the issue may involve protocol support, local proxy mode, or a client-specific parsing difference rather than the account itself.
A sensible fallback plan is simple: return to the current official or trusted client, refresh the subscription, test a different route, and use a compatible protocol supported by that client. If the problem is limited to one application, inspect its routing mode instead of rebuilding the whole profile. If the problem follows every route and every network, stop making local changes and provide the collected logs to support.
Confirm the network, confirm the account, refresh the subscription, verify permissions, test another route, inspect proxy scope, then change the protocol or client. One controlled change at a time produces a useful diagnosis; repeated random changes only hide the original cause.