A VPN client can show an active connection while your browser, messaging app, or desktop software remains offline. This usually means that the encrypted tunnel was established, but traffic is being blocked or misrouted after the connection is created. The cause may be the local network, a stale DNS setting, a system proxy conflict, a permission problem, an incompatible protocol, or a route that is connected but not usable.
Do not switch servers repeatedly as the first reaction. A different route can occasionally help, but it can also hide the real problem and make troubleshooting harder. Use a fixed order instead: confirm whether the ordinary network works, identify whether the failure affects every application, inspect DNS and proxy settings, check permissions and routing, then test another protocol or client. This approach usually reveals whether the issue belongs to the VPN service, the device, or the current network.
Confirm the Scope Before Changing Settings
Start by disconnecting the VPN and opening a few ordinary websites or services. If the device is offline even without the VPN, the problem is probably related to Wi-Fi, mobile data, captive-portal authentication, a router restriction, or an upstream outage. Sign in to the network if a browser page asks for acceptance of terms, and confirm that the device has received a local IP address. A VPN cannot repair a basic connection that has not completed its own network login.
Next, reconnect the VPN and compare several types of traffic. Try a normal website, a domain that you regularly use, and an application that does not rely on the browser's proxy settings. If every application fails, focus on the tunnel, routing, firewall, or DNS. If only the browser fails, inspect browser proxy extensions, secure DNS settings, and cached network state. If websites work but one application does not, that application may be bypassing the VPN, rejecting the route, or using its own DNS and proxy configuration.
90+
Countries covered
200+
Available routes
Unlimited
Online devices
Record what changes between the working and failing states. Note whether the failure appears immediately after connection, whether local websites remain available, whether the issue occurs on Wi-Fi and mobile data, and whether it affects one device or several. You do not need complicated diagnostic software at this stage. A clear comparison prevents unrelated settings from being changed at the same time.
- ✅ Test the ordinary network with the VPN disconnected
- ✅ Check more than one website and at least one separate application
- ✅ Test the same client on another available network when possible
- ❌ Do not assume that a connected status means traffic is passing successfully
- ❌ Do not change the server, protocol, DNS, and proxy settings simultaneously
If the VPN works on a different network, the original Wi-Fi, router, or access provider may be interfering with the tunnel. If it fails everywhere on one device but works on another, inspect the local client and operating system. If several devices fail at the same time, check the account status, subscription update, service notice, or route availability before spending time on one device's browser settings.
Check DNS and Name Resolution
DNS translates a domain name into an IP address. A VPN may connect correctly while DNS requests continue using an unavailable local resolver, a blocked resolver, or a resolver that cannot be reached through the selected route. In that situation, the browser may display an error that looks like a complete loss of internet access even though the tunnel itself is active.
Begin with the client’s DNS option. If it offers a choice between automatic DNS, VPN-provided DNS, and a custom DNS server, return to the recommended or automatic setting first. A manually entered DNS address copied from an old setup can become unreachable when the route, network, or protocol changes. Avoid adding several custom resolvers at once because inconsistent responses make the result difficult to interpret.
Clear the local DNS cache after changing the setting. On Windows, open an elevated Command Prompt and run:
ipconfig /flushdnsOn macOS, restarting the client and the device is often the least error-prone way to clear stale resolver state. On Android and iOS, disconnecting the VPN, switching the network connection off and on, and reconnecting can refresh the relevant state. Linux distributions use different resolver services, so check whether the system uses systemd-resolved, NetworkManager, or another local resolver before applying a distribution-specific command.
Browser-level secure DNS can also create a split path. A browser may send DNS requests through its own encrypted resolver while other applications use the operating system. Temporarily return the browser’s secure DNS setting to its default behavior and test again. Browser extensions that provide proxying, filtering, or privacy routing should also be disabled temporarily, especially if the system VPN client already manages traffic.
When diagnosing DNS, distinguish between a name-resolution error and a routing error. An error such as “server DNS address could not be found” points toward a resolver or cache problem. A timeout after the domain resolves can indicate firewall filtering, route failure, MTU trouble, or a protocol issue. The exact wording varies by platform, but the distinction helps you choose the next test.
Remove Proxy and Routing Conflicts
A VPN client may use a system-wide tunnel, a local HTTP or SOCKS proxy, or a combination of both. Problems occur when another application has already configured a proxy, the operating system retains a proxy after the client disconnects, or the browser points to a local port that is no longer listening. The client can report success because its tunnel is established while applications are still sending traffic to a dead local proxy.
Inspect the operating system proxy panel and the browser’s proxy settings. If you do not intentionally use a separate proxy, select the client’s recommended automatic option or disable the unrelated manual proxy. Check developer tools, download managers, antivirus web filters, and traffic-capture applications as well. These tools may install their own certificates or local listeners and can interfere with encrypted connections.
On Windows, review both the system proxy and any WinHTTP proxy configuration used by background services. On macOS, inspect the active network service rather than only the Wi-Fi profile; Ethernet, a phone hotspot, and a virtual adapter may have separate settings. On Linux, check environment variables such as HTTP proxy and HTTPS proxy, desktop network settings, and application-specific configuration files. Mobile applications may ignore the system proxy entirely, so compare them with a browser instead of assuming that one result applies to all apps.
Split tunneling is another common source of confusion. With split tunneling enabled, selected applications or domains bypass the VPN by design. That can be useful for local services, printers, or software that must use a domestic connection, but an overly broad bypass list can make the internet appear unavailable in the applications you expect to use through the tunnel. Temporarily disable split tunneling and test with a simple all-traffic profile. If connectivity returns, rebuild the bypass rules one entry at a time.
| Observed behavior | Likely area | First action | What the result means |
|---|---|---|---|
| Every application is offline after connection | Route, firewall, tunnel mode, or DNS | Disable split tunneling and inspect system proxy settings | If traffic returns, a local routing or proxy rule was conflicting |
| Only the browser is offline | Browser proxy, extension, or secure DNS | Use a clean browser window and restore default network settings | If the clean window works, the browser configuration needs review |
| Local services work but external services fail | VPN route, DNS path, or access-network filtering | Test another route or protocol without changing other settings | A route or protocol difference becomes the main suspect |
| The client connects and immediately disconnects | Permissions, firewall, protocol, or unstable network | Restart the client with appropriate permissions and check security software | A persistent failure points to the device or network environment |
Review Permissions, Firewalls, and Network Adapters
A VPN needs permission to create or control a virtual network interface. Operating-system updates, security software, device-management policies, and competing network utilities can prevent that interface from forwarding traffic correctly. The user interface may still display a connection because authentication succeeded, but the data path may not have been installed completely.
Close the client, restart the device, and launch the official client again. On desktop systems, allow the client to request the permissions required to create a VPN profile or virtual adapter. Do not permanently disable the firewall as a shortcut. Instead, review whether the firewall or endpoint security product has blocked the client, its background service, or the virtual adapter. If a security product has a network inspection feature, pause only that feature for a controlled test and restore it immediately afterward.
Look for stale adapters created by older VPN clients, virtual machines, container tools, or traffic-management software. Multiple virtual interfaces can alter route priority. Remove or disable only adapters that you recognize and no longer use, and make a backup of important network settings before making structural changes. If you are unsure which adapter is active, reconnect the client and observe which interface changes state rather than deleting entries at random.
Desktop clients commonly support several protocol families, including Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard, although the exact choices depend on the service and client. These are not interchangeable labels for the same connection. A protocol may connect successfully on one network but fail to carry traffic on another because of filtering, transport behavior, or compatibility with the local client. Test a supported alternative only after checking the simpler causes above.
Third-party clients such as Clash Verge, sing-box, and Shadowrocket also require correct mode selection and permissions. A subscription may import successfully while the client remains in a mode that does not capture the traffic you are testing. Verify whether the client is using system proxy mode, a TUN interface, or an application-level mode. The subscription format and protocol support must match the client; an imported configuration is not proof that every route or mode is compatible.
Test Routes, Protocols, and MTU Carefully
Once local settings look correct, test another route in the same general region and then, if supported, another protocol. Change one variable at a time and keep a short record of the result. If one route works immediately while another connects without carrying traffic, the issue is probably route-specific rather than a general device failure. If all routes fail on one access network but work elsewhere, the network may be restricting a transport or blocking the client’s tunnel behavior.
Do not judge a route only by its name or geographic label. A route can be technically available but unsuitable for the current network path. Congestion, transit differences, packet loss, and policy restrictions can all affect whether a connection remains usable. If the client provides route categories such as BGP, CN2, or IEPL, treat them as network-path descriptions rather than guarantees of performance in every location. The practical test is whether the route stays connected and passes the traffic your application needs.
MTU problems can appear as partial connectivity. Small requests may work while larger pages, file transfers, or applications using long-lived connections stall. This happens when packets are too large for a segment of the path and fragmentation or packet-size discovery does not work correctly. If the client exposes an MTU option, use its recommended value or a conservative value supplied by the client documentation. Avoid copying a value from an unrelated device or network, because the suitable setting depends on the tunnel and transport.
After changing a route or protocol, fully disconnect before reconnecting. Some clients retain the previous virtual adapter, DNS state, or proxy mode when a profile is switched while connected. A clean reconnect gives the operating system an opportunity to remove the old route and install the new one. If the problem continues, restart the client service or device rather than repeatedly clicking connect.
- ✅ Change only one route or protocol between tests
- ✅ Use the client’s recommended protocol for the current platform first
- ✅ Test a clean reconnect after every meaningful profile change
- ✅ Compare results across Wi-Fi and mobile data when available
- ❌ Do not treat a country label as proof that every route in that region is equivalent
- ❌ Do not copy MTU values or configuration fragments from an unrelated client
Know When to Reinstall or Contact Support
If the issue affects only one device after the network, DNS, proxy, and route checks, reinstalling the official client may be reasonable. Before removing it, record any custom rules, back up configurations that do not contain exposed credentials, and make sure you can retrieve the subscription or account configuration again. A clean installation can repair a damaged virtual adapter or an incomplete permission registration, but it should not be the first step when the underlying network is offline.
On mobile platforms, check whether the VPN profile is still present and whether the operating system has restricted background activity, battery use, or network access for the client. On iOS and Android, deleting and recreating the VPN profile may clear a stale permission state. On Windows, macOS, and Linux, confirm that another VPN, proxy manager, or virtual network tool is not starting automatically with the system.
Contact support with useful diagnostic context rather than only saying that the VPN does not work. Include the operating system, client name, whether the ordinary network works without the VPN, whether all applications are affected, the tested route and protocol, and whether the issue changes on another network. Never send a private subscription link, password, token, or full configuration file in a public support channel. Screenshots should hide account identifiers and connection credentials.
For a quick final review, return the device to a simple baseline: one VPN client, automatic DNS, no unrelated manual proxy, split tunneling disabled, a supported route, and the client’s recommended protocol. If that baseline works, restore custom settings gradually. The setting that reintroduces the failure is more valuable than another random server change because it identifies the source of the conflict.
If you are new to importing configurations or switching between official and compatible clients, the view the tutorial page can help you establish a clean starting setup. Once the connection works, keep only the settings you need, update subscriptions through trusted channels, and recheck the baseline whenever a network or operating-system change causes the same symptom to return.