Internet Works Only With the VPN App On? Check Four Layers

You try a free VPN client or a browser extension for a week, switch it off, and the internet stops. The Wi-Fi icon still shows a connection, other devices on the same router are fine, and the only things that bring browsing back are re-enabling the app or uninstalling it. That pattern is not encryption creating a dependency. It is configuration the app wrote somewhere the tunnel does not own.

The client edits settings the tunnel does not own

A privacy client on Windows or macOS usually touches three places at once. It sets the system HTTP proxy, which is the same field Internet Options exposes. It installs a virtual adapter, often a TAP driver, so it can capture packets. And it rewrites the resolver list, while only the tunnel disappears when you press disconnect.

A browser extension is a narrower thing. It normally changes its own profile or the proxy that one browser follows. That is why a single browser can fail while command-line tools keep working, or the reverse: the extension never had the authority to touch the other layers. Which layer it edited decides which tools break.

Either way, the stale decision was made by software that had no reason to undo it. The tunnel was the visible part, and it was also the only part with a clean shutdown path. Everything else is a setting in a store that outlives the process, so removing the app is the one step that reverses all three at once. Reading those stores before reinstalling anything is what turns the symptom into a diagnosis.

Three leftovers, three different failures

The first leftover is a proxy that points at nothing: the LAN proxy box still ticked, or a configuration script URL aimed at a localhost port where no process is listening any more. The browser forwards every request to that dead port and stalls until the timeout looks like a dead network. The second is an adapter that still owns a default route, because a TAP-Windows device or a vendor routing driver remains a real interface after an uninstall. It keeps the route it was given, and traffic disappears into a tunnel that is not there. Neither leftover announces itself; both look exactly like an outage.

The third is DNS, and it fails earlier than the other two. If the resolver list contains only servers reachable through the tunnel, every lookup times out before a single page is requested, so the browser reports an unreachable site rather than a dead proxy. Whichever one you have, none of them is an outage in the network sense. Each is a leftover nobody revoked, and each is repaired in a different place.

Work down the four layers

Start closest to the application and work down, because the layers fail in that order of visibility. Change one layer per test, and retest after each one. Resetting everything at once usually restores browsing, and it leaves you unable to say which leftover caused it, so the next install recreates the same puzzle. The order is proxy, adapters, routes, resolvers.

On Windows each check is a single command that ships with the operating system, so nothing needs installing. Run them in order and keep the output together, because the four answers only make sense side by side. They report the proxy, the adapters, the IPv4 routes and the resolver list, in that order:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux and macOS need their own commands, and they are not interchangeable. On Linux the routes come from ip route and the resolver from resolvectl status where systemd-resolved owns it, falling back to cat /etc/resolv.conf. On macOS the routes come from netstat -rn, the resolvers from scutil --dns, and the system proxy from scutil --proxy. A macOS reader who runs ip route gets command not found, and /etc/resolv.conf there is a generated stub rather than the authoritative configuration. Check the platform before you check the layer, or the first command becomes the finding.

For each layer ask one question: does this value still point at something that exists while the app is closed? A proxy at a dead port, an adapter with no tunnel, a default route through a down interface and a resolver inside the tunnel all answer no. Any single no is enough to explain the symptom, which is why one change per test matters.

A proxy is not a tunnel

A proxy accepts a request, fetches it elsewhere and hands back the response, which means it knows the destination and sees anything the site did not encrypt itself. It does not carry other protocols. It does not protect the path unless the destination already uses TLS. And it can be changed by whatever installed it, without your involvement.

That distinction changes the question worth asking. When a proxy remains behind, find out which program still steers your browser rather than whether the tunnel is up. The tunnel may be perfectly healthy and entirely irrelevant to the failure.

If you want to know what such a client actually did, observe it instead of reading its dashboard. Process Monitor records which registry keys and files it touches, while a packet capture reveals where its traffic went. Both are ordinary tools, and both answer the leftover question better than any status light. Neither requires the app to still be running.

Remove the component, not the evidence

The durable fix is to remove the thing that wrote the setting. Uninstall the app, delete the virtual adapter it added, clear the proxy and the resolver list, then reboot and test with the app still uninstalled. If browsing works at that point, you have found the cause rather than a workaround. Keep a note of which layer was stale, because the same vendor tends to ship the same mistake twice.

If the symptom comes back after you install the next client, walk the four layers again before deciding that the service broke something. The evidence is usually still there, in one of the four places. A second app does not create a fifth layer; it edits one of the four.

Reinstalling resets the proxy but not a stale adapter, and it may leave two resolvers in the list. That asymmetry is why uninstall-then-test beats a reset-everything button. It also gives you a baseline to compare against the next time the connection drops.