A VPN client can show “Connected” while websites, messaging apps, or other services still fail to load. That status usually confirms that the client has established a tunnel; it does not prove that your device has working DNS, a usable default route, or permission to send every app’s traffic through that tunnel. The problem may be on the device, in the selected route, or in the network you are using.

Work through the checks below in order. Start with a simple comparison, then inspect DNS and routing, test a different server or protocol, and finally look for conflicting proxy or security settings. Change one thing at a time and retest the same app or website after each change. This makes it easier to identify the cause and restore any setting that was not involved.

Separate a VPN problem from a network outage

First, leave the VPN connected and try more than one kind of internet activity. Open a familiar website, refresh an app that uses a different service, and see whether a new page loads in a browser. If only one website or app fails, the VPN may be working normally while that particular service, app, or destination is having trouble. If nothing can connect, continue with the system-level checks.

Next, disconnect the VPN and repeat the same tests. If the device still cannot reach the internet, investigate the local connection before changing VPN settings. Confirm that Wi-Fi or mobile data is enabled, check whether the device shows an internet connection rather than only a connection to a router, and try loading a page on another device using the same access network. A router, captive portal, mobile-data restriction, or temporary service interruption can prevent internet access regardless of the VPN.

If the internet works without the VPN but stops as soon as the tunnel connects, the VPN path or a setting applied by the client becomes more likely. Do not assume that the server is at fault yet. The tunnel can be established even when a DNS resolver is unreachable, an application is excluded by split tunneling, or the operating system has retained a conflicting route from another network tool.

Compare

Test the same apps with the VPN connected and disconnected.

Isolate

Check whether one destination or all internet traffic is affected.

Retest

Change one setting at a time and repeat the same test.

Also check for a sign-in page on public Wi-Fi. Some networks require you to accept terms or authenticate before allowing general internet access. Disconnect the VPN briefly, open the network’s sign-in page if one appears, complete the required steps, and reconnect. If the network blocks VPN traffic, the client may remain in a connecting or apparently connected state without providing usable access. Try another trusted network to determine whether the issue is specific to that access point.

On a phone, confirm that the affected app is allowed to use mobile data and is not restricted by a data-saving mode. On a computer, check whether the connection itself has changed, such as moving between Wi-Fi and Ethernet. A network transition can leave the tunnel active while its previous route is no longer valid.

Key takeaway: If internet access fails with and without the VPN, fix the underlying network first. If it fails only when the VPN is connected, continue by checking DNS, routing, and client settings.

Check DNS and device routing

DNS translates a website name into an address that a device can contact. A tunnel may be active while DNS requests are sent to a resolver that is unavailable, blocked by the current network, or inconsistent with the VPN’s configuration. This can make websites appear offline even when the device has a working route to other destinations. It is also possible for different apps to behave differently because they use different DNS mechanisms or retain cached results.

Begin with low-risk steps. Disconnect and reconnect the VPN, then fully close and reopen the affected app. If the issue continues, toggle the device’s network connection off and back on. On a computer, restarting the browser can clear a stale connection held by that application. On a phone, briefly enabling and disabling airplane mode can refresh the local network connection; reconnect to Wi-Fi or mobile data before testing again.

Review any custom DNS configuration on the device and in the VPN client. Examples include a manually entered DNS server, Android Private DNS, encrypted DNS in a browser, or a DNS profile installed by another app. Temporarily return only the relevant setting to automatic or the client’s recommended default, then reconnect and test. Avoid changing several DNS settings at once, because it becomes difficult to tell which change affected the result.

Do not use a single failed ping or an address typed into a browser as definitive proof that routing is broken. Some networks block diagnostic traffic, and many websites do not serve a page when opened by a raw IP address. Instead, compare several ordinary destinations and, if you are comfortable with system tools, check whether a domain name resolves using the DNS troubleshooting method appropriate for your operating system. A name-resolution failure points toward DNS; successful resolution followed by failed connections may indicate routing, filtering, or a destination-side issue.

Routing determines where traffic goes after DNS has done its work. In a VPN client, modes such as rule-based routing, global routing, or split tunneling can send different apps or destinations along different paths. A rule may direct a browser outside the tunnel while another app uses it, or a recent configuration change may exclude the app you are testing. Check the active mode and review whether the affected app or destination is included in a bypass or exclusion list.

  • ✅ Reconnect the VPN after a Wi-Fi, Ethernet, or mobile-network change.
  • ✅ Review custom DNS, Private DNS, browser DNS, and client DNS options one at a time.
  • ✅ Check split-tunnel and routing rules for the app or destination that cannot connect.
  • ❌ Do not permanently disable DNS protection or route protection just to make one test pass.

On Windows, a DNS cache refresh can help when a computer keeps using an old lookup result, but it cannot repair a missing route or an unreachable resolver. On macOS, restarting the affected application and reconnecting the network are reasonable first checks; DNS cache procedures vary by system version. On iOS and Android, reconnecting the network or restarting the device is usually a simpler first diagnostic than entering unfamiliar terminal commands. If a change does not help, restore the original setting before proceeding.

Follow a safe retest sequence

