A VPN client can report “Connected” while your browser and apps still appear offline. That status usually confirms that a tunnel was established; it does not prove that your device can resolve domain names, reach the public internet, or send every app’s traffic through the intended route. The cause may be a Wi-Fi sign-in page, a local proxy setting, a DNS problem, a routing rule, or a server path that is not working well for your current network.
Use the checks below in order. Change one setting at a time and retest the same website or app after each change. This makes it easier to identify the cause and undo a change that does not help. If you are using a work-managed device or a network with strict access rules, do not remove required security settings without checking with the administrator.
Diagnose what is actually offline
Start by separating a device-wide connection problem from an app-specific one. With the VPN connected, try opening more than one website and, if possible, a second app that uses the internet. Then disconnect the VPN and repeat the same tests. If everything fails in both states, investigate the Wi-Fi or mobile connection first. If access returns only when the VPN is disconnected, the issue is more likely related to the VPN route, DNS, proxy settings, or traffic rules.
Also check whether the VPN client shows a connected state for the current network, rather than merely displaying that a profile is selected. A network change can interrupt a tunnel while the app interface takes time to refresh. On a phone, switching between Wi-Fi and mobile data may trigger this situation; on a computer, sleep, waking, or reconnecting to a different access point can do the same. Disconnect and reconnect once, then wait for the client to report its current status before testing again.
7
practical fixes
1
change at a time
2
connection states to compare
These figures describe the structure of this troubleshooting guide, not a guarantee about repair time or connection performance. A useful initial comparison is simple: test the same destination with the VPN on and off, then test another app. A website that fails by name but works when reached by a known IP address may point toward DNS, although not every service permits a meaningful IP-based test. Avoid treating a single browser error as proof that the entire device has lost internet access.
- ✅ Test the same destination with the VPN connected and disconnected.
- ✅ Compare at least two apps or websites before changing settings.
- ❌ Do not change DNS, routing, and protocol settings all at once.
Four quick checks for common causes
Fix 1: Check the underlying network
Disconnect the VPN and confirm that Wi-Fi or mobile data works normally. Check the device’s network indicator, open a page you have used successfully before, and, if available, try another device on the same Wi-Fi. If no device can access the internet, restart the router only if you are allowed to do so, or contact the network operator. If just one device is affected, forget and reconnect to the Wi-Fi network only when you know its password and any required network settings.
For mobile data, confirm that data access is enabled and that the operating system has not restricted the VPN app or the app you are testing. A weak or unstable local connection can also cause a tunnel to establish and then fail to carry useful traffic. Check the local network first rather than repeatedly importing a subscription or reinstalling the VPN client.
Fix 2: Complete a captive-portal sign-in
Hotels, campuses, airports, offices, and some public hotspots may require you to accept terms or sign in through a browser before unrestricted access is available. The VPN can connect while the network still blocks ordinary traffic until that step is completed. Disconnect the VPN, open a browser, and visit a simple page to see whether a sign-in screen appears. Complete the network’s instructions, verify that ordinary access works, and reconnect the VPN.
If the sign-in page does not appear, do not assume that a random redirect or security warning is safe. Use the network’s official instructions or ask its staff. Some networks block VPN traffic altogether; if so, follow the network owner’s rules rather than attempting to bypass its access controls.
Fix 3: Check for another proxy or VPN
A second proxy, VPN, firewall, DNS-filtering app, or security client can compete with the VPN for the same system traffic. Check whether another network tool is active, including browser-specific proxy extensions, a manually configured system proxy, or a workplace security agent. Temporarily pause only tools that you control and are permitted to change, then reconnect the VPN and test again.
On Windows, review the system proxy settings and check whether another VPN application is still running in the background. On macOS, look at the active network service and any installed network filters. On Android and iOS, check whether another VPN profile or filtering app has taken the active VPN slot. Linux users may need to inspect their desktop network settings or the configuration of a separately managed proxy. Restore any setting you changed if the test makes no difference.
Fix 4: Check DNS resolution
DNS translates a domain name, such as a site address, into information that helps the device reach the destination. A tunnel may be active while DNS requests are blocked, sent to an unsuitable resolver, or handled differently by the operating system and the VPN client. If some apps work but websites fail to load by name, DNS is one possibility. Check the client’s DNS mode and use its documented default or recommended setting as a test; do not enter an unfamiliar DNS address just because it appears in an online troubleshooting post.
Some clients have an option to flush or refresh DNS, while desktop operating systems may cache previous answers. Restarting the browser or reconnecting the network can help distinguish a stale cache from a persistent resolver issue. If you use custom DNS for a work network, parental controls, or security filtering, record the original value and consider the consequences before changing it. Restore it after testing if the VPN is not the cause.
A repeatable check you can run now
Use this sequence to test the connection without making several changes at once. It works as a general diagnostic method on Windows, macOS, Android, iOS, and Linux, though the location and names of settings vary by operating-system version and client. If you need help choosing a service or checking available setup information, the VPNGF Best VPN for China homepage provides the site’s starting point.
- Record the starting state. Note whether you are on Wi-Fi or mobile data, the VPN client’s connection status, and whether the problem affects one app or several. Do not include passwords, private keys, or an unredacted subscription link in notes you plan to share.
- Test without the VPN. Disconnect it briefly and open the same destinations. If they still fail, stop changing VPN settings and investigate the underlying network or its sign-in requirements.
- Test after reconnecting. Connect once, wait for the client to finish establishing the tunnel, then repeat the same tests. If the client offers connection logs, check for a clear DNS, route, or permission error rather than guessing from the status icon.
- Change one item only. For example, complete a captive-portal sign-in, disable a conflicting proxy, or restore the client’s default DNS option. Retest the same destination and write down whether the result changed.
- Undo unsuccessful changes. Return settings to their original state before moving to another test. This keeps the device understandable and prevents one troubleshooting attempt from creating a second problem.
On desktop systems, also check whether an operating-system firewall or endpoint-security product has asked for permission to allow the VPN client. Approve only the legitimate client you installed from an authorized source and only when the permission matches the action you expect. On mobile devices, confirm that the VPN profile was accepted and that the app is allowed to use the network in the background if your setup depends on a persistent connection. A permission prompt that was dismissed or denied can leave the interface looking ready while traffic is restricted.
Do not use a speed test as the only diagnostic. A failed speed test can be caused by the test service, DNS, a browser extension, or the route to that particular test server. Conversely, one successful page does not prove that every app follows the same route. When an issue is limited to a single app, check that app’s own proxy settings, account status, and network permissions before changing system-wide VPN configuration.
Check routing, then try another server or protocol
Fix 5: Review the kill switch and split tunneling
A kill switch is designed to block traffic if the VPN tunnel is unavailable or does not meet the client’s conditions. That behavior can look like a total internet outage when the connection has dropped or a network change has left the client in a blocked state. Check the client’s status and its documented recovery steps. If you temporarily test with the kill switch disabled, understand that traffic may leave outside the VPN; avoid doing this for sensitive activity, and re-enable the protection after the test.
Split tunneling and per-app routing can also make the results seem inconsistent. Some apps may be included in the VPN while others are excluded, or a rule may send a destination to a route that is unavailable. Temporarily use the client’s default routing mode, if it provides one, and test again. If that fixes access, inspect the rules one by one. Do not assume that a browser and a desktop application use the same route simply because they are on the same device.
Fix 6: Select a different server
A particular server may be unavailable, undergoing maintenance, or poorly matched to the network you are currently using. Disconnect cleanly, select another suitable server in the client, and establish a fresh connection. If the client groups servers by country, region, or purpose, use a choice appropriate for the destination and the service’s guidance. A nearby server may be a reasonable first comparison, but geographic distance alone does not guarantee a better connection.
Retest the same website and app after changing servers. If only one server fails, save its name for a support report and continue with a working option if one is available. If several servers show the same behavior, switching through the full list is unlikely to identify the underlying cause; return to DNS, routing, local proxy, and network checks instead.
Fix 7: Switch to another supported protocol
Networks can handle VPN transports differently. A protocol that connects on one Wi-Fi network may fail to carry traffic on another because of filtering, routing, or compatibility differences. If your client and service provide a choice of supported protocols, select one of the documented alternatives, reconnect, and test the same destination. Change only the protocol for this test, leaving DNS and routing settings unchanged so the result is useful.
Do not paste an arbitrary protocol name into a custom client or assume that every client supports every configuration. The service’s configuration format, the client’s core, and the selected transport must be compatible. If you use a third-party client, confirm that its imported profile supports the protocol and settings supplied by your provider. When a protocol switch does not help, restore the previous selection before continuing.
When to contact support and what to include
If the device works without the VPN but remains offline across multiple servers and supported protocols, contact the VPN provider’s support team. If it fails with and without the VPN, contact the network operator or your device administrator instead. Explain the comparison you performed and the result, rather than reporting only that the VPN is “connected but broken.” This helps the person responding separate a client setup issue from a local network or service-side problem.
A useful report includes the device operating system, VPN client name and version, connection type (Wi-Fi or mobile data), the approximate time the problem occurred, whether it affects all apps or only specific ones, and the exact error message. Include the server label and selected protocol if visible. State whether disconnecting the VPN restores access and whether a different server or protocol changed the result. If logs are available, follow the provider’s instructions for exporting and sharing them.
Before sending logs or screenshots, review them for account names, email addresses, public IP addresses, access tokens, subscription URLs, and other personal information. Redact sensitive fields where possible, but do not edit the technical error lines that support needs to diagnose the issue. Never send a password or a one-time verification code. If a support agent requests a configuration file, confirm how it will be handled and use the provider’s official support channel.
Until the issue is resolved, use a connection method permitted by the network owner and appropriate for the sensitivity of your activity. Avoid leaving protection features disabled after a short test, and do not install an unknown “fix” utility or change system-wide proxy settings based on an unverified instruction. Once service returns, note which single change fixed the problem. That record can make the next Wi-Fi handoff, DNS issue, or app-specific routing problem much easier to resolve.
- ✅ Share the operating system, client version, server label, and reproducible error.
- ✅ Say whether the connection works with the VPN disconnected.
- ❌ Do not send passwords, private keys, or unredacted subscription links.