A VPN app can show “Connected” while websites and apps still fail to load. That status usually means the client established a tunnel or proxy connection; it does not prove that your device is sending every request through the expected route, that DNS is working, or that the destination is reachable. The cause may be your local network, a particular server, a DNS setting, another proxy, or a kill switch that is blocking traffic.
Work through the checks below in order. After each change, test the same site or app again so you can tell which setting made a difference. Avoid changing several settings at once: it makes the cause harder to identify and can leave behind a second problem.
Fix 1: Check whether the network works without the VPN
Start by separating a VPN problem from an internet connection problem. Disconnect the VPN using the client’s normal control, then open a few ordinary websites or try a service that does not depend on the affected app. If nothing loads with the VPN off, the tunnel is unlikely to be the main cause. The underlying Wi-Fi, mobile data, router, or local network may have lost its connection.
Check the device’s Wi-Fi or mobile-data indicator, and confirm that it is connected to the network you intend to use. If practical, open the same site on another device using that network. When several devices fail, restart the router or access point using its normal procedure, then wait for the network to become available before testing again. If only one device has trouble, focus on that device’s connection settings instead of repeatedly changing VPN options.
Try switching between Wi-Fi and mobile data, or between two known networks, if available. A captive portal can also interrupt access: this is the sign-in or terms page sometimes required by a hotel, school, airport, or public hotspot. Disconnect the VPN briefly, complete the network’s required sign-in, and then reconnect. Avoid entering account credentials on a page unless you are confident it belongs to the network you are using.
If ordinary browsing works without the VPN, reconnect and test more than one destination. A single website may be unavailable, rate-limiting requests, or having a service-side problem. Compare a browser with a separate app, too. If the browser works but one app does not, the issue may be app-specific routing or the app’s own connection state rather than a complete loss of internet access.
- ✅ Confirm that ordinary browsing works with the VPN disconnected.
- ✅ If possible, compare another device or another network.
- ❌ Do not treat one unavailable website as proof that the whole VPN connection is down.
Fix 2: Reconnect and try a different server
If the underlying network works, reconnect the VPN cleanly. Disconnect from the current server, wait for the client to show that the session has ended, and then connect again. A stale session or a brief network change can leave the application displaying an outdated state. If the client offers a separate reconnect or refresh control, use that rather than force-quitting it repeatedly.
Next, choose another available server or region and test again. This helps distinguish a problem with one route from a device-wide problem. A server can be temporarily unreachable from a particular network, undergoing maintenance, or unable to complete a route to a destination. Changing servers is a diagnostic step, not proof that one region is always faster or more reliable. Test the websites and apps you actually need, because different destinations can behave differently.
When a client offers protocol choices, change only one option at a time and use settings that the service and client support. Protocols such as Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are not interchangeable names for the same setting; availability depends on the specific configuration. Do not paste a random server address or import an unknown profile as a workaround. If you use a subscription-based configuration, update it through the client’s normal subscription function and check that the expected server entries are present.
Also verify that the account or configuration is still available in the service’s client or account area. A server name remaining in the list does not necessarily confirm that the latest configuration has been fetched. If your client is third-party, compare its imported settings with the service’s current instructions. You can use the 1KVPN VPN for Expats in China home page to find the relevant service information, but do not share a subscription link publicly: it may contain access credentials.
Keep the test simple: reconnect to the original server once, try another server, and then compare the result. If one server works and another does not, note the affected server and route for support. If all servers fail only on one network, the network or its local restrictions may be involved. If the problem follows the device across networks, examine its DNS and proxy settings next.
Fix 3: Check DNS and app routing
DNS translates a domain name, such as a website address, into information a device can use to connect. A VPN may provide its own DNS settings, accept DNS from the operating system, or apply different rules to different apps. If the tunnel connects but domain names fail to resolve, a browser can appear offline even though the device still has a route to the network.
First, test more than one domain and, where appropriate, compare the result in a browser and an app. If a client includes a DNS mode or DNS reset option, use its documented default before experimenting with custom resolvers. If you previously entered DNS addresses manually in the operating system, router, or client, note those values and restore the normal automatic setting as a test. Do not assume that changing DNS alone will fix an unreachable server or a broken underlying connection.
Then inspect split tunneling, app exclusions, and rule mode. In a full-tunnel configuration, most eligible device traffic is directed through the VPN. In split tunneling, selected apps or destinations may instead use the ordinary network. Rule mode can route requests according to domain, IP address, or other client rules. These behaviors mean that two apps on the same device may take different paths, even while the client reports one connected session.
Temporarily use the client’s standard or global routing mode, if available, to test whether a rule or app exclusion is responsible. If the affected app starts working, restore your preferred mode and review its specific rule rather than leaving every app routed differently than intended. On mobile devices, confirm that the app has not been excluded from the VPN. On a desktop, review the selected system proxy mode and the client’s rule list. Names and controls vary by client, so follow its documentation rather than copying instructions for a different application.
After changing DNS or routing, disconnect and reconnect once so the client can apply the new configuration. If the client provides a DNS cache flush or connection reset function, use that documented function. Avoid installing several DNS utilities or editing advanced network files without understanding how to reverse the changes; overlapping tools can create conflicts that are harder to diagnose than the original fault.
Fix 4: Remove conflicting proxy or VPN settings
A VPN client may operate as a system-level tunnel, configure a system proxy, or use a proxy core with its own routing rules. These modes can be valid, but two active tools may compete to control the same traffic. A second VPN, a browser proxy extension, a manually configured proxy, or a network-filtering application can therefore make the VPN appear connected while requests take an unexpected route or fail entirely.
Check whether another VPN or proxy application is running. Close the extra client through its normal controls, then verify that only the intended app is managing the connection. If you use a browser extension, disable it temporarily for a controlled test. Also inspect the operating system’s proxy settings for an address or port you no longer use. Record any custom value before changing it, especially on a work or school device where a proxy may be required by the organization.
In a compatible client such as Clash Verge, sing-box, or Shadowrocket, check that the selected mode and imported configuration match the instructions for that configuration. A proxy client can show an active core while a particular app is not configured to use its local proxy, or while rules direct the app elsewhere. Conversely, a system-wide proxy left enabled after closing a client can send requests to a local address that is no longer listening. Do not assume that every compatible client uses the same profile format or system-integration behavior.
Restart the affected browser or app after changing proxy settings, because some applications keep their own network sessions open. If the operating system provides a built-in network reset, reserve it for cases where simpler checks have failed and read what it will reset first. A reset may remove saved network details or custom proxy settings, so it is not the first troubleshooting step.
Once the test succeeds, re-enable only the tools you actually need, one at a time. If the connection fails immediately after a particular proxy extension, filtering app, or second VPN is re-enabled, you have a useful lead. Keep the diagnosis limited to the device and software you control, and contact a network administrator before changing managed settings.
Fix 5: Review the kill switch and device permissions
A kill switch is designed to block network traffic when the VPN tunnel is unavailable or does not meet the client’s connection conditions. That protection can look like “VPN connected but no internet” if the tunnel has stalled, if the client has not completed a reconnect, or if the operating system is still enforcing a block from an earlier session. A kill switch is not the same as a general internet switch, and its behavior differs by client and operating system.
If you suspect this setting, first disconnect using the VPN app’s own control and check whether the client reports that the tunnel has ended. Look for a documented option such as kill switch, network lock, or block connections without VPN. If you temporarily disable it for diagnosis, do so only long enough to test and understand that traffic may use the ordinary network while the VPN is off. Re-enable it afterward if you rely on it, and reconnect through the client rather than leaving the device in an unknown state.
On Windows and macOS, check whether a firewall, endpoint-security tool, or network filter is blocking the VPN client or its network component. On iOS and Android, inspect the system’s VPN settings and confirm that the expected VPN profile is active. Android may offer an always-on VPN or a setting to block connections without the VPN; those controls can continue restricting traffic independently of an app’s visible status. On any platform, grant only the permissions the official client requires, and remove obsolete VPN profiles only when you know which profile they belong to.
Restarting the device can clear a stuck network extension or VPN session, but save your work first. After restart, connect using one client and test the same site before enabling other network tools. If the device is managed by an employer, school, or family administrator, ask before changing firewall, profile, or always-on settings. A policy may intentionally prevent direct access when the VPN is disconnected.
If the problem returns whenever the kill switch is enabled, record the operating system, VPN client, selected server, and whether the underlying connection works with the VPN off. Share only the information needed for diagnosis; do not send passwords, authentication tokens, or a complete subscription URL. These details help distinguish a tunnel issue from a local blocking rule without weakening protections as a permanent workaround.
Test one change at a time and confirm the result
After completing the checks, reconnect and test a small set of representative destinations: one ordinary website, the site or app that originally failed, and another service that uses a different app or browser. Check whether the device is still using the expected network and whether the VPN client continues to show a stable session. A successful result in one app does not guarantee that every app follows the same route, particularly when split tunneling or rule mode is enabled.
If the issue persists, write down what you tested and what happened: whether browsing worked with the VPN off, whether a different server changed the result, whether DNS or routing settings were changed, and whether another proxy or security tool was active. Include the device platform, client name, and any exact error message. This is more useful than reporting only that the VPN says “connected,” and it avoids repeating steps that have already been ruled out.
Restore any temporary settings that did not help, especially custom DNS, proxy values, and kill-switch changes. Keep the client configuration aligned with the service’s current instructions, and avoid running two VPN clients at the same time. If the connection works on one network but not another, focus on the affected network’s sign-in, firewall, or access policy. If the same device fails across networks while other devices work, focus on local profiles, app permissions, and routing settings.
- ✅ Test the underlying connection before changing VPN settings.
- ✅ Change one server, DNS, routing, proxy, or kill-switch setting at a time.
- ✅ Restore temporary diagnostic changes when they do not solve the problem.
- ❌ Do not share passwords, tokens, or full subscription links while requesting help.