VPN Connected but No Internet? 5 Fixes to Get Back Online

What “Connected” means—and what it does not

A VPN app can report that it is connected while your browser and other apps cannot reach the internet. The status usually confirms that the client established a tunnel to a VPN server; it does not necessarily confirm that your device has working DNS, that all traffic is routed through the tunnel, or that the server can reach every destination you want to use.

Start by separating the problem into three possibilities: the current Wi-Fi or mobile network has no internet, the VPN connection is interfering with routing or name lookup, or only one app or website is affected. This distinction matters. Reinstalling a client will not fix an outage on the local network, and changing a VPN server will not fix a browser configured to use an unrelated manual proxy.

Before changing settings, note whether the issue began immediately after connecting, after changing a network, or after editing the client configuration. Keep any error messages and the approximate time of the problem. Do not share passwords, authentication details, or a private subscription link when asking for help.

Fix 1: Confirm the current network works without the VPN

Disconnect the VPN using its normal control, then try opening more than one familiar website or app. If nothing loads, reconnecting to the same VPN server is unlikely to help: the underlying network may have lost access, require a sign-in, or be blocking the connection. Avoid repeatedly switching settings until you have checked the basic connection.

1. Turn off the VPN temporarily and test a page or app that normally works. If only one service fails, check that service separately rather than treating the issue as a complete internet outage.
2. Check whether the device is connected to the intended Wi-Fi network or has mobile data enabled. On a public or guest network, open a browser and see whether a network sign-in or acceptance page appears.
3. If you can, compare with another trusted connection, such as your own mobile data instead of Wi-Fi. Do not use an unfamiliar public hotspot for sensitive activity just to run a test.
4. Restart the network connection in a controlled way: disconnect and reconnect Wi-Fi, or briefly toggle mobile data off and back on. If other devices on the same network are also offline, investigate the router or contact the network operator.

Some networks need a captive-portal login before they permit normal traffic. A VPN can make that page harder to reach because it routes requests into the tunnel. Disconnect the VPN, complete the network’s sign-in using its legitimate page, and then try connecting again. On a managed work or school network, follow its administrator’s instructions rather than changing security controls.

• ✅ Test whether ordinary internet access works with the VPN disconnected.
• ✅ Check for a required Wi-Fi sign-in or a service interruption on the local network.
• ❌ Do not assume the VPN server is responsible if every device on the network is offline.

Fix 2: Restart the VPN session and check system permissions

If the network works without the VPN, disconnect in the client, wait for the status to change, and connect again. If the client appears stuck, fully quit and reopen it. On a phone, simply switching to the home screen may leave the VPN service running, so use the client’s disconnect control and check the system VPN indicator before testing again.

Restarting the session can clear a stale tunnel after a network change, such as moving from Wi-Fi to mobile data. If that does not help, restart the device once and test the connection again before making several configuration changes at the same time. Changing one thing per test makes it easier to identify the cause and undo an unsuccessful change.

Review permissions, kill switch, and traffic rules

Desktop and mobile operating systems may ask permission to create a VPN connection. Confirm that the VPN profile is enabled in system settings and that the client has the permissions it needs. Menu names differ by operating system and version, so look for the VPN, network, or connection settings rather than relying on a label that may not match your device.

A kill switch is designed to block internet traffic when the VPN tunnel is unavailable or considered unsafe. If it remains active after a failed connection, the device may appear completely offline even though the ordinary network works. Check whether the client offers a kill-switch setting and read its description. You may temporarily disable it for a brief diagnostic test, but restore your preferred protection afterward; do not treat turning it off as a permanent fix.

Also review split-tunneling or per-app routing. These features can send some apps through the VPN and others directly, or exclude particular apps from the tunnel. A rule that was changed accidentally may explain why one browser works while another app does not. Return to a simple default route for testing if the client provides one, then add exceptions back only when you understand their effect.

When comparing clients, remember that a subscription configuration and the active connection are different things. Importing or updating a configuration does not itself guarantee that the selected route is connected or that the operating system is using it. If you use a compatible third-party client, verify its active profile, selected server, and system-proxy or tunnel mode separately.

Fix 3: Check DNS and proxy settings

DNS translates a site name into the address needed to reach it. If DNS requests fail, a connection may look like “no internet” even when some network traffic still passes. A useful clue is that a familiar app continues to work while websites fail to load, or that a site behaves differently when you use its app rather than its name in a browser. These clues are not proof, but they help narrow the search.

First, disconnect and reconnect the VPN, then test a different website or app. If the client offers a DNS option, use the setting recommended for that client or service instead of entering an arbitrary DNS address. Some networks, privacy tools, and security apps can also apply encrypted DNS or filtering rules outside the VPN. Avoid changing several DNS controls at once; record the original setting so you can restore it.

Next, inspect the operating system and browser for a manually configured proxy. A proxy left over from a work network, test, or older application may send browser traffic to a server that is no longer reachable. Disable only a proxy you recognize as unnecessary. If the device is managed by an employer, school, or other organization, do not remove its required proxy without permission.

