Is this a fault, or the kill switch doing its job?
If your internet stops the moment the VPN connects, or cuts out mid-session and does not come back, the most likely explanation is not a broken app. It is the kill switch, doing exactly what it was built to do. That is the answer for the large majority of people who search for this, and it is worth sitting with before you start changing settings.
A kill switch blocks all internet traffic when the VPN tunnel drops, rather than letting your connection quietly fall back to your ordinary line. That fallback is the thing it exists to prevent: without it, the seconds after a tunnel drops go out over your normal connection with your real address attached, and you would never notice. So when the tunnel is unstable — on a weak signal, during a server restart, at the moment you change networks — the switch fences everything off, and from where you are sitting that is indistinguishable from the internet being dead.
This is the trap. A stranded kill switch and a genuinely dead connection look identical from the browser. The one-line test that separates them is to disconnect or quit the VPN fully, not to fiddle with the browser. If the internet comes straight back once the VPN is off, nothing is broken — the switch caught a dropped tunnel and did precisely what you paid for.
What the VPN kill switch actually does when the tunnel drops
Tunnels drop. They drop on network changes, on suspend and resume, on server reboots, and on a mobile signal that fades in a lift or a tunnel. These are not defects; they are ordinary events in the life of a connection. The question a kill switch answers is what happens in the gap between the tunnel failing and the client noticing and rebuilding it. Without a switch, traffic in that gap leaves unprotected. With one, it stops.
The distinction that decides whether a kill switch is worth anything is between an application-level switch and a firewall-level one. An app-level switch relies on the VPN application still running to notice the tunnel has failed and pull traffic. If the app itself crashes — which is exactly the kind of failure you want covered — an app-level switch crashes with it and stops protecting anything. A firewall-level switch installs rules in the operating system that block traffic even if the app dies, so the protection outlives the process. That is the version you actually need, and the two are often not distinguished in the marketing.
You cannot tell which kind you have by reading the settings screen, but you can test it, and almost nobody does. The correct test is to kill the VPN process from the task manager or with a kill command, not to click disconnect. A graceful disconnect is not the failure mode you are worried about; every implementation handles that cleanly. Start a continuous download or a ping to a remote host, terminate the process, and watch. If traffic keeps flowing, the switch is app-level and depended on the app it just lost. If traffic stops dead, the switch is enforced below the app and survived it.
- Click disconnect: every kill switch handles this, so it proves nothing
- Kill the VPN process: this is the real test, and app-level switches fail it
- Traffic keeps flowing after the process dies: app-level, weaker than advertised
- Traffic stops dead: firewall-level, the behaviour you want
Why is traffic still blocked after I quit the app?
The flip side of a firewall-level switch is the complaint that fills support forums: the VPN is closed, sometimes uninstalled, and there is still no internet. This is the same mechanism seen from the other direction. The switch installed firewall rules to fence off traffic when the tunnel dropped, and if the app crashed or was force-quit before it could tidy up, those rules are still in place with nothing left to remove them.
The fix is almost always to give the app its tunnel back or to let it clean up properly. Reopen the client and reconnect, which re-establishes the tunnel the rules are waiting for; or open it and toggle the kill switch off deliberately, which removes the rules in an orderly way. If the client will not launch, restarting it usually clears the stranded state on startup, and a reboot is the blunt last resort that always works because the firewall rules do not persist across one.
What you should not do is treat a stranded switch as a reason to leave the kill switch off for good. That trades away the exact protection you bought to avoid a one-minute inconvenience you now know how to clear in seconds.
Avoid
- Turning the kill switch off permanently to "fix" a drop — that removes the protection, not the fault
- Uninstalling the client while it is stranded, which can leave the firewall rules behind with no app to clear them
- Assuming no internet means a dead line before you have quit the VPN and checked
Is an always-on VPN stronger than blocking connections without one?
People searching for "block connections without VPN" and people searching for an always-on setting are usually after the same thing: a guarantee that nothing leaves the device unless the tunnel is up. It is worth knowing that the in-app kill switch and the operating system’s own setting are not the same control, and the OS one is stronger because it does not depend on the VPN application at all.
On Android this is a native setting: always-on VPN with a block-connections-without-VPN option, enforced by the system rather than by the app, so it holds even if the app crashes. It is the single most useful toggle on mobile and it is off by default. On iOS there is no equivalent switch in ordinary settings — the always-on behaviour requires a configuration profile or a supervised device, so most iPhone users are relying on the app’s own on-demand rules, which are weaker. That gap is worth knowing before you assume an iPhone is fenced off the way an Android phone can be.
On the desktop the equivalent is a permanent kill-switch mode, where some clients block traffic before the app has even started rather than only after it has connected once. That closes the window at boot, when a device can otherwise send a burst of traffic — update checks, sync, telemetry — in the seconds before the VPN client loads. If that window matters to you, the permanent mode is the setting to find, and not every provider offers it.
Connected but no internet at all — is it DNS or IPv6?
The other common version of "I lose internet on the VPN" is different from a kill switch entirely: the client says connected, the tunnel is genuinely up, and yet nothing loads. This is usually not the switch. It is name resolution failing, and it looks like a dead connection because without DNS nothing resolves to an address to connect to.
Test it by loading a site by its raw numeric address rather than its name. If that works and the named site does not, the tunnel is carrying traffic fine and DNS is the fault. The usual fixes are to switch protocol, to toggle the provider’s own DNS or ad-blocking DNS feature off, or to flush the local resolver cache. A provider that runs its own resolvers on the same servers as the tunnel exit is the structural answer here; one that hands you a third-party resolver has moved the problem rather than solved it.
IPv6 is the other culprit, and it is invisible unless you look for it. If your connection has IPv6 but the client configures only the IPv4 route and leaves IPv6 to the operating system, some lookups head out over a path the tunnel never covered and simply go nowhere. There are two acceptable client behaviours: carry IPv6 inside the tunnel, or block it entirely at the interface. Ignoring it is the failure. Check the client for an IPv6 setting before assuming the connection is broken. If small pages load but large transfers hang, the cause is more likely MTU — tunnelled packets carry extra overhead, and oversized ones get dropped silently — which is a separate fault worth chasing on the connection guide rather than here.
What the VPN kill switch will not do
A kill switch is a narrow tool, and it is oversold. It stops traffic when the tunnel drops. That is the whole of it. It does not make you anonymous, it does not encrypt anything a running tunnel was not already encrypting, and it does nothing about the identifiers — cookies, logins, fingerprints — that work above the network layer regardless of your address.
It also does not cover what you have deliberately routed around it. Every application you exclude through split tunnelling is outside the switch as well as outside the tunnel, and an exclusion added to fix one banking login two years ago is still there, still leaking, still forgotten. A kill switch and a split-tunnelling exclusion list are pulling in opposite directions, and the exclusion wins for anything on it.
And it does not close a leak that already has its own path. A WebRTC request or a stray IPv6 route exposes your real address through a channel the kill switch was never watching, because that traffic is not "falling back" — it is leaving through a door that was open the whole time. The switch guards the moment the tunnel fails; it does not audit the routes that were misconfigured while the tunnel was up. That is why testing for leaks is a separate exercise from testing the switch.
How the four providers we cover handle the kill switch
All four providers in our dataset advertise a kill switch. That word does the same marketing work on every site, so it is worth being specific about what each one actually ships and how far it is documented, because that is where the four separate.
Proton VPN carries a kill switch across every platform, and on desktop it offers a permanent mode that blocks traffic before the app even starts — the boot-window case above. That, with leak handling on all platforms, is why it scores nine of ten on leak protection in our rubric. NordVPN runs a kill switch on all its desktop and mobile apps, resolves DNS inside the tunnel, and operates a RAM-only server fleet so nothing about a session survives a reboot; it also scores nine on leak protection, for a different combination of reasons.
PureVPN is where the coverage narrows: its kill switch is present on desktop and Android only, and there is no RAM-only server fleet behind it, which is why it sits at seven rather than nine. FastestVPN is the cautionary case. It advertises a kill switch like the others, but its leak behaviour is not documented publicly by any independent party — nobody outside the company has confirmed what the switch does when a tunnel actually drops. That absence of evidence, not a proven failure, is why it scores five, the lowest of the four. The lesson generalises past these four: an advertised kill switch is a claim, and the only way to turn a claim into a fact is the process test above — kill the tunnel and watch, because that is the one thing the marketing page cannot do for you.