VPN Connected but No Internet? 7 Quick Fixes to Try

Start with the symptoms

Before changing settings, determine what “no internet” means in your case. Open more than one app or website, including a service that does not depend on the VPN. If everything fails only while the VPN is connected, the tunnel, its DNS configuration, or the device’s routing settings are likely places to investigate. If only one website or app fails, the tunnel may be working while that particular destination is unavailable, blocking the exit address, or using a connection method that does not cooperate with the current route.

Compare the same device with the VPN disconnected. If ordinary browsing also fails without the VPN, troubleshoot the Wi-Fi or mobile connection first: check whether the device joined the intended network, whether a sign-in page is waiting, and whether other devices on that network can browse. A VPN cannot repair a broken local connection. If the internet works without the VPN but stops when it connects, continue with the client and route checks below.

Also note the scope of the issue. If one device fails but another device on the same network works, focus on the affected device’s client, operating-system network settings, and local security software. If several devices using the same service and network fail at the same time, a server or wider network issue becomes more plausible. These clues are not proof by themselves, but they help narrow down where to look.

These are diagnostic checks, not performance measurements. A “connected” label is useful evidence that the client reached a connection state, but it does not report whether every app’s traffic follows the intended route.

Seven fixes to try, one at a time

Work through these checks in order. After each change, disconnect and reconnect if needed, then retry the same website or app. If the connection starts working, stop there and keep a note of the setting that made the difference.

1. Check the local connection. Disconnect the VPN and open a website. If it still will not load, reconnect to Wi-Fi or mobile data, check for a captive-portal sign-in page, and test another network if one is available. On public Wi-Fi, the access page may need to be completed before a tunnel can carry traffic.
2. Reconnect the client. Disconnect from the current server, wait for the client to show that it is disconnected, and connect again. If that does not help, quit and reopen the client. This can clear a stalled session without changing your configuration.
3. Select a different server or region. The selected server may be temporarily unavailable, congested, or unable to reach a particular destination. Choose another available option, reconnect, and test the same service. A different region can also change how a website responds, so compare results for the actual app you need rather than relying only on a server name.
4. Review the client’s routing mode. Rule-based or split-tunnel modes send different apps or destinations through different routes. A rule may send the affected app directly, or a custom rule may point it to a route that is not working. For a controlled test, use a mode that routes all traffic through the proxy if your client and service support it. Restore your preferred mode after the test and review the relevant rules.
5. Check DNS settings. DNS translates a website name into an address. If the tunnel connects but DNS requests use an unavailable resolver, names may fail to load even when other parts of the connection are working. Temporarily return custom DNS settings to the client’s default or service-provided option, reconnect, and test a site by its normal domain name. Avoid entering an unfamiliar DNS address from an untrusted source.
6. Look for local network conflicts. A second VPN, proxy app, firewall rule, security product, or manually configured system proxy can interfere with routing. Close other proxy or VPN clients and check whether the operating system has a proxy setting left over from another app. If you adjust a firewall, make a narrow, temporary test and restore the protection afterward; do not leave security features disabled as a permanent fix.
7. Try another supported protocol or transport. If the client offers more than one configuration, switch to another option supported by your service, reconnect, and repeat the same test. Protocols and transports can behave differently across networks, but changing one is a diagnostic step—not a guarantee that the alternative will work better. Do not paste configuration values from an unknown source.

Restarting the device can be useful if the operating system appears to have retained stale network settings, but it is best done after the simpler checks. If you restart, use the same test conditions afterward. Otherwise, it will be difficult to tell whether the restart, a server change, or another setting resolved the issue.

Run a repeatable troubleshooting test

For a practical diagnosis, keep the test small and repeatable. Pick one website or app that reliably showed the problem, and avoid switching targets while you compare settings. This makes it easier to separate a route problem from an issue affecting only one service. If the service has its own status page or reports an outage, check that independently rather than assuming the VPN is responsible.

1. Record the starting state. Note the device, network type, client, selected server, routing mode, and any custom DNS or proxy setting you know is enabled. Do not record or share passwords, account credentials, or a complete subscription link.
2. Test without the VPN. Confirm whether the chosen app or site works on the ordinary connection. If it does not, resolve the local network or destination issue first. If it does, note that the failure is associated with the VPN connection or its interaction with the destination.
3. Reconnect without changing other settings. Test again after reconnecting to the same server. If the failure remains, change only the server and repeat the test. This helps distinguish a server-specific problem from a device-wide setting.
4. Test routing and DNS separately. If changing servers did not help, review split tunneling or routing mode, then test. Next, review DNS and test again. Avoid changing both at once, because you may fix the issue without learning which setting caused it.
5. Compare a second network or device if available. A different network can reveal whether the first network blocks or disrupts a connection. A second device can show whether the issue is local to one operating system or client installation. Treat these comparisons as clues, not as a requirement to expose account details or install unfamiliar software.