Third-party firewall, antivirus, parental-control, and network-filtering apps can affect DNS or block the VPN client. Check their recent notifications and rules rather than disabling every protection feature. If you test a security product’s effect, do so briefly and restore protection afterward. A browser extension that filters requests can also create a problem limited to that browser, so compare with a clean browser profile or another trusted app before changing system-wide settings.

For a practical comparison, test one ordinary site in a browser and one app that does not depend on the same browser profile. If both fail only while the VPN is connected, the issue is more likely to involve the tunnel, DNS, routing, or a system-level rule. If just one browser fails, focus on its proxy, DNS, extensions, and saved network settings.

Fix 4: Try another server or connection protocol

If the local network works and DNS or proxy settings look normal, the selected VPN server or protocol may not be working well with the current network. Disconnect first, select another available server, and reconnect. A server label identifies a route or location; it does not guarantee that every destination will work from every network. Test an ordinary website and app after each change.

Some networks handle one connection method more reliably than another. If the client supports protocol selection, try a different option that is available in its settings, then reconnect and compare. Protocol names such as WireGuard, Shadowsocks, VMess, Trojan, and Hysteria2 refer to different technologies or connection modes; they are not interchangeable labels, and a client may support only a subset. Use the options provided by your service and client rather than copying an unrelated configuration from the internet.

Do not change the server, protocol, DNS, and firewall rules all at once. If the new combination works, you will not know which change mattered, and if it fails, returning to a known starting point will be harder. Record the original selection, test a single alternative, and restore the original if the result gets worse.

When choosing a new route, consider whether the problem occurs on one network or everywhere. If the same server works on mobile data but not on a particular Wi-Fi network, a local network rule may be involved. If several routes fail on the same device and network while unprotected access works, focus on the client configuration, permissions, or a local security application. When researching a service or its available routes, the VPNZK China VPN home page is one place to start; the actual server and protocol choices should still be checked in the client you use.

On mobile devices, a network handoff can leave a session stale. After switching between Wi-Fi and mobile data, disconnect and reconnect once. On a laptop, sleep and wake cycles or changing networks can have a similar effect. If reconnecting fixes the issue only temporarily, note when it happens and which network transition preceded it; that detail can help distinguish a route problem from an application defect.

• Try a different available server while leaving the protocol unchanged.
• If needed, restore the original server and test another protocol offered by the client.
• Compare the same setup on another trusted network, if available.
• Keep a note of which single change made the connection improve or fail.

Fix 5: Update the client and verify its configuration

An outdated client or an old imported configuration can behave differently after an operating-system update or a change in network conditions. Check the client’s own update mechanism and follow the service’s setup instructions for your platform. Avoid downloading installers or configuration files from an unverified third-party source. If you use a third-party compatible client, confirm that it supports the configuration format you imported and that the profile has not been disabled or replaced by another profile.

Refresh a subscription or configuration only through the source that provided it. A refresh may update available routes or settings, but it does not necessarily repair a local proxy, grant missing system permission, or restore access to a network that is offline. After updating, select a route explicitly and confirm that the client shows it as active. If the configuration contains groups or rules, check that the selected group has a usable route rather than assuming the first item is automatically in use.

Before reinstalling, save any information you are permitted to keep, such as the client name, operating-system version, selected protocol, and non-sensitive error text. Do not export or send a configuration if it contains credentials. Reinstalling should be a later step, especially on a device where a VPN profile, managed policy, or work security application is controlled by an administrator.

For a clean test, temporarily use the client’s standard connection mode and a route provided in the current configuration. Turn off only optional routing rules that you understand, and restore them after the test. If the connection still fails, preserve the configuration state and collect diagnostic details rather than repeatedly importing different files.

When to contact support—and what details to include

If the network works without the VPN but multiple available routes fail after the client, permissions, DNS, and proxy checks, contact the service or client support team. A concise report is more useful than saying only “the VPN is broken.” Describe what succeeds and what fails, and include the steps you already tried so support can avoid asking you to repeat them.

• ✅ Include your device type, operating-system version, and VPN client name and version.
• ✅ State whether ordinary internet access works with the VPN disconnected.
• ✅ Describe the network type, such as Wi-Fi or mobile data, without exposing private network credentials.
• ✅ Note the selected server or route, protocol, approximate time of the failure, and exact error text.
• ✅ Say whether another route, protocol, browser, app, or trusted network changed the result.
• ❌ Do not send account passwords, authentication tokens, private keys, or an unredacted subscription link.

If support requests logs, use the client’s official export or diagnostic function and review what the file contains before sharing it. Logs can include device identifiers, network details, or other private information. Send them only through the support channel you have verified, and redact unrelated personal data where appropriate.

For work or school devices, contact the network administrator before changing managed VPN, proxy, firewall, or security settings. On a personal device, restore any temporary diagnostic changes that did not help. Keeping one known-good baseline makes the next test easier and reduces the chance that a troubleshooting change creates a second problem.