Confirm where the failure is
A VPN client can display “Connected” even when ordinary browsing is unavailable. That status usually means the client has established or attempted to establish a tunnel; it does not prove that every app is sending traffic through it, that DNS is resolving correctly, or that the VPN server can reach the destination. Start by identifying whether the problem is your underlying internet connection, the VPN route, or a particular device or app. This avoids changing several settings at once and making the cause harder to find.
First disconnect the VPN and try opening a few familiar websites or apps. If they still do not load, troubleshoot the local connection before changing VPN settings: check Wi-Fi or mobile-data status, reconnect to the network, and see whether another device on the same network can get online. If those devices also fail, restart the router or contact the network provider as appropriate. A VPN cannot repair an internet connection that is already unavailable.
If the internet works normally with the VPN disconnected, reconnect and test more than one destination. Try a website you use regularly, a different site, and an app that does not depend on the browser. A single site failing may indicate a site-specific issue, filtering, or a browser problem rather than a completely broken tunnel. If all apps fail only while connected, focus on the client, routing, DNS, or the selected server.
Also check whether the VPN is configured for full-tunnel or split-tunnel routing. In full-tunnel mode, most or all internet traffic should use the VPN. In split tunneling, only selected apps or destinations may use it; other traffic is intentionally sent through the ordinary connection. A browser that is excluded by an app rule can appear offline if its expected route differs from the one the client is applying.
- ✅ Confirm the local connection works with the VPN disconnected.
- ✅ Test more than one website and, if possible, more than one app.
- ✅ Check whether the client uses full-tunnel or split-tunnel routing.
- ❌ Do not reinstall the client or reset every network setting before isolating the failure.
Check the tunnel, routing, and server
When the local connection is healthy but traffic stops after connecting, briefly disconnect and reconnect from the VPN client itself. Wait for the client to finish establishing the tunnel before testing. If the client has a traffic or connection log, look for repeated reconnects, a failed handshake, a DNS error, or a route that is being rejected. A connected indicator can remain visible during a transient interruption, so the log may provide more useful detail than the status label.
Try a different server or region, then test again without changing any other settings. This helps distinguish a problem with one route from a device-wide configuration issue. If one server works and another does not, the original route may be unavailable, overloaded, or unable to reach a particular destination at that moment. Do not assume the country label alone explains the failure; the actual route and service availability can differ between nodes with similar labels.
Check for automatic server selection and failover options. A client may move traffic to another node when the current route becomes unstable. That can be helpful for general browsing, but it can also interrupt active sessions or place traffic on a route that behaves differently. For diagnosis, select a single available server manually and avoid changing regions repeatedly during the same test. Once you know whether a fixed route works, you can decide whether automatic selection is useful for normal use.
Proxy mode matters too. Some desktop clients can set a system proxy, while others create a virtual network interface or tunnel. In a rule-based mode, only destinations matched by the configuration use the proxy; in global or tunnel modes, a broader set of traffic is routed through it. If a client indicates that it is connected but the system proxy is disabled, or the browser is configured to use a different proxy, traffic may not follow the route you expect. Check that there is not another proxy application active at the same time.
If you are using a compatible third-party client such as Clash Verge, sing-box, or Shadowrocket, confirm that the subscription or configuration has updated successfully and that the selected profile is active. Client compatibility depends on the configuration format and supported options, not just the protocol name. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are distinct protocols or implementations; choosing a client that does not properly support the configuration can produce a connection indicator without usable traffic. When in doubt, compare the same subscription in the service’s recommended client rather than editing server parameters manually.
Work through the fixes in a controlled order
Make one change at a time and retest after each change. This is especially important if you use the same device for work, banking, or local network services: an unnecessary reset can remove settings that were unrelated to the VPN. The sequence below begins with reversible checks and moves toward more specific network adjustments.
- Reconnect cleanly. Disconnect in the VPN app, wait until it reports that the tunnel is stopped, and then connect again. If the client offers a safe restart option, use that rather than force-quitting the app while it is changing routes.
- Verify the selected route. Choose another available server and leave other options unchanged. If the new route works, note the original server and retry it later. Avoid interpreting a single successful connection as proof that every route is working.
- Check proxy and tunnel settings. Confirm that the client’s proxy mode matches your intended use and that the operating system is not pointing to a stale manual proxy. Close or disable other proxy and VPN clients before testing, because they can compete to control the same system traffic.
- Refresh DNS only if the symptoms fit. If an app can reach a destination by address but fails when using its domain name, or pages stall while the tunnel otherwise appears active, DNS is a reasonable next check. Restarting the client may refresh its DNS handling. On a computer, you can also clear the system DNS cache using the operating system’s standard method; on Linux, the command depends on the active resolver service.
- Review security and network permissions. Check that the VPN app is permitted to create a VPN connection and that a firewall or endpoint-security tool is not blocking its network extension, virtual adapter, or DNS traffic. Prefer allowing the verified app through the relevant control over turning off protection for the whole device.
- Change protocol only when needed. If the client and service offer more than one supported protocol, try another compatible option after recording the current setting. Networks can treat transports differently, but a protocol switch is a diagnostic test, not a universal speed or reliability fix.
- Restart the device if routes remain stuck. A restart can clear a stale network interface or proxy state. Before resetting network settings, make sure you know the Wi-Fi credentials and understand that saved network details may be removed.
For Windows, check the VPN client’s adapter and Windows proxy settings, then verify that the client is allowed through Windows Firewall. The command ipconfig /flushdns clears the local DNS resolver cache; run it in Command Prompt and retry the affected site. It does not change the VPN subscription or repair an unavailable server. If the issue began immediately after changing an adapter or proxy option, restore that option to its previous value before trying broad network resets.
On macOS, confirm that the VPN configuration or network extension is authorized in System Settings and that no manual proxy remains enabled unexpectedly. If you need to clear the DNS cache, macOS commands can vary by release; a commonly used sequence is sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. Enter administrator credentials only in the system prompt or trusted terminal. If a permission prompt appears, approve only the VPN client you intended to install.
On Android, check that the expected VPN is selected in the system VPN settings and that another VPN is not active. Review “Always-on VPN” and “Block connections without VPN” if enabled: these options can intentionally prevent ordinary traffic when the tunnel is down, which protects privacy but can look like a complete internet outage. Also check Private DNS. A custom Private DNS hostname may be unreachable through the current network or route; temporarily return it to the previous or automatic setting for a controlled test, then restore it if the test does not help.
On iPhone or iPad, verify that the VPN profile belongs to the client you are using and that the app has permission to add or manage its VPN configuration. Disconnect and reconnect through the app, not only through a second VPN app or profile. If switching between Wi-Fi and mobile data changes the result, note which network works and avoid deleting profiles until you have confirmed that you can recreate them. On all mobile platforms, a device-wide “block without VPN” option can deliberately stop traffic when the tunnel cannot carry it.
For Linux, inspect the client’s connection status and resolver configuration using the tools provided by the distribution. Systems using systemd-resolved commonly support resolvectl flush-caches; older setups may use a different service or command. Do not overwrite resolver files with generic instructions from another distribution. If you are using a command-line client, confirm that its process is still running and that the system route points to the intended tunnel interface.
When comparing setup choices or checking which official platform options are available, the VPNGI Best VPN for China home page provides the relevant service overview. Keep the troubleshooting test focused on your current device and route; changing providers, clients, and network settings at the same time makes it difficult to identify what actually restored access.
Find DNS, proxy, and permission conflicts
DNS translates a domain name into an address that a device can contact. A VPN may carry web traffic through its tunnel while DNS queries still use an unavailable local resolver, or the client may apply a DNS rule that does not match the active routing mode. In either case, a page can fail to open even though the VPN status says connected. DNS problems are more likely when some apps continue to work, a site fails by name but not by a known address, or the issue changes after reconnecting to another network.
Do not replace DNS with an arbitrary public address as the first response. Some services rely on their own DNS behavior, and a manually configured resolver can make region-sensitive services behave differently or bypass settings intended to keep queries within the tunnel. First use the client’s recommended DNS configuration, update its profile if the configuration is outdated, and check whether the client has a “DNS through proxy” or equivalent option. If you change a system DNS setting to test, record the original value and restore it if the result is unchanged.
Proxy conflicts can be less obvious. A browser may have its own proxy setting, while the operating system and VPN client each have separate controls. A leftover manual proxy can send requests to a local address where no proxy is listening; a second client may overwrite the system proxy; and a browser extension can route traffic independently of the VPN. Check the browser, operating system, and active network apps rather than repeatedly toggling the VPN connection alone.
Security software, parental controls, and managed-device policies can also block traffic. Look for a recent firewall notification or a newly installed network filter. If the device is managed by an employer or school, do not remove its security profile or bypass its policy; ask the administrator whether the VPN client is permitted. On a personal device, use the security tool’s approved exception process and restore any temporary test setting immediately.
Pay particular attention to kill switches and “block connections without VPN” settings. Their purpose is to prevent traffic from leaving through the ordinary connection if the tunnel drops. When a server is unreachable or a client has lost its route, the result can be “no internet” rather than an unprotected connection. Do not disable this protection casually. If you choose to test it, do so briefly, understand that traffic may use your regular network, and turn it back on as soon as the test is complete.
Know when to change routes or ask for help
Try another server when the local connection works, the client has permission, and the same device can browse normally after disconnecting. If changing the route restores access, the original node or route was the likely point of failure. If every available route fails but ordinary browsing works, compare the client’s logs, DNS mode, proxy settings, and firewall permissions. Reinstalling the client is a later step, not the starting point: first make sure you can recover your subscription and any custom routing rules.
If the connection fails only on one Wi-Fi network but works on mobile data, the network may restrict VPN traffic or require a captive-portal sign-in. Disconnect the VPN, complete the network’s normal sign-in page if one is required, then reconnect and test. If the route works on Wi-Fi but fails on mobile data, check the client’s permission to use cellular data and review any data-saving or background restrictions. These comparisons help separate a network policy from a client configuration issue.
If you contact support, provide useful evidence without exposing credentials. Include the operating system and version, the client name and version, whether the issue affects all apps or only some, whether disconnecting restores internet access, the route and protocol you tested, and any relevant error text or log excerpt. Remove usernames, subscription links, access tokens, and unrelated personal information from screenshots and logs. A subscription URL can function like a credential, so treat it as private.
After troubleshooting, restore any temporary changes you made: return DNS to its previous setting if the test did not help, re-enable firewall protections, restore the intended kill-switch behavior, and remove only the stale proxy entry you identified. Then reconnect using the route and mode that worked and verify both the target app and ordinary local services. A stable result should be reproducible after a normal disconnect and reconnect, not dependent on several undocumented manual changes.
Keep a short note of the successful configuration: client, mode, DNS handling, and selected route. If the problem returns, you can compare the new state with the known-working one instead of repeating every step. If no route works and the service’s status information or support team confirms a broader outage, avoid repeatedly changing device settings; wait for the route to recover and retest with the same controlled setup.
- ✅ Switch servers when the local internet works but a particular route does not.
- ✅ Compare Wi-Fi and mobile data to identify network-specific restrictions.
- ✅ Share sanitized error details when asking for technical support.
- ❌ Do not publish subscription links, credentials, or unredacted logs.
- ❌ Do not leave temporary firewall, DNS, or kill-switch changes in place without a clear reason.