VPN Connected but No Internet? Quick Fixes for Common Causes

A VPN client can show “Connected” while websites fail to load, apps report that they are offline, or only some traffic works. That status usually means a tunnel or proxy route was established; it does not prove that DNS, routing, the device’s local network, and the destination are all working together. Start with checks that are easy to reverse: test a second website, confirm the device still has ordinary network access, and inspect proxy or DNS settings before changing protocols. The steps below help narrow down the cause on Windows, macOS, Android, and iOS without treating every connection problem as a server fault.

Identify What Is and Is Not Working

Begin by testing more than one destination. Try a familiar website in a browser, then try an app that uses a different service. If one site fails but others load, the problem may be limited to that service, its browser session, or its own network restrictions. If all apps fail, focus on the device’s connection, the VPN route, DNS, or a system-wide proxy setting.

Check whether the same device can connect when the VPN is disconnected. If ordinary access also fails, reconnecting to another VPN server is unlikely to fix a Wi-Fi outage, a mobile-data problem, or a captive portal that still requires sign-in. If ordinary access works but internet access stops immediately after connecting, the VPN route, DNS configuration, or a conflicting network tool is more likely to be involved.

Note the exact scope of the failure before troubleshooting: does it affect every app, one browser, only domain names, or only traffic using a particular mode? Also record what changed recently, such as switching Wi-Fi networks, installing a security app, editing DNS settings, or importing a new subscription. These details help distinguish a configuration issue from a temporary network problem.

When a connection stops working, avoid changing several items at once. Switching servers, protocols, DNS providers, and routing modes together may restore access, but it hides the cause and makes a later recurrence harder to diagnose. A simple comparison—same device, same network, same destination, with the VPN on and off—provides a useful starting point.

Check DNS, Proxy, and Routing Settings

DNS translates a domain name into an address that a device can connect to. A VPN may be connected while the configured DNS resolver is unreachable, blocked by the current network, or inconsistent with the active routing mode. To test for a possible DNS issue, try loading a different domain and compare behavior in another browser or app. If services that use saved sessions appear to work but new domains do not, name resolution is worth checking; this pattern is a clue, not proof.

On Windows, open the client’s settings and check whether it manages DNS or installs a local proxy. If you recently changed DNS manually, note the current setting before restoring the device or client’s normal configuration. You can also open Command Prompt and run ipconfig /flushdns to clear the local DNS cache. This does not change the VPN server or repair an unavailable resolver, but it can remove stale cached results. On macOS, first disconnect and reconnect the VPN; if you are comfortable using Terminal, the system DNS cache can be refreshed with sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. A password prompt is normal for these administrative commands. Do not run commands copied from an unknown source.

Next, inspect proxy settings. Some clients use the operating system’s system proxy, while others create a tunnel interface or route traffic through a local service. A browser may also have a separate proxy extension or manually configured proxy. If a previous client was closed without restoring its settings, another application might still be pointing to a local proxy that is no longer running. Check the operating system and the affected browser, and disable only a setting you recognize and can restore. Avoid deleting unfamiliar profiles or certificates as a first step.

Routing mode matters too. Rule-based or split-tunnel modes intentionally send some destinations through the VPN and leave others on the direct connection. Global mode generally applies the proxy more broadly, while direct mode bypasses it. Names and behavior vary between clients, so consult the client’s own description rather than assuming every mode has identical rules. If only a subset of apps or destinations fails, temporarily compare with a broader routing mode if the client supports it, then restore your preferred rules after testing.

On Android, check whether another VPN-based application is active, including a firewall, ad blocker, or privacy tool. Android generally allows only one active VPN service at a time, and one app may replace or interfere with another. On iOS, review the VPN status and any installed VPN or device-management profiles; a profile may change DNS or route behavior. Do not remove a work or school profile without checking with its administrator. On desktop systems, security suites and local proxy tools can similarly affect routing or filter DNS requests.

Run a Controlled Troubleshooting Test

Use this sequence to isolate the problem without making unrelated changes. Keep a short note of each result, including the network you are using and whether the VPN is connected. If access returns after a step, repeat the original failing test before treating the issue as resolved.