Use the following sequence in the middle of troubleshooting. It is designed to limit unnecessary changes and to show whether the failure follows the network, the app, or the VPN configuration. Keep a short note of what you changed and whether the same test began working. That record is especially useful if you later need to compare a different server or ask the service provider for help.

  1. Choose a repeatable test. Select one browser page and one unrelated app that normally use the internet. Avoid relying on a single website, since a site can be unavailable independently of your connection.
  2. Check the local network. Disconnect the VPN and confirm that the chosen test works. If it does not, reconnect to Wi-Fi or mobile data, complete any network sign-in, and resolve the local outage before continuing.
  3. Reconnect cleanly. Turn the VPN off, wait for the client to show that it is disconnected, and connect again. If you recently changed networks, reconnect to that network first. Retest both the browser and the app.
  4. Inspect DNS and routing. Review custom DNS and the client’s routing mode. Check whether split tunneling, per-app routing, or a bypass rule affects the test app. Change only one relevant setting, reconnect, and repeat the same tests.
  5. Try another server or protocol. Select another available server, or choose a different protocol if the client offers one. Do not change the server, protocol, DNS, and routing rules all at once; doing so may restore access without revealing what caused the failure.
  6. Restore unrelated settings. If a test has no effect, put the changed setting back as it was. This avoids leaving behind an unnecessary exception or a less secure configuration.

Keep the test consistent. If the first attempt uses one app on Wi-Fi and the next uses a different app on mobile data, the outcomes cannot be compared reliably. For a computer, keep the same network adapter active during each comparison. For a phone, note whether the test uses Wi-Fi or cellular data, and check that the app is permitted to use that connection.

Restarting the device can help after a network transition or a change to system-level routing. It is not necessary after every failed page load, but it can clear a stale adapter or network state that survives a client reconnect. Save work first, restart only after the simpler checks, and then connect the VPN before repeating the same test.

Test a different server or protocol

A selected server may be temporarily unreachable from your current network, or the route between that network and the server may be having a problem. The client can sometimes complete part of the connection process while user traffic remains unusable. Disconnect, select a different available server, reconnect, and repeat the same test. If that works, the original route may have been the issue; it does not necessarily mean that the device’s DNS settings were wrong.

If changing servers does not help, try another protocol supported by the client and service. Protocols use different connection methods and can behave differently under restrictive Wi-Fi, mobile networks, or other network policies. A protocol change is a diagnostic comparison, not a universal speed or reliability guarantee. Choose options exposed by the official client or a compatible client configured with the service’s supported settings; do not copy arbitrary ports or protocol parameters from unrelated guides.

When a server or protocol change restores access, record the combination that worked and reconnect using it. If the same issue returns on the original combination, compare again later rather than repeatedly changing unrelated operating-system settings. A temporary route problem and a persistent local configuration conflict require different remedies.

For third-party clients, verify that the subscription or configuration has updated successfully and that the selected profile is current. An imported configuration can contain several server entries, but a successful import does not mean every entry is reachable from every network. Confirm that the client is using the intended profile, that its mode is appropriate, and that no outdated local override changes DNS or routing.

If every server and available protocol behaves the same on one network but works on another, the access network may be filtering or interrupting VPN traffic. Check the network’s usage rules or test on a different connection you are allowed to use. Avoid repeatedly forcing connections or editing undocumented configuration values: those changes can obscure the original cause and may break unrelated traffic.

Key takeaway: Change the server first, then compare a supported protocol if needed. A successful alternative is useful evidence, but it does not by itself identify whether the original problem was temporary or configuration-related.

Remove proxy conflicts and know when to escalate

A separate proxy can conflict with a VPN by sending application traffic to an address that is no longer reachable, or by overriding the route the VPN client expects to use. Look for manually configured system proxies, browser proxy extensions, local debugging proxies, and proxy settings in individual apps. If you recognize a proxy that you intentionally use, note its current configuration before testing without it. Do not remove settings you do not understand on a managed work or school device.

Check for other network tools that can change DNS, routes, or filtering behavior. Examples include another VPN client, a firewall utility, an endpoint-security product, a traffic-capture tool, or a custom DNS application. Two tools may both be active even when only one appears to be connected. Close or pause only tools you recognize and are allowed to control, then reconnect the VPN and retest. On a managed device, contact the administrator rather than overriding policy.

Review the VPN client’s logs or connection details if the basic checks do not resolve the problem. Look for repeated DNS errors, route-configuration warnings, failed reconnects, or messages showing that the tunnel was closed after the client reported a connection. A log entry is a clue rather than a complete diagnosis: note the time, network type, selected server, protocol, and exact app behavior. Remove usernames, subscription links, access tokens, and other private information before sharing diagnostic material.

If only one app is affected, inspect its own proxy, network-permission, and data-use settings before resetting the whole device’s network configuration. If every app fails only with the VPN connected, include the client’s selected routing mode and DNS settings in your notes. If the issue happens only on one Wi-Fi network, mention that comparison as well. Clear, reproducible details are more useful than a screenshot showing only “Connected.”

Use a full network reset only as a last resort. Depending on the operating system, it may remove saved Wi-Fi networks, custom DNS, VPN profiles, or other connection preferences. Before resetting, record settings you need to restore and check whether a simpler client reconnect or device restart resolves the issue. After a reset, install or configure only the network tools you actually use, then test the VPN before restoring optional proxy or DNS customizations.

  • ✅ Review system and browser proxy settings for a proxy you no longer use.
  • ✅ Check for another active VPN, firewall, or DNS tool that can change routes.
  • ✅ Save relevant client logs and record the network, server, protocol, and affected apps.
  • ❌ Do not share subscription links, authentication tokens, or unredacted private logs.
  • ❌ Do not reset all network settings before recording configurations you may need.

In short, a connected indicator describes the tunnel state, not the complete health of internet access. Compare the connection with and without the VPN, verify DNS and routing, test another server or supported protocol, and check for proxy conflicts. Make changes gradually, keep security protections enabled whenever possible, and restore any diagnostic setting that did not help. This approach narrows the cause without turning a single connectivity problem into a larger configuration problem.