VPN connected but no internet: identify what is actually failing
A connected status only confirms that the client has established a tunnel or proxy connection. It does not prove that every app is sending traffic through it, that DNS is resolving correctly, or that the selected route can reach the destination you need. That distinction matters: changing servers repeatedly may not help if the problem is a local proxy setting, a blocked permission, or an app using a different network path.
First, establish the scope. Try a few unrelated websites in a browser, then try another app. If only one website or service fails, the issue may be specific to that destination, its account, or its own outage. If the browser works but one app does not, check that app’s proxy support, VPN permissions, and any per-app routing rules. If nothing works while the VPN is on but normal access returns as soon as it is off, concentrate on the client, route, DNS, and system network settings.
Also check whether the device has ordinary internet access without the VPN. Disconnect the VPN briefly and load a familiar site. If that fails too, troubleshoot Wi-Fi or mobile data first: reconnect to the network, check whether a sign-in page is waiting, and try another connection if one is available. A VPN cannot repair an internet connection that is already offline.
Run the quick checks before changing configuration
Begin with reversible checks. Note the device, network, selected profile, and client mode so you can undo a change if it has no effect. Close and reopen the affected app after reconnecting; some apps keep an existing network session and do not retry through a newly established tunnel immediately.
- ✅ Open more than one unrelated site to distinguish a general failure from a single destination problem.
- ✅ Disconnect and reconnect once, then wait for the client to report a completed connection.
- ✅ Check whether Wi-Fi or mobile data works when the VPN is disconnected.
- ✅ Look for a captive portal, such as a hotel, airport, or café sign-in page, on the underlying network.
- ❌ Do not run two VPN or proxy clients at the same time; they can compete for system routes and DNS settings.
- ❌ Do not delete profiles or reset all network settings before recording the current configuration.
When you need a provider-side reference, VPN61 VPN for China Travel is relevant to comparing the service’s supported client platforms and connection options with the device you are troubleshooting. Keep the diagnosis focused on your actual symptom rather than assuming a service change will fix every local network issue.
Seven fixes to try, from simplest to more specific
Work through these checks in order and test after each meaningful change. If internet access returns, stop there; changing additional settings can introduce a second problem and make it harder to identify the cause.
Fix 1: reconnect and verify the active profile
Disconnect from the active profile, wait for the client to finish closing the connection, and connect again. Confirm that the expected profile or node is selected rather than an empty group, an outdated entry, or a profile that belongs to another service. If the client has groups or automatic selection, choose a specific available entry temporarily so that the test does not silently switch destinations.
If reconnection fails or the client reports an authentication, configuration, or timeout error, note the exact wording. That message is more useful than repeatedly tapping Connect. A successful tunnel handshake followed by no page loads points to a different stage than a connection that never establishes.
Fix 2: check the underlying Wi-Fi or mobile network
On Wi-Fi, disconnect and rejoin the network, and check whether the router requires a web-based sign-in. On mobile, confirm that mobile data is enabled and that the device has not switched to a network with no usable internet. If possible, test the same client over a different trusted connection. A failure on one Wi-Fi network but not another suggests that the router, network policy, or DNS provided by that network may be involved.
Some public networks restrict VPN traffic until a user accepts terms or completes a sign-in. Disconnect the VPN long enough to open the network’s legitimate sign-in page, complete the required step, and then reconnect. Avoid entering credentials into a page whose address or identity you cannot verify.
Fix 3: remove proxy conflicts and check routing mode
Check whether another proxy, VPN, firewall utility, or network-filtering app is active. A browser extension may also apply a separate proxy to browser traffic. Turn off only the competing component for a controlled test, then restart the affected app. If you use a compatible client such as Clash Verge or sing-box, review whether its system proxy or TUN mode is enabled; do not assume those modes cover traffic identically.
Rule-based mode can send some requests directly while proxying others. A rule, bypass list, or per-app exclusion may therefore explain why one app has no access even though another works. For diagnosis, use a clearly understood mode supported by the client and test one app. Restore your preferred routing rules after the test rather than leaving broad changes in place without understanding their effect.
Fix 4: test for a DNS problem
DNS translates a site name into an address. When DNS requests go to an unavailable resolver, a browser may show a name-resolution error even though the tunnel itself is connected. Compare the error: a message saying a domain cannot be found differs from a page that starts loading and then times out. Try a different unrelated domain, and if the client offers a documented DNS option, switch to another supported setting for a temporary test.
Also review whether the device has a custom DNS service, encrypted DNS setting, or filtering app active. These can conflict with DNS handling in a VPN client. Change one setting at a time and record the original value. On desktop systems, reconnecting the network interface or restarting the device may clear stale resolver state; on mobile, toggling the network connection and reconnecting the client is a safer initial test than installing an unfamiliar DNS utility.
Fix 5: confirm device permissions and system VPN status
Mobile operating systems require permission for an app to create a VPN connection. Confirm that the permission prompt was accepted and that the system’s VPN indicator agrees with the client. Check whether another app has taken over the system VPN slot; many mobile systems permit only one active system VPN connection at a time. If you recently updated the operating system or client, reopen the app and review its connection permission before changing profiles.
On Windows, macOS, and Linux, review whether a firewall, endpoint security tool, or network extension has blocked the client or its virtual interface. Do not disable essential security software as a general fix. If a security product shows a specific block, use its documented allow-listing process or ask its administrator to assess the rule. Managed work or school devices may intentionally prevent VPN use, and local policy should not be bypassed.
Fix 6: test another server or route
A route can be temporarily unavailable or incompatible with a particular destination, even when the client can establish a connection. Select another available server or route in the same client and repeat the same test. Keep the device, network, app, and routing mode unchanged so the comparison is meaningful. If the alternative works, the first route may be the issue; if neither works, a local setting or broader network restriction becomes more likely.
Do not infer that a route is broken solely because one website fails. Websites can reject certain traffic, limit sessions, or behave differently by region. Test a small set of unrelated destinations and distinguish DNS errors, connection timeouts, and explicit access-denied messages. Those symptoms point to different causes.
Fix 7: change protocol only after simpler checks
If the client supports more than one protocol, changing protocols can help when the current one is blocked or mishandled by the underlying network. Use only protocols and options the service and client actually support. For example, clients may present choices such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, but the names are not interchangeable settings: a protocol must be offered in the configuration and supported by the client.
Change one option, reconnect, and retest the same apps. If the client imports configuration through a subscription, do not edit generated fields unless the client or provider documents that workflow. An incorrect manual change can make a valid profile unusable. Restore the original option if the result is worse, and record which setting changed before contacting support.
Use a controlled test to narrow down the cause
Once the quick checks are complete, compare results systematically rather than changing several things at once. A useful test holds the device and app constant while changing only the network, route, or protocol. For example, if the same profile works on mobile data but not on home Wi-Fi, focus on the router or network restrictions. If all routes fail only in one app, investigate that app’s proxy support and exclusions. If multiple apps fail on every network while the VPN is active, review the client’s DNS, routing mode, permissions, and system conflicts.
Keep a short record of each attempt: the operating system, client name and version if known, network type, active profile, routing mode, whether other apps work, and the exact error shown. Avoid sharing a full subscription URL, password, private key, or other access credential in a public post or screenshot. Crop screenshots to remove account information and notification details.
After testing, return any temporary DNS, proxy, or protocol changes that did not help. On managed devices, ask the administrator before changing firewall or network policies. On a personal device, use the operating system’s documented network controls; broad resets can remove saved Wi-Fi networks, certificates, and other configuration without identifying the original cause.
What to send support if the problem continues
If none of the checks restores access, provide a concise report rather than only saying “the VPN is connected but the internet is down.” Include the device platform, client name, whether the problem started after an update or network change, whether the underlying internet works with the VPN disconnected, and whether the failure affects every app or only particular ones. Add the selected route, protocol, and routing mode if the client displays them.
Describe the sequence you tested and the result of each useful comparison: another network, another route, another app, or a different supported protocol. Include the exact error text and the approximate time it occurred, but do not invent latency figures or claim a service outage based on a single failed page. If the client has a diagnostic export, inspect it for account identifiers or credentials before sharing it, and use the provider’s official support channel.
Support can act more quickly when the report separates connection establishment from traffic delivery. State whether the client reaches a connected state, whether DNS lookups fail, whether an IP-based destination behaves differently from a domain name, and whether the same profile works on another network. Never send passwords, private keys, or an unredacted subscription link. A clear, privacy-conscious description helps distinguish a local device issue from a route or service-side problem without exposing account access.
In most cases, the most useful first steps are to confirm ordinary internet access, rule out competing proxies, verify app coverage and DNS, and compare one alternate route. Make each change reversible, keep notes, and stop once the cause is clear. That approach is safer and more effective than reinstalling clients or resetting the whole device before you know which part of the connection is failing.