A VPN client can report “Connected” while websites, apps, or even basic network checks fail to load. The status usually confirms that the client established a tunnel or proxy connection; it does not prove that DNS is resolving correctly, that your device is sending the affected app’s traffic through the right route, or that the destination is reachable. Start by checking whether the problem affects everything or only one app, then work through DNS, route selection, protocol, and device settings in order.
Change one thing at a time and test the same website or app after each change. This makes it easier to identify the cause and undo a setting that was not responsible.
Check the scope before changing settings
First, determine what “no internet” means on your device. Try opening more than one website and, if possible, a different app. A single site may be unavailable or may reject a particular exit route, while a browser problem can look like a device-wide outage. If every app fails while the VPN is connected, focus on the tunnel, DNS, system proxy, or local network settings.
Next, disconnect the VPN and try the same destinations over your normal connection. If they still fail, troubleshoot the Wi-Fi or mobile connection before changing VPN settings. If they load without the VPN but stop loading when it connects, the issue is more likely related to the selected route, the client’s traffic mode, or the device’s VPN configuration. This comparison is a diagnostic step, not a reason to leave an untrusted network unprotected.
- ✅ Test several unrelated sites or apps rather than relying on one destination.
- ✅ Compare the same destination with the VPN connected and disconnected.
- ✅ Check whether another device on the same Wi-Fi can get online.
- ❌ Do not assume the connection is fully working just because the client shows “Connected.”
- ❌ Avoid changing DNS, protocol, and firewall settings all at once; you will not know which change mattered.
Also note the pattern: does the failure begin immediately after connecting, happen only on one Wi-Fi network, or affect only one browser? A problem limited to one network can point to router restrictions or a captive portal. A problem limited to one app may instead be caused by that app’s proxy settings, a per-app VPN rule, or a connection that does not use the system VPN.
Check DNS and name resolution
DNS translates a website name into an address that a device can connect to. If DNS requests are blocked, sent to an unsuitable resolver, or left pointed at a network that is no longer reachable, a browser may report that it cannot find a site even though the VPN client is connected. Other apps may show a blank screen or keep loading because they cannot resolve their service hostnames.
Start with the least disruptive checks. Disconnect and reconnect the VPN, then fully close and reopen the affected app. If the client offers a DNS option, return it to the recommended or automatic setting before trying a custom resolver. A manually entered DNS address can be wrong for the current network or may not be reachable through the selected route. Do not copy an address from an unknown troubleshooting post simply because it worked for someone else.
On Windows, you can open Command Prompt and run ipconfig /flushdns to clear the local DNS cache, then reconnect and test again. On macOS, close the affected app and toggle the VPN connection first; DNS cache-clearing commands can vary with the system version, so use the appropriate instructions for your version rather than pasting an unfamiliar command. On Android, check whether Private DNS is set to a custom provider; if it is, temporarily switch to Automatic for a comparison. On iPhone, disconnect and reconnect the VPN and confirm that the active Wi-Fi or cellular connection itself is working before changing DNS-related profiles.
Some clients provide a DNS mode or a setting for routing DNS requests through the tunnel. If you change it, record the original setting and test only one alternative at a time. Avoid configuring both a custom system DNS address and a conflicting DNS option inside the VPN client. If changing the DNS setting makes the problem worse, restore the previous value and reconnect.
DNS is not the only possible cause of a browser error. A website can be unavailable, a browser can have its own secure-DNS setting, and a filtering or security application may intercept requests. Compare a browser with a different app and check whether the failure occurs on more than one destination before concluding that the VPN’s DNS is at fault.
Test a different route or protocol
A VPN route is a path between your device, the service’s network, and the destination. A particular route may be temporarily congested, blocked by the local network, or unsuitable for a specific service. If only selected destinations fail, try another available route or region that makes sense for your use. If all destinations fail, a route change is still a useful test, but also check the client and device settings below.
Disconnect before selecting a different route, then reconnect and allow the client to finish its connection attempt. Do not judge a route solely by its name or location. A nearby exit is not automatically the best choice, and a route’s label does not guarantee that every website or app will work through it. If the client has a route or server status view, treat it as a selection aid rather than proof that a destination is reachable from your current network.
If switching routes does not help, test another protocol only if the client actually offers that option. VPN protocols differ in how they establish and maintain a connection, and some Wi-Fi networks or firewalls may interfere with particular connection methods. Choose a protocol exposed by the official client or a compatible client you trust; do not paste in a configuration for an unrelated protocol. After each change, reconnect and test the same destinations.
It can also help to compare networks. If the VPN works on mobile data but not on a particular Wi-Fi network, that points toward a restriction or configuration on the Wi-Fi path. If it fails across networks, focus on the client configuration, route, or device-level VPN settings instead. VPNEdit provides routes in 120+ countries / 220+ routes, but coverage figures describe availability, not a guarantee that every route will work on every network or for every destination. For account access and service details, VPNEdit VPN with USDT Payment is available from the site’s homepage.
A step-by-step test you can follow
Use this sequence when you want to isolate the cause without resetting the entire device. Keep a note of the original client settings, especially if you are using a third-party client with manually imported profiles.
- Confirm the local connection. Disconnect the VPN briefly and check that the device can load more than one destination. If it cannot, reconnect to Wi-Fi or mobile data, complete any network sign-in page, and resolve the local connection first.
- Reconnect cleanly. Close the VPN connection from the client, wait for it to disconnect, and connect again. If the client offers a system-tray or background mode, make sure it is not still running another profile at the same time.
- Test the scope. Try a browser and a separate app. If just one app fails, check that app’s proxy, firewall, and per-app routing settings rather than changing the whole device’s DNS.
- Change one connection option. Select a different route, or test another protocol if the client supports it. Do not change both in the same test.
- Check DNS and proxy settings. Restore DNS to automatic or the client’s recommended mode, and confirm that the operating system is not pointing to an obsolete manual proxy.
- Restart and retest. Restart the affected app first. If the connection still fails, restart the device and repeat the same test before removing profiles or resetting network settings.
After each step, note whether all apps, only a browser, or only one destination changed. This distinction helps separate a device-wide routing issue from an app-specific setting or destination problem. If the VPN connects but a particular work application still cannot reach an internal service, ask the administrator whether that service requires a specific route or whether the VPN is intended to carry that traffic.
For a third-party client such as Clash Verge, sing-box, or Shadowrocket, also check that the active profile is current and that its mode matches your intended use. Rule-based mode can send different destinations through different paths; a rule may direct an app or domain outside the VPN, or to a route that is unavailable. Test with a simple, known-good profile or the client’s documented default mode if available, and preserve a copy of the original configuration before editing it.
Review device settings and restore safely
When a VPN is connected but traffic still fails, check whether another network tool is competing for control. A second VPN, proxy application, security filter, ad blocker, or firewall may install its own network extension or change system proxy settings. Close or temporarily disable one competing tool at a time, then retest. Do not leave security protections disabled as a permanent workaround; restore them after the comparison.
Windows
Check the VPN client’s traffic mode and confirm that the intended profile is active. If you use a manual proxy in Windows, review the proxy settings and remove only an entry you recognize as obsolete. A stale proxy can prevent browser traffic from reaching the internet even after the VPN tunnel is established. If an adapter or firewall rule was recently changed, revert that specific change rather than resetting all network components immediately.
Windows may also retain an old network state after switching between Wi-Fi networks. Disconnect the VPN, reconnect to the current network, then start the VPN again. If the problem appears only in one browser, check that browser’s proxy and secure-DNS settings before changing system-wide configuration.
macOS
On a Mac, another VPN app or network filter can conflict with the active VPN. Quit the other app fully and check the system’s VPN and network-filter entries for a profile you no longer use. If the VPN client asks for permission to add or use a network extension, confirm that the permission is enabled in macOS settings. The exact location and wording can vary by system version.
When changing from Ethernet to Wi-Fi or joining a different wireless network, disconnect and reconnect the VPN after the new connection is established. If only one application is affected, check its own proxy configuration and any content-filtering extension before removing the VPN profile.
Android and iPhone
On Android, inspect the system VPN settings for an old profile, an always-on VPN, or a “block connections without VPN” option. Those controls can intentionally prevent traffic when the configured VPN is unavailable, which may appear as a total loss of internet access. If you change one for testing, remember its original state and restore the protection setting afterward. Also check whether the VPN app is excluded from battery restrictions that may stop it in the background.
On iPhone, verify that the VPN profile belongs to the client you are using and that another VPN or security app is not active. If the connection works over one network but not another, compare Wi-Fi and cellular with the same route. Avoid deleting configuration profiles unless you know how to add them again; remove or reinstall a profile only after recording the relevant account and import details.
IPv6 and network resets
IPv6 handling can differ between the local network, the VPN client, and the destination. If the client documents an IPv6 option, use its supported setting and test it as a controlled comparison. Do not disable IPv6 across the operating system as a first response: that can affect other network functions and may not address the actual problem. Likewise, a full network reset can remove saved Wi-Fi networks, VPN profiles, and other settings, so reserve it for cases where simpler checks have failed and you can restore what the reset removes.
If the issue continues, record the operating system, client name and version, whether it affects all apps or selected destinations, which network you tested, and which route or protocol changes you tried. Share only the diagnostic details needed for support. Remove passwords, subscription links, QR codes, and account credentials from screenshots or logs before sending them.