When these checks point to DNS or routing, use the client’s documented settings rather than copying commands meant for a different operating system. Windows, macOS, Android, iOS, and Linux handle network interfaces and proxy settings differently. A setting that is appropriate for one client can leave another device without a working route.

If you are comparing service options while reviewing the connection requirements, the VPNQA Free VPN for China homepage provides a starting point for checking the service information. Use your own app and network tests to confirm whether a particular configuration suits the tasks you need to perform.

Understand DNS, routing, and protocol clues

When DNS is the likely cause

A DNS problem often looks like a domain-name failure: a browser may report that a site cannot be found, while the client still says it is connected. This does not prove DNS is the cause, because a destination can also be unavailable for other reasons. Compare more than one domain and check whether apps that use saved connections behave differently from apps that need to look up a new address. If only name resolution appears affected, review custom DNS settings and any DNS filtering or security app on the device.

Be careful with online “DNS fix” instructions that tell you to disable protections or use an unknown resolver. A DNS provider can see the domain names it resolves, and a resolver change can alter how requests are handled. Prefer the client’s supported defaults or documentation, and record the original setting before making a temporary change so you can restore it.

When split tunneling is the likely cause

Split tunneling, sometimes presented as per-app routing or rule-based routing, determines which traffic uses the proxy and which traffic goes directly through the local network. If one app fails but others work, check whether that app is excluded, assigned to a different route, or affected by a custom domain rule. A temporary full-tunnel test can help isolate the issue, but it should not replace reviewing the specific rule that caused the mismatch.

Also check whether the client is in system-proxy mode or a tunnel mode. System-proxy mode generally applies to apps that honor the operating system’s proxy settings; an app that ignores those settings may connect directly. Tunnel mode works at a different network layer, but its availability and behavior depend on the client and platform. “Connected” therefore does not mean that every app is using the same route.

When to change the server or protocol

If DNS and routing settings look correct, try a different server. A connection endpoint can be reachable while a particular route beyond it has trouble reaching a destination. If the service provides multiple supported protocols or transports, compare them one at a time on the same network and with the same test app. WireGuard is a VPN protocol; Shadowsocks, VMess, and Trojan are proxy protocols, while Hysteria2 is a protocol designed for proxy transport. The names describe different technical approaches, not a universal ranking of reliability or compatibility.

Network restrictions, client support, and service configuration affect which option works in a given situation. Keep the original configuration available, use only options supplied or documented by your service, and switch back if the alternative causes broader problems. A protocol change should not be treated as proof that the previous configuration was unsafe or that the new one will always be faster.

When to escalate and what to share

If the problem persists across multiple servers and networks, or if the client repeatedly disconnects while reporting no clear error, collect a concise set of diagnostic details before contacting support. Include the operating system, client name and version if known, the type of network, the selected server or region, the routing mode, and the exact error text. State whether the same app works with the VPN disconnected and whether another app is affected.

Do not include your password, payment details, private keys, or a full subscription URL in a public post or ordinary screenshot. Subscription links can contain account-specific information. If support needs a configuration detail, ask how to provide it safely. A cropped screenshot showing the status and error can be more useful than a full desktop image containing unrelated personal information.

Before reinstalling a client or resetting all network settings, check whether its configuration can be backed up and whether you can restore the current settings. Broad resets may remove working proxy rules, DNS preferences, or other network configurations unrelated to the VPN. If the issue began after a system update or network change, mention that timing; it may help support distinguish a client configuration problem from a change on the device or network.

• ✅ Confirm whether ordinary browsing works with the VPN disconnected.
• ✅ Test the same app after changing only one setting.
• ✅ Compare another supported server or network when available.
• ❌ Do not share account credentials or a complete subscription link.
• ❌ Do not leave firewall or security protections disabled as a workaround.

Most “connected but no internet” cases become easier to understand once you separate the local connection, the VPN route, and the destination app. Start with the local network, then reconnect, test another server, and inspect routing and DNS before changing protocol settings. If those steps do not isolate the problem, provide support with the test results and error details while keeping account secrets private.