A VPN client can show “Connected” while your browser or other apps remain offline. That status usually confirms that a tunnel or proxy session was established; it does not prove that your device has working internet access, that the app is routing traffic the way you expect, or that DNS requests can reach a resolver. The cause may be as simple as a temporarily unavailable Wi-Fi connection, or it may involve a kill switch, a second proxy, a routing rule, or a server that is not responding properly.
Use the checks below in order, changing one setting at a time. First establish whether the problem affects every app or only one, and whether the internet works when the VPN is disconnected. Then move through the device network, client settings, DNS and proxy configuration, and server choice. This approach makes it easier to identify what actually fixed the problem instead of leaving several unknown settings behind.
Identify what is offline before changing settings
Start with a quick comparison. Open more than one app or website, preferably including a site or service you normally use. If only one app is offline, the VPN connection may be working while that app is using a different route, relying on a proxy it cannot reach, or being blocked by its own network settings. If every app is offline, focus first on the device’s internet connection, VPN routing, DNS, and any kill switch.
Next, disconnect the VPN and test the same apps on the same network. If they still cannot connect, the problem is probably not caused solely by the VPN. Check whether Wi-Fi or mobile data is active, whether other devices on the network can browse, and whether a captive portal requires you to sign in. On hotel, campus, airport, and public Wi-Fi, complete the network’s sign-in page before connecting to a VPN. If the portal page does not appear, disconnect the VPN temporarily and open a regular website to trigger it.
If the internet works without the VPN but stops as soon as you connect, note the client mode and the timing. For example, does access fail immediately, only after the client changes to a different mode, or only in one application? Avoid restarting the router or resetting every network setting at the beginning. Those actions can erase useful clues, affect other people using the network, and make it harder to isolate a client-side issue.
- ✅ Test multiple apps to distinguish an app-specific issue from a device-wide outage.
- ✅ Compare the same network with the VPN disconnected and connected.
- ✅ Complete any Wi-Fi sign-in page before troubleshooting the tunnel.
- ❌ Do not change DNS, proxy, and routing settings all at once; test one change at a time.
Try these seven fixes in a controlled order
The following checks cover the most common causes without assuming that every client uses the same labels. Menus vary by operating system and app version, so look for the setting that performs the described function rather than relying on an exact menu name. After each change, reconnect and test the same app or website. If access returns, stop there and keep a note of the setting that made the difference.
Fix 1: Confirm the device has internet access
Disconnect the VPN and load a familiar website. If it does not load, reconnect to Wi-Fi or mobile data, check airplane mode, and try another available network if practical. On public Wi-Fi, finish its sign-in or acceptance page first. If the device still cannot browse without the VPN, contact the network administrator or internet provider before adjusting VPN settings.
Fix 2: Rebuild the VPN session
Disconnect from the server, wait for the client to show that it is disconnected, and connect again. If the problem persists, fully quit and reopen the VPN app; simply closing its window may leave a background process running. On a phone, switch between Wi-Fi and mobile data only if you can do so without interrupting an important task. A fresh session can clear a stale route or a failed connection negotiation, but it will not repair an underlying network outage.
Fix 3: Check the kill switch and blocking options
A kill switch is designed to block some or all traffic when the VPN tunnel is unavailable. Depending on the client, it may remain active after a disconnect, after a server change, or when the app is closed. Look for settings such as “Kill Switch,” “Block connections without VPN,” or “Always-on VPN.” If the client reports connected but no traffic passes, verify that the selected server is actually active and that the kill switch is not blocking traffic because it believes the tunnel has failed.
For diagnosis, you can temporarily turn off the relevant blocking option, reconnect, and test again. Treat this as a test rather than a default recommendation: disabling a kill switch may allow traffic to use your ordinary network if the VPN drops. If you need the blocking protection, restore the setting after testing and resolve the connection issue before relying on the VPN again.
Fix 4: Try another server or connection option
Disconnect cleanly and select a different server location. A particular server may be temporarily unavailable, congested, or incompatible with the network you are currently using. If your client offers more than one supported protocol or connection mode, try another option one at a time. Do not assume that a server name, protocol label, or “fast” badge guarantees that it will work on every network. The purpose of this check is to determine whether the issue is limited to one route or affects all VPN connections.
Fix 5: Look for a second proxy or conflicting VPN
Only one app should generally manage the device’s active VPN route at a time. Quit other VPN clients, proxy tools, or network-filtering apps before testing again. On a desktop, review the system proxy settings and the VPN client’s own proxy mode. A system proxy may cover only applications that respect that setting, while a TUN or virtual-adapter mode can route traffic at a different layer. If a browser has a separately configured proxy, it may not follow the system settings.
Change the client to a simple supported mode for a test, then check the browser and another app. If the browser works but a desktop app does not, that app may ignore the system proxy or require its own network configuration. If you use a third-party client such as Clash Verge, sing-box, or Shadowrocket, confirm that its active profile and routing rules match the connection you intend to use. Avoid importing or enabling multiple profiles at once while diagnosing the issue.
Fix 6: Check DNS and routing rules
DNS translates a domain name into an address. If a page fails by name but a known network service still appears reachable, DNS may be part of the problem; however, one failed website is not enough to prove that diagnosis. First check whether the client has a DNS setting, a DNS protection option, or rules that send DNS requests through a particular route. Restore the client’s default or recommended DNS configuration if you changed it previously.
Split tunneling and rule-based routing can also send different destinations along different paths. A domain may be excluded from the VPN, assigned to a route that is unavailable, or matched by a rule you forgot you added. Temporarily use the client’s default routing mode, if available, and test again. On a managed work or school device, do not override administrator-provided DNS or routing settings without permission. Avoid entering unfamiliar DNS addresses from random online instructions; an untrusted resolver can affect privacy as well as connectivity.
Fix 7: Refresh the device network state
Restart the VPN app and then the device if a normal disconnect and reconnect did not help. On Windows or macOS, check that the VPN adapter or network extension is enabled and that the system has not shown a permission request requiring approval. On Android, review the VPN entry in system settings and check whether “Always-on VPN” or a block-without-VPN option is enabled. On iOS, review the VPN status and any installed configuration or filtering profile; remove a profile only if you understand what it controls. On Linux, check the client’s connection status and system logs rather than repeatedly changing firewall rules.
Use operating-system network reset tools only after simpler checks, because they may remove saved Wi-Fi networks, VPN profiles, or other network configuration. If you do reset a setting, record what changed and make sure you can restore any required work or school configuration.
Apply the checks to your platform
The same symptom can have different causes on a desktop and a phone. A desktop may have both a system proxy and a virtual network adapter; a phone may enforce an always-on VPN or keep an old VPN profile. Use the relevant platform checks below, but keep the troubleshooting sequence consistent: test without the VPN, confirm the active connection mode, and then change one setting at a time.
| Platform | What to inspect | Useful test |
|---|---|---|
| Windows | System proxy, VPN adapter status, client permissions, and any second VPN or proxy app | Disconnect the VPN, verify ordinary browsing, then reconnect using one client and one mode |
| macOS | VPN or network-extension approval, proxy settings, and other network-filtering software | Check whether the extension is allowed in system settings, then restart the client and retest |
| Android | Always-on VPN, block-without-VPN, battery restrictions, and another active VPN | Review the system VPN entry and confirm the client remains connected while testing an app |
| iOS | VPN status, configuration profiles, content filters, and any other VPN app | Disconnect and reconnect from the client, then check whether the same issue affects cellular data and Wi-Fi |
| Linux | Client status, DNS configuration, routing rules, and firewall or network-manager changes | Review client logs and test with the default route before editing firewall or resolver files |
On Windows, a browser may follow the system proxy while another program bypasses it. If the problem began after enabling TUN mode or a virtual adapter, test the client’s normal rules or proxy mode before changing Windows network settings. On macOS, a VPN client may depend on a system network extension; if macOS asks for approval, follow the client’s official instructions and verify that the extension is enabled. Do not install multiple network extensions just to see whether one happens to work.
On Android, battery-management settings can affect an app that is expected to maintain a background connection, although they are not the first thing to change if no app can browse at all. Check the system’s VPN controls and make sure you have not enabled a block that is preventing traffic during a failed tunnel. On iOS, comparing Wi-Fi and cellular data can help separate a local router issue from a client or profile issue. On Linux, the exact commands and files depend on the distribution and networking stack. Avoid copying commands that flush firewall rules or overwrite DNS configuration unless you know how to restore the previous state.
Use test results to narrow down the cause
After each change, record whether the result improved, stayed the same, or changed only for one app. This short record can prevent you from repeating the same experiment and is useful if you need support. You do not need specialist network tools to make progress: compare the same destination with the VPN disconnected and connected, note the selected server and mode, and check whether the issue affects one network or several.
- If all apps fail both with and without the VPN, investigate the local network, sign-in page, device connection, or internet service first.
- If browsing works without the VPN but all apps fail with it, focus on the VPN session, kill switch, active route, DNS configuration, and server choice.
- If one browser works but another app does not, check the app’s proxy behavior, split-tunneling rules, and whether the client mode covers that app’s traffic.
- If the problem occurs only on one Wi-Fi network, compare it with a trusted alternative network when available; a network policy or captive portal may be involved.
- If changing servers fixes the issue, note the original server and report the difference rather than changing several client settings unnecessarily.
Do not treat a successful page load as proof that every app uses the same route. A browser, a game, a messaging app, and a background updater may follow different proxy or routing rules. Likewise, a client’s connected indicator is useful but should be checked alongside actual traffic. If your client provides connection logs, review the entries around the time the problem began. Look for clear signs such as a failed DNS lookup, a rejected route, or a connection that repeatedly drops; avoid posting logs publicly if they contain account details, addresses, or other private information.
Know when to stop and ask for help
If you have confirmed that ordinary internet access works, tested a fresh VPN session, checked the kill switch, tried another server or supported connection option, and reviewed conflicting proxies and routing rules, gather the details before contacting support. Include the operating system and version, VPN client and version, the network type, the server or route selected, and whether the problem affects every app or only certain ones. Describe the steps you already tried and the result of each; “connected but no internet” is a helpful starting description, but the comparison between connected and disconnected states is more diagnostic.
Keep the report focused and protect your privacy. Do not send passwords, authentication codes, or full unfiltered logs. If support asks for a log, use the client’s export function and check what it includes before sharing it. If the device belongs to an employer or school, contact its administrator for policy-related settings. If the issue occurs only on a public or managed network, the network operator may need to explain whether VPN traffic is restricted or whether a sign-in step remains incomplete.
Once access is restored, return any temporary diagnostic settings to the configuration you actually want. Re-enable a kill switch if you rely on it, remove test-only proxy settings, and restore your preferred routing rules. Keep a note of the working server or mode, but do not assume it will be the best option on every network. A careful comparison is safer and more useful than leaving several temporary changes enabled without knowing what they do.