1. Confirm the underlying network. Disconnect the VPN and open a couple of ordinary websites or apps. If they still fail, reconnect to Wi-Fi, check mobile data, or complete any network sign-in page first. Do not change the VPN configuration while the base connection is unavailable.
2. Reconnect cleanly. Disconnect from the VPN in its client, wait for the status to change, and connect again. If the operating system shows a separate VPN control, make sure it agrees with the client. Avoid force-quitting the client during a connection attempt, because that can leave a system proxy or tunnel in an unexpected state.
3. Compare destinations and applications. Test a known website in a browser and an unrelated app. If only one browser fails, temporarily disable its proxy extension or test a private window without changing the system-wide network settings. If all apps fail, continue with the route and network checks.
4. Check DNS and proxy configuration. Review the client’s DNS, system-proxy, and routing options. Restore a recent manual change only if you know what it was and can reverse it. On Windows, flushing the DNS cache may help with stale local records; on macOS, use the cache-refresh commands only if you are comfortable with Terminal.
5. Test one different server. Select another available route, reconnect, and repeat the same destination tests. This can help distinguish a route-specific issue from a device-wide configuration problem. Do not assume that a particular location is guaranteed to work with every network or website.
6. Compare a different network if possible. If the VPN works on mobile data but not on one Wi-Fi network, the Wi-Fi network, router, or its filtering may be involved. If the same problem follows the device across networks, focus on its client, DNS, proxy, and security settings.
7. Restore your normal setup. Re-enable any security or privacy feature you paused for testing, and return temporary routing or DNS changes to their previous values. Keep the configuration that resolved the issue only if you understand what it changes.

If you are choosing a travel setup or checking which client and supported route options fit your devices, the VPNMT VPN for China Travel overview is a useful place to review the service context. For the connection problem itself, however, keep the troubleshooting test focused on your current device, network, and client.

For an additional Windows cache check, open Command Prompt and enter ipconfig /flushdns. For macOS, the DNS cache refresh commands shown above require administrator authorization. These commands refresh local cache state; they do not reset the VPN account, alter a subscription, or prove that the VPN route is functioning.

Try Another Server or Protocol Carefully

A route can be reachable while still performing poorly on a particular network. If reconnecting does not help, test another server offered in your client and keep the device, network, destination, and routing mode unchanged. If the second route works, the issue may be specific to the original route or to how the current network handles it. If neither works, a local conflict or a broader network restriction remains possible.

Protocol selection can also affect compatibility. Shadowsocks, VMess, Trojan, and VLESS are proxy protocols; Hysteria2 is a QUIC-based protocol. WireGuard is a VPN protocol with a different operating model from many subscription-based proxy configurations. Do not assume that a client supports every protocol just because it can import a subscription link. The client must understand the subscription format and the protocol used by the selected configuration.

In clients such as Clash Verge, sing-box, and Shadowrocket, labels for profiles, groups, routes, and modes can differ. If the subscription provides multiple configurations, update it through the client’s supported subscription function and select only an entry that the client can use. Do not paste a subscription URL into a public website or send it in an unredacted screenshot: it can contain access credentials. When testing a protocol, change only that selection, reconnect, and repeat the same checks. If the client does not clearly expose a supported alternative, avoid editing raw configuration fields by guesswork.

Some networks restrict or interfere with particular connection patterns. A VPN that works on one Wi-Fi network but not another may be affected by router rules, network filtering, or a captive portal. A protocol change can sometimes help with compatibility, but it is not a general fix for a disconnected base network, incorrect DNS, or an inactive local proxy. Restore the original option if the test makes no difference.

• ✅ Compare VPN off and VPN on using the same device and destination.
• ✅ Test a different route while keeping the other settings unchanged.
• ✅ Check for another VPN, firewall, proxy, or network-filtering application.
• ❌ Do not edit unfamiliar DNS, certificate, or routing fields at random.
• ❌ Do not share passwords, subscription links, tokens, or unredacted QR codes.

Prepare Useful Details for Support

If the problem persists, gather enough information for someone to reproduce the failure without exposing account secrets. Record the device platform and version, the client name and version, whether the problem affects all apps or specific ones, and whether the VPN works on another network. Include the approximate time the issue began, what changed beforehand, the route label shown in the client, and any non-sensitive error message. A concise sequence of tests and results is more useful than saying only that the internet is broken.

Before sharing a screenshot or log, inspect it for usernames, passwords, subscription URLs, tokens, QR codes, and unrelated personal information. Redact those items while leaving relevant status messages and settings visible. Do not upload a full configuration file to an untrusted third-party site. If you are asked to provide a log, use the client’s documented export method and share it through the support channel you normally use.

Explain what you have already tried and what changed after each test. For example, say whether ordinary internet access worked with the VPN disconnected, whether another route changed the result, and whether the same device behaved differently on mobile data. This prevents repeated generic steps and helps distinguish a route issue from a local DNS or proxy conflict.

After service is restored, remove temporary exceptions and return security features to their normal state. Keep a note of the setting that resolved the problem, but avoid saving credentials or subscription links in that note. A connected indicator is useful, yet the final check is whether the applications you need can reach their destinations through the intended route.