A VPN can show “Connected” while websites, apps, or all internet traffic still fail. The status usually confirms that the client established a tunnel; it does not prove that your device has working DNS, that the relevant app is routed through the tunnel, or that the network outside the VPN is available. Work through the checks below in order, changing one thing at a time. That makes it easier to identify the cause and undo any temporary adjustment.
Identify what is not working
First, note whether the problem affects everything or only one app. Try opening a familiar website in a second browser, then test an app that does not depend on the browser. If only one website or app fails, the issue may be specific to that service, its account, or the app’s own proxy settings. If nothing loads on any device while the VPN is active, focus on the tunnel, DNS, routing, and your underlying connection.
Next, disconnect the VPN and retry the same test. If the internet still fails, the VPN may not be the cause: check Wi-Fi or mobile data, captive-portal sign-in, router status, and any outage affecting your internet provider. If ordinary access returns as soon as you disconnect, concentrate on the VPN client and its route or DNS settings. Do not treat a VPN icon or a successful connection message as a complete connectivity test.
Also distinguish a full-device VPN from an app-specific proxy. Some proxy clients route only selected apps or destinations according to rules. In that mode, an app that is set to bypass the proxy may use the local connection, while another app uses the tunnel. A connection can therefore appear healthy even when the particular app you are testing is not using the route you expect.
Fix 1: Check the underlying network and app conflicts
Before changing VPN settings, confirm that the device itself can reach the internet. Turn the VPN off, load a few different sites, and, if possible, compare Wi-Fi with mobile data or another trusted network. On public Wi-Fi, open a browser and look for a sign-in page or terms-of-use prompt. A network may allow the VPN client to start but block normal browsing until you complete its login process.
If the connection fails only on one Wi-Fi network, restart the router if you control it, or ask the network administrator whether VPN traffic is restricted. A workplace, school, hotel, or public hotspot may have its own firewall and access rules. Do not try to bypass controls on a managed network; use an approved connection or contact its administrator. If the VPN works on a different network, that comparison is useful evidence that the original network is the limiting factor.
Check whether another app is already using the device’s VPN interface. Ad blockers, security suites, firewall tools, private DNS apps, and other VPN clients can create local tunnels or install filtering rules. Most mobile operating systems generally allow only one active VPN connection at a time, and desktop routing can also be affected by overlapping network tools. Close or pause only tools you recognize and are allowed to change. If the device is managed by an employer or school, leave organization-installed profiles in place and ask the administrator for help.
- ✅ Test the internet with the VPN disconnected before changing client settings.
- ✅ Check for a Wi-Fi sign-in page, weak signal, or a network restriction.
- ✅ Close a second proxy or VPN client only if you know what it does.
- ❌ Do not delete a work, school, or security profile just to test a connection.
If the underlying connection is unavailable, repair that first. Reinstalling a VPN client or repeatedly switching servers will not restore a disconnected router, mobile-data session, or captive-portal login.
Fix 2: Check the kill switch and traffic routing
A kill switch is designed to block traffic when a VPN tunnel drops or is not considered secure. That behavior can look like “VPN connected but no internet” if the client has a stale connection state, if the tunnel did not finish starting, or if the kill switch remains active after disconnecting. Open the VPN client and inspect its kill-switch, lockdown, or “block connections without VPN” setting. The wording depends on the client and operating system.
For a safe test, first note the setting’s current state. If the VPN is connected but no traffic passes, disconnect it using the client’s own control and see whether ordinary internet access returns. If it does not, check the client’s status and system VPN settings before changing the kill switch. You may temporarily disable a client-level kill switch to diagnose the issue, but do so only on a network you trust and restore your preferred protection after testing. On Android, an always-on VPN or system option to block connections without VPN can continue blocking traffic even after the app appears closed.
In a rule-based client such as Clash Verge or sing-box, inspect the selected mode and routing rules. “Rule” mode may send some domains or applications directly while routing others through a proxy; “Global” mode, where available, generally sends a broader set of traffic through the proxy. These labels and behaviors vary by client and configuration. A rule that sends DNS requests one way and the associated connection another way can also cause failures. If you recently edited rules, switch back to a known working configuration or refresh the provider configuration through the client’s supported update function.
On phones, check whether the affected app is excluded from VPN use or limited by a per-app routing list. On computers, look for split tunneling, proxy exceptions, or multiple active network adapters. Do not remove individual routes or paste configuration snippets from an untrusted source. If changing one mode restores access, record the original value and review the rule that caused the difference before making that change permanent.
When you need to compare the client’s behavior with a standard service setup, VPNLearn Reliable VPN for China provides a starting point for checking supported platforms and connection options; the exact troubleshooting controls still depend on the client and device you use.
Fix 3: Run a controlled DNS and server check
DNS translates a site name into the address a device needs to connect. A VPN tunnel may be established while DNS requests are blocked, sent to an unreachable resolver, or handled by an incompatible setting on the device. This often presents as a browser that spins or reports that a site cannot be found. If an app connects by a saved session but new sites fail to open, DNS is one possible explanation, not proof of the cause.
- Disconnect the VPN and confirm that ordinary browsing works.
- Reconnect using the VPN client’s normal connection control, then test more than one unrelated website and another app.
- If the client offers a DNS option, note its current value and restore the client’s default or service-provided setting if it was manually changed.
- On Android, check whether Private DNS is set to a custom provider; on other systems, check for custom DNS, encrypted DNS, or browser-specific secure DNS settings.
- Change only one DNS setting for a brief comparison, then test again and record whether the result changes.
- Restore the previous setting if the test makes no difference, or if access becomes less reliable.
Do not assume that a public resolver is automatically better or that changing DNS will fix every connection problem. Some networks and services require a particular resolver, and a browser’s secure-DNS setting can behave differently from the operating system’s DNS setting. Avoid entering random DNS addresses from forum posts. If the VPN client manages DNS automatically, use its documented options rather than overriding the operating system without a clear reason.
If DNS settings seem correct, test a different server or location using the client’s normal server list. A particular endpoint may be temporarily busy, unavailable from your current network, or unsuitable for the service you are trying to reach. Select one alternative, wait for the client to show a completed connection, and repeat the same tests. Avoid cycling rapidly through many servers: doing so makes results hard to interpret and may trigger additional service or account checks.
Where the client supports multiple protocols, a temporary protocol comparison can help identify a network-compatibility problem. Protocol names such as Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard refer to different connection technologies, not interchangeable speed grades. Availability and behavior depend on the service, client core, configuration, and network. Use only options actually supplied by your service or client, and return to the recommended setting if the alternative does not help.
Fix 4: Review device settings and restore changes
If one device has no internet through the VPN while another works on the same network and service, compare their client versions, active profiles, and routing options. An outdated client, an incomplete subscription update, or a profile that no longer matches the client’s supported format can cause a tunnel to connect without forwarding traffic as expected. Update the client only from a trusted source, then refresh the configuration using its documented subscription-update process. Do not share a subscription link publicly: it may grant access to your account’s connection configuration.
Check whether the device recently changed networks or resumed from sleep. A laptop may keep an old route after moving from Wi-Fi to Ethernet, and a phone may retain a VPN session after switching between Wi-Fi and mobile data. Disconnect from the VPN, briefly disable and re-enable the active network connection using the operating system’s controls, then reconnect through the client. If the issue began after changing a proxy, firewall, DNS, or network profile, use the system’s normal settings screen to review that change rather than applying a broad reset immediately.
As a last local diagnostic step, restart the device and reconnect with only one VPN client active. Before resetting network settings, save any information you may need to reconnect, such as a Wi-Fi password or administrator-provided profile. A network reset can remove saved networks, custom DNS values, VPN profiles, or other settings, and the exact effects vary by operating system. Prefer a targeted reset or the device maker’s documented recovery process, especially on managed devices.
Keep a short record of each change: the original value, what you changed, and whether the test improved access. Reverse unsuccessful changes before trying another fix. This is particularly important when you temporarily disable a kill switch, edit a DNS option, or change a proxy mode. If reverting the change restores the original behavior, leave the setting as it was and investigate another cause instead of stacking more adjustments.
Confirm the fix and know when to ask for help
After access returns, confirm that the result is repeatable. Test a few different sites and at least one non-browser app, then disconnect and reconnect the VPN once through its normal controls. If you changed a setting for diagnosis, decide whether to keep it only when you understand its purpose and it is compatible with the client’s instructions. Re-enable security protections you temporarily paused, and verify that ordinary internet access still works when the VPN is disconnected.
If the problem persists, collect useful details before contacting the VPN provider or device administrator: the operating system and client name, whether the problem occurs on Wi-Fi, mobile data, or both, whether the internet works without the VPN, the selected protocol or routing mode if visible, and the settings you changed and restored. Include the exact error message and approximate time of the failure. Do not send passwords, authentication codes, or a private subscription URL in a public forum or ordinary support message.