When a VPN will not connect, the cause is often somewhere between the device and the service rather than a single broken setting. A weak or restricted network, an expired account, an overloaded or unreachable server, an incompatible protocol, or another app controlling the device’s network can all produce similar symptoms. Start with checks that are easy to reverse, and change one thing at a time so you can tell which step helped.
Before troubleshooting, note what “not working” means on your device. Does the client fail before showing a connected state, connect but leave websites unreachable, or work for some apps but not others? If possible, record the exact error message and whether the problem began after changing networks, installing an update, importing a configuration, or enabling another network tool. Those details help distinguish an account or server problem from a local routing issue.
Start with the symptoms
A client’s connected indicator means that it has established a tunnel or proxy connection; it does not guarantee that every app is using that connection or that every destination is reachable. Conversely, a browser error does not by itself prove that the VPN server is down. Identify which layer is failing before making broad changes.
- ✅ If the client cannot complete its connection, check the network, account, selected server, and protocol first.
- ✅ If the client says connected but all websites fail, inspect routing, DNS, and conflicting network tools.
- ✅ If only one app or website fails, compare it with another destination before changing the whole setup.
- ❌ Do not repeatedly reinstall the client before checking whether the current network allows a connection.
- ❌ Do not share screenshots or configuration links that may expose account or connection credentials.
Seven quick fixes to try
1. Check the underlying network
First disconnect the VPN and confirm that the device can reach the internet over its ordinary connection. Open a familiar website or app, then try a different network if one is available, such as switching between Wi-Fi and mobile data. If ordinary internet access is already unavailable, the VPN cannot establish a reliable route on top of it. Resolve the local connection problem first by reconnecting to Wi-Fi, checking the router, or following your mobile carrier’s troubleshooting steps.
Some networks restrict VPN traffic, interfere with particular ports, require a browser-based sign-in, or apply filtering that prevents a tunnel from completing. Public Wi-Fi may require you to accept terms on a captive portal before other connections work. Disconnect the VPN, complete the network’s sign-in process, and then reconnect. If the VPN works on another network but not the current one, that comparison points to network-specific filtering or routing rather than a damaged installation.
2. Verify your account and configuration
Check that you are signed in to the intended account and that the service has not reported an account, subscription, or authentication issue. If a client uses an imported subscription, refresh it from the original provider rather than relying on an old local list. A configuration can become outdated when servers or connection parameters change. If the client reports that a subscription cannot be reached, distinguish that from a node connection failure: the subscription fetch and the VPN connection are separate operations.
When a configuration was copied manually, check for accidental whitespace, a truncated address, or a missing character. Avoid pasting a private subscription URL into an unfamiliar website to “convert” or inspect it. Such a link may provide access to personal connection details. If you use a third-party client, confirm that it supports the format and protocol provided by your service; an import that succeeds does not necessarily mean every entry is compatible.
3. Try another server or location
A specific server may be temporarily unreachable from your current network, under maintenance, or experiencing a routing issue. Select another available server and test again. If the alternate server connects, the problem is more likely limited to the original route than to the device as a whole. If several servers fail in the same way, continue with the client, account, network, and device checks instead of cycling through every entry without a plan.
Choose a server appropriate for the task and keep the test simple. For example, use one nearby option to establish whether the client can connect, then select a different location only if you need to test a particular service or route. Server labels are useful identifiers, but a label alone does not explain the route, capacity, or compatibility of that entry. If all options fail, note which ones you tested and the exact errors before contacting support.
4. Switch the protocol or connection mode
VPN protocols and transport modes do not behave identically on every network. A network may handle one transport well while restricting another, and an older client core may not understand a newer configuration. If the client offers a protocol or connection-mode selection, try a different supported option, reconnect, and test the same destination. Change only this setting for the test, and restore the original choice if the alternative makes no difference.
Do not assume that a protocol name by itself guarantees compatibility. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are different technologies, and support depends on both the service configuration and the client implementation. A third-party client may accept an imported profile while lacking support for a particular protocol feature or transport combination. Use the service’s documented client and configuration guidance where available. If you are unsure which option to choose, keep the default rather than editing advanced fields such as ports, TLS, or server names at random.
5. Update and restart the client
Close the client completely, reopen it, and try again. If the issue appeared after the device resumed from sleep or changed networks, a fresh connection can clear a stale route or tunnel state. Then check for an update from the client’s official distribution source. Updates may address operating-system compatibility, connection handling, or support for newer configuration formats. On mobile devices, also check whether the operating system has an update pending that affects network permissions.
If the client was installed recently, confirm that the downloaded version is intended for your platform and processor where the publisher provides different builds. Do not install several VPN clients as a troubleshooting shortcut. Multiple network extensions or proxy tools can compete for routing control, making it harder to identify the original problem. If you do reinstall, first make sure you can retrieve your account details and configuration again, and remove only the affected client using the platform’s normal uninstall process.
6. Check DNS, system time, and permissions
If the VPN reports a successful connection but names such as website addresses do not load, DNS may be involved. First test a different website or app, then temporarily return DNS settings to the client or system default if you previously changed them. Custom DNS, encrypted DNS features, or a manually configured resolver may conflict with the VPN’s routing rules. Avoid entering an unfamiliar DNS address as a guess; restore the last known working configuration and test again.
Also verify that the device’s date, time, and time zone are set correctly, preferably using automatic time settings. Incorrect system time can interfere with certificate validation and secure handshakes. On phones and computers, the operating system may ask permission to create a VPN connection or network extension. If that permission was declined or later removed, open the system’s network or VPN settings and approve the client’s request. The exact menu names differ by operating system, so use the platform’s current settings rather than following instructions written for an unrelated version.
7. Look for conflicting apps and routing rules
Another VPN, proxy, firewall, endpoint security product, DNS changer, or traffic-filtering app may be controlling the same network path. Temporarily disable other proxy or VPN connections, then reconnect the one you are troubleshooting. On desktop systems, check whether a browser has its own proxy setting or whether a system proxy remains enabled after another tool was closed. On mobile devices, review VPN profiles and network-filtering permissions so you can identify which app currently owns the connection.
Split tunneling can create a different kind of confusion: some apps may be sent through the VPN while others use the direct connection. If only selected apps fail, review the app list and routing mode rather than assuming the entire tunnel is down. Restore a simple default routing configuration for testing, then add exceptions back individually if you need them. Avoid deleting system certificates, resetting all network settings, or disabling security protections as an early step; those changes can have side effects and usually provide less useful diagnostic information than a controlled comparison.
When the VPN connects but nothing loads
A connected state with no usable internet usually calls for a different set of checks from a connection attempt that never finishes. Start by testing more than one app or destination. If one browser fails but another app works, inspect browser proxy settings, extensions, or app-specific routing. If every app fails, disconnect and reconnect once, then check DNS and whether another network tool has installed a competing route.
Next, switch to a different server while leaving the rest of the setup unchanged. If traffic works on the alternate server, keep a note of the original entry and report the difference if the issue persists. If neither server works, temporarily return custom routing or DNS settings to their defaults. In a third-party client, inspect whether the active profile is using a global, rule-based, or direct mode; these modes can send traffic along different paths. A browser configured for a local proxy may also fail when the client is not listening on the expected local port.
Do not treat a speed test as the only diagnostic. A test site may use a different route from the app or website that is failing, and a successful result proves only that the particular test request completed. For a more useful comparison, note whether the client connects, whether domain names resolve, and whether the same destination works with the VPN disconnected. That evidence helps narrow the issue without exposing private account information.
When only one app or website fails
If the VPN works for most traffic but a particular service does not, avoid resetting the entire device immediately. Check whether the affected app is excluded from the VPN, whether it has an independent proxy setting, and whether its browser or app cache is holding an old session. Sign out and back in only if the service’s own guidance recommends it. Some services may also have account, region, or security requirements that a network change cannot resolve.
Compare the same service in another browser or on another device using the same VPN route, if practical. If it fails only in one app, the cause may be local to that app. If it fails across devices but other destinations work, the issue may be service-specific or related to the selected route. Keep the location and configuration stable during this comparison so a changing exit does not introduce another variable. A VPN can carry network traffic, but it cannot correct an account restriction, an application bug, or a service outage.
When the problem began after adding split-tunneling rules, remove the newest exception and test again. Rules may match an application differently than expected, especially when an app launches helper processes or uses a separate browser component. Add exceptions one at a time and keep a record of the original behavior. For general client setup and importing guidance, see the quick-start guide.
When to contact support
Contact the service’s support team if the problem continues across networks and supported servers, or if the client shows an account or authentication error you cannot resolve. Include your operating system, client name and version, the connection mode or protocol selected, the approximate time the issue occurred, and the exact error text. State what you tested—for example, whether ordinary internet access worked, whether another server connected, and whether the same problem occurred on another network.
Share only the information needed to diagnose the issue. Do not send passwords, one-time codes, private keys, or a full subscription URL in a public channel. If support requests logs, use the client’s built-in export or the provider’s stated secure method, and review the files for personal details before sending them. A short, ordered troubleshooting record is usually more helpful than a large collection of unrelated screenshots.
- ✅ Report the exact error and the step where the connection stops.
- ✅ Mention recent changes, such as a client update, new network, or modified routing rule.
- ✅ Say whether the issue affects all traffic, one app, or one destination.
- ❌ Do not publish account credentials or private configuration links while asking for help.