A VPN that will not connect is not always caused by the VPN service itself. The failure may come from the local network, a blocked permission, an unavailable server, an unsuitable protocol, a stale DNS result, or a conflict with another proxy tool. The fastest way to troubleshoot is to change one variable at a time and test the connection after each change. Disconnect first, record what the client shows, and then work through the fixes in order rather than repeatedly clicking Connect.
This guide applies to official Windows, macOS, Android, iOS, and Linux clients, as well as compatible clients such as Clash Verge, sing-box, and Shadowrocket. The exact menu names differ between applications, but the reasoning is the same: confirm that the device has a usable network, make sure the client can create its tunnel, test another route or protocol, and verify the result outside the client window.
1. Identify exactly where the connection fails
Before changing settings, separate the failure into a stage. A client may fail while downloading a subscription, fail during authentication, fail during the handshake, establish a tunnel but lose traffic, or work at the system level while one application bypasses it. These are different problems and require different fixes.
First, turn the VPN off and open several ordinary websites. If nothing loads, switch between Wi-Fi and mobile data, restart the router if you control it, or sign in again to a captive portal on hotel, campus, airport, or public Wi-Fi. A VPN cannot complete a handshake through a network that has not yet granted normal internet access. Some networks also require browser confirmation before encrypted connections are allowed.
Next, check the client status and error message. “Invalid subscription,” “authentication failed,” “timeout,” “TLS error,” “permission denied,” and “connected without internet” point to different layers. Take a screenshot or copy the message before resetting the application. If a subscription link was imported into Clash Verge, sing-box, or another client, test whether the subscription can still be updated. An expired, malformed, or incomplete profile can look like a server failure even when the account is valid.
- ✅ Test ordinary internet access with the VPN disconnected
- ✅ Check whether the subscription or profile can be refreshed
- ✅ Note whether the error appears before or after authentication
- ❌ Do not judge the tunnel only by the client icon
On a desktop, also check whether another VPN, system proxy, antivirus web filter, virtual network adapter, or traffic-capture utility is running. On a phone, look for an existing VPN profile under network settings. Two applications trying to control the same system proxy or VPN interface can produce an apparently random result: one window says connected while traffic is sent through another configuration.
2. Check the network, permissions, and device clock
A local permission problem is one of the most common reasons a VPN stops working after an operating-system update, a security-policy change, or a fresh installation. The client may need permission to add a system VPN profile, create a virtual network interface, modify the system proxy, or run in the background. If that permission was denied, the application may open normally but never complete the tunnel.
On Windows and macOS, close the client and reopen it with the permissions required by its installation method. Review the operating system’s VPN, network-extension, firewall, and privacy prompts. A desktop client that uses a TUN mode may need permission to create or operate a virtual interface. If system-proxy mode is used instead, confirm that the proxy address and port are actually enabled after connection. Do not enable every mode at once; test TUN and system proxy separately.
On Android and iOS, remove an old VPN profile only if you are certain it belongs to the client being repaired, then approve the new VPN request when prompted. Battery optimization can stop a mobile client in the background, especially when the screen is locked. Allow background activity when continuous connectivity is important, but understand that this can increase battery use. If the client was installed through a subscription import, confirm that the imported profile has not been disabled by a mobile security setting.
The device clock also matters. A clock that is substantially wrong can cause certificate validation, authentication, and encrypted handshakes to fail. Enable automatic date and time, confirm the time zone, and retry after the clock synchronizes. This is particularly useful when the error mentions certificates, secure transport, or an expired connection.
Firewall and endpoint-security software should be tested carefully. Instead of permanently disabling protection, add the VPN client or its network component to the approved list according to the security product’s documentation. Corporate, campus, and managed devices may prevent the installation of VPN profiles entirely. In that situation, repeated protocol changes will not solve the underlying policy restriction.
3. Switch the server, region, and protocol method
If the device has normal internet access and permissions are correct, test another server or region. A single server may be temporarily overloaded, restarting, undergoing maintenance, or affected by a route change between your network and the service. Repeatedly retrying the same endpoint does not provide useful information; moving to a different endpoint does.
Choose the replacement according to the target service rather than automatically choosing the geographically closest location. A nearby location can be a good starting point for general browsing, but a service that checks regional availability may require a particular exit region. For banking, work systems, and university platforms, frequent changes in exit location can trigger additional login checks. For video or region-sensitive services, the exit location may matter more than the nominal bandwidth.
Protocol selection is another controlled test. Shadowsocks is a proxy protocol often used by compatible clients and can work well when the client is configured correctly. VMess and Trojan are commonly used through clients that support their respective transport and security parameters. Hysteria2 uses a QUIC-based transport and may behave differently on networks that treat UDP traffic unusually. WireGuard is a VPN protocol with a lightweight design, but it still depends on correct keys, endpoint details, allowed routes, and network support. A protocol name alone does not guarantee that every network will handle it equally well.
Change only one of these variables at a time: server, protocol, transport option, or routing mode. If a new server works with the original protocol, the first endpoint was likely the immediate problem. If several servers fail under one protocol but work under another, the network may be filtering or mishandling that transport. If every protocol fails only on one Wi-Fi network, investigate the network rather than deleting all profiles.
| Test result | Most likely area | Next action | What to verify |
|---|---|---|---|
| One server fails, another works | Endpoint availability or route condition | Keep the working server and retry the original later | Exit IP and target application |
| All servers fail on one Wi-Fi network | Local network policy or transport handling | Test mobile data or another protocol | Whether the same profile works elsewhere |
| Client connects but pages do not load | Routing, DNS, proxy, or TUN configuration | Test system proxy and routing mode separately | IP, DNS, and application path |
| Only one application fails | Application proxy rules, cache, or account policy | Compare with a browser and review app-specific settings | Whether the app bypasses the tunnel |
Some providers offer different route types, such as BGP, CN2, or IEPL-related paths. These labels describe network routing characteristics, not a universal promise that one option will work on every connection. Test the route with the actual application and time of day that matter to you. A route that connects successfully but cannot carry the required traffic is not a complete fix.
4. Repair routing, DNS, and proxy conflicts
A VPN can display Connected while traffic still follows the wrong path. This happens when the system proxy was not applied, a TUN interface failed to start, split-tunnel rules match incorrectly, or the application has its own proxy setting. DNS can also remain on the local resolver, producing results that do not match the expected exit region or causing a domain to resolve to an unreachable address.
Start by choosing one operating mode. In a compatible client, system-proxy mode usually affects applications that respect the operating system’s proxy settings. TUN mode works at a lower network level and can capture traffic from applications that do not use a browser-style proxy, but it requires the correct virtual interface permissions and routing rules. If both modes are enabled with conflicting settings, disable one and test again.
Review rule mode, global mode, and direct mode carefully. Global mode is useful as a diagnostic because it reduces the number of routing decisions, but it may send local services, banking applications, printers, or intranet traffic through the tunnel. Rule mode is more practical for everyday use, provided the rules are current and the target domain is matched correctly. Direct mode can make a working VPN appear broken because it intentionally bypasses the proxy.
For DNS troubleshooting, compare the result with the VPN disconnected and connected. Check whether the resolver changes as expected, whether domains resolve consistently, and whether only one domain fails. Clear the operating-system DNS cache when appropriate, restart the browser or application, and avoid changing several DNS tools at once. A public DNS resolver may improve name resolution, but it cannot repair an unavailable route or an application that ignores the system network settings.
Browser extensions and application-level proxies deserve separate attention. A browser extension may override the system proxy, while a developer tool, download manager, terminal, or game launcher may use its own connection method. Test the same destination in a clean browser window and then check the application’s proxy option. If the browser works but the application does not, the tunnel may be healthy and the application configuration is the actual fault.
- ✅ Test one mode at a time: system proxy, TUN, or application proxy
- ✅ Use global mode briefly as a diagnostic, then return to suitable rules
- ✅ Restart the affected application after changing routing or DNS
- ❌ Do not assume Connected proves that every application uses the tunnel
5. Refresh the profile and rebuild stale client state
Configuration files can become stale even when the account itself is active. A subscription may have been imported months ago, a node may have been removed, or an update may have changed a client’s accepted field names. Refresh the subscription from the original link, wait for the update to complete, and inspect whether usable servers are listed. If the update fails, test the link in the provider’s supported official client or account panel rather than repeatedly importing the same broken copy.
Before deleting anything, save the settings that you can safely restore: selected server, routing preference, custom rules, and local exceptions. Do not publish a subscription link or access token in a screenshot or support message. A redacted error message is usually enough for initial diagnosis.
Then restart the client completely. On desktop systems, quit it from the tray or menu bar instead of merely closing the window. On mobile systems, force-close only when normal disconnect and reconnect do not work. Rebooting the device can clear a stuck network extension, but it should follow simpler checks rather than replace them.
If the client still behaves inconsistently, remove and reinstall it from a trusted official source, or create a new profile while keeping the old one for comparison. For Clash Verge, sing-box, Shadowrocket, and similar tools, verify that the imported configuration matches the client’s supported format. A profile intended for one core or transport implementation may not function correctly in another. Do not mix WireGuard configuration fields with a proxy profile, and do not assume that a VMess, Trojan, Shadowsocks, or Hysteria2 entry can be pasted into an unrelated client without conversion.
Linux users should additionally inspect whether a desktop environment proxy and a command-line environment proxy are different. A browser launched from the desktop may follow one setting while command-line tools use environment variables such as HTTP or HTTPS proxy values. Check the active network interface, routing table, and service logs only if you are comfortable interpreting them. Otherwise, a clean official client can help determine whether the issue is with the operating-system configuration or the subscription itself.
6. Verify the fix, then contact support with useful evidence
After a connection succeeds, do not stop at the client status. Open an IP-checking service and confirm that the exit address and approximate region match the selected route. Check DNS behavior if location consistency matters. Test the actual target application, not just a generic webpage, because different applications may use different protocols, cached sessions, or their own proxy settings.
Repeat the test after disconnecting and reconnecting. Confirm that the system returns to the expected direct route when the VPN is off, and that the selected rules are restored when it is on. If a long-running application is important, start a new session after the tunnel is established. Existing connections may retain old DNS results or an old route and can continue failing until they are rebuilt.
90+
Countries covered
200+
线路 available
5
Supported platforms
Unlimited
Online devices
When multiple servers and protocols fail after the local checks are complete, contact support with information that allows the problem to be reproduced. Include the operating system, client name and version, whether the failure occurs on Wi-Fi or mobile data, the approximate time, the selected protocol, the selected region, and the exact error text. State whether ordinary internet access works without the VPN and whether another application can use the connection.
Remove passwords, subscription URLs, access tokens, private keys, and personal account information before sending logs. If support requests a log, provide only the relevant time range when possible. Mention the tests that already worked, such as “another server connects but the target app fails” or “the same profile works on mobile data.” This is far more useful than reporting only that the VPN is broken.
A practical troubleshooting routine does not require deleting every setting or selecting the fastest-looking server at random. It requires a clean baseline, controlled comparisons, and verification at the destination. Once the working server, protocol, and routing mode are identified, record those choices so the next interruption can be resolved quickly instead of starting from zero.