VPN Kill Switch Explained: What It Actually Blocks (2026)

A VPN kill switch is supposed to do one simple thing: if your VPN connection drops, cut your internet access entirely rather than let your device quietly fall back to your unprotected regular connection. It sounds like a binary, always-works feature — either your traffic is blocked or it isn’t. It isn’t that simple: independent lab testing as recent as this year found that 19 of 20 tested VPNs leaked traffic in at least one failure scenario, most often after a simple system reboot — a reason to take the checkbox in your VPN’s feature list less on faith than most people do.

What a Kill Switch Is Actually Blocking

The failure a kill switch exists to prevent is specific: your VPN tunnel drops — the app crashes, the server goes down, your Wi-Fi hiccups and reconnects to a different network — and your operating system, which doesn’t know or care that you wanted your traffic encrypted, just routes new connections through whatever network interface is available. Without a kill switch, that fallback happens silently. Your browser keeps loading pages, your torrent client keeps seeding, and none of it goes through the VPN anymore — with no on-screen warning that anything changed.

A kill switch prevents that fallback by installing firewall-level rules that block all non-VPN traffic outright rather than trying to reconnect the tunnel first. The distinction that matters here is where those rules live. A system-level kill switch is enforced by the operating system’s own firewall (Windows Filtering Platform, macOS’s packet filter, Linux’s iptables) — the block holds even if the VPN app itself has crashed or isn’t running. An app-level kill switch is enforced by the VPN application’s own process instead, which means it depends on that process still running to keep blocking traffic — if the app itself crashes, gets killed by the OS to free memory, or simply hasn’t finished launching yet, the block it was supposed to enforce can go with it.

Why the Same Feature Name Means Different Things

Every VPN in this site’s reviews ships something called a kill switch. What that word covers varies enough between providers that treating it as one interchangeable checkbox is a mistake:

Always-on versus opt-in. Mullvad’s kill switch can’t be turned off from the app’s settings at all — it’s a permanent property of the connection, not a toggle a user might accidentally leave unchecked. Contrast that with NordVPN, where the Windows app splits the feature into a separate “Internet Kill Switch” and an opt-in “App Kill Switch” — two different settings, not one, and neither is guaranteed to be on by default the way it is on iOS and the macOS App Store version of the same app. A feature that has to be found and manually enabled protects nobody who didn’t know to look for it.

System-level versus app-level, sometimes both at once. hide.me’s “Stealth Guard” explicitly offers a system-wide mode alongside a narrower per-app mode, giving the user the choice depending on whether they want their whole device locked down or just specific applications. Astrill goes further with “App Guard,” a dedicated Windows-only enhancement layered on top of its standard kill switch for granular per-application control — but App Guard doesn’t work at all with Astrill’s own OpenWeb protocol, and has no iOS or Android equivalent whatsoever. A feature that only covers some protocols on some platforms isn’t a universal safety net; it’s a safety net with specific, documented holes, and those holes are exactly where a user is most likely to assume they’re covered.

Consistency across platforms, or the lack of it. TunnelBear’s GhostBear obfuscation mode — a related but distinct feature from its VigilantBear kill switch — works on Windows, the older macOS v4 app, and Android, but not iOS at all. NordVPN’s split tunneling behaves differently on every platform: full app-based exclusion on Windows and Android, a different port-based “Allowlist” system on Linux, and no split-tunneling option at all on macOS or iOS. None of this means these providers are being dishonest — it reflects real constraints in what each mobile OS actually allows a third-party app to do at the network level. But it does mean a review that says “has a kill switch” without specifying which platform, which protocol, and which mode is giving an incomplete answer.

What Independent Testing Actually Found

The most current answer comes from RTINGS.com, a lab testing outlet that bought and tested 20 VPN services on a Windows 11 machine, capturing all traffic on a mirrored network port with Wireshark rather than trusting what each VPN’s own app reported. Their methodology, last updated April 2026, forced three separate failure scenarios: killing the VPN’s process, physically cutting the internet connection, and rebooting the operating system entirely. Only one provider, Perfect Privacy, produced zero leaks across all three scenarios. Four more — Mullvad, Proton VPN, IVPN, and AirVPN — held up against a process crash and a connection loss but still leaked during a full system reboot, the hardest of the three scenarios. Every other tested provider leaked in at least one scenario, and the reboot case in particular exposed a structural race condition: Windows brings its network interface online before most VPN clients have had a chance to re-engage their kill switch, so traffic — often a DNS query or an unprompted check-in to Microsoft’s own servers — slips out in the gap before the VPN catches up.

The same structural problem showed up earlier, at larger scale, in peer-reviewed academic research. In 2022, researchers Reethika Ramesh, Leonid Evdokimov, Diwen Xue, and Roya Ensafi at the University of Michigan published “VPNInspector: Systematic Investigation of the VPN Ecosystem” at NDSS, one of the field’s top security conferences, after testing 80 desktop VPN applications. Their findings on tunnel-failure behavior: traffic leaked during a tunnel failure in 26 of the providers tested, DNS queries specifically leaked during tunnel failure in 8, and IPv6 traffic leaked directly to the user’s ISP in 5 — all separate from any kill switch setting, simply describing what happens when the tunnel goes down with no dedicated protection engaged at all. The number that matters most for anyone relying on a kill switch specifically: 10 of the tested providers leaked traffic even in their most secure configuration, and 6 of those leaked data with a kill switch feature turned on. The paper doesn’t publish which six providers, so this article isn’t naming names it can’t verify. This is a 2022 dataset, not re-tested at this scale since — but four years and one much smaller, differently-scoped test later, the RTINGS results above show the same underlying gap never actually closed.

When a Provider Found Out the Hard Way

IVPN’s own account of what happened to its iOS kill switch is a useful case study precisely because it’s self-reported. IVPN added a kill switch to its iOS app in November 2021, built on Apple’s includeAllNetworks API — the mechanism Apple provides specifically so a VPN app can force all device traffic, not just app-specific traffic, through its tunnel. That API had a known limitation even at launch: a separate iOS bug meant it couldn’t be implemented without gaps for the IKEv2 protocol, so IVPN’s kill switch only covered WireGuard and OpenVPN connections from day one.

Then, in August 2023, IVPN discovered something worse than a known gap: on iOS 16.1 and later, includeAllNetworks silently stopped fully doing its job. Traffic to specific Apple services — Apple Maps, Apple Push Notifications — could bypass the VPN tunnel entirely and reach Apple’s servers carrying the device’s real IP address, even with the kill switch switched on. IVPN’s response was to remove the iOS kill switch feature outright rather than continue shipping something that could give users a false sense of protection, and to file a bug report with Apple. As of this article, IVPN’s own knowledge base still states plainly that the kill switch isn’t available on iOS 16 or later — the removal wasn’t a temporary patch-in-progress footnote, it’s been the status for roughly three years.

This isn’t a story about IVPN being worse at building a kill switch than anyone else — if anything, choosing to pull a leaking feature rather than leave it listed as a working safeguard is the opposite of what a marketing-first vendor would do. It’s a story about the platform underneath every VPN app imposing constraints that no amount of provider effort fully closes, and about how a feature can pass every test on release day and still develop a hole two OS versions later that nobody notices until someone goes looking.

How to Actually Check Yours

None of this means kill switches are useless — the mechanism is sound, and the alternative (silent fallback to your unprotected connection with no warning) is worse in every case. It means the checkbox in a settings menu isn’t proof of anything by itself, and the lab results above show exactly which scenario is most likely to expose that gap. A few things worth doing instead of assuming:

Find out whether yours is system-level or app-level, and whether it’s on by default or something you have to enable — check your provider’s own support documentation rather than assuming, since as shown above this varies by platform even within the same provider.

Test it directly, including a reboot. Connect to your VPN, start a continuous ping or a page-load loop to confirm you’re online, then force the tunnel down — disable your network adapter, or kill the VPN app’s process if you’re testing the system-level claim specifically — and watch whether your traffic actually stops rather than silently continuing over your normal connection. Don’t stop at a simple disconnect test: as the RTINGS results above show, a reboot is where most kill switches actually fail, since your operating system typically brings its network connection online before your VPN app has re-launched and re-engaged. If you rely on your kill switch for anything sensitive, set your VPN app to launch automatically on startup rather than assuming it’ll catch up in time.

Check the specific gaps that apply to your platform. iOS users relying on a kill switch should know which VPNs currently support it there at all and which protocols it covers, given the IKEv2 limitation and the Apple-services gap documented above aren’t unique to one provider’s implementation — they’re consequences of what Apple’s own VPN APIs currently allow. Anyone layering split tunneling on top of a kill switch should confirm the two features are compatible on their specific OS, since — as shown above — split tunneling support itself varies by platform even within a single provider’s app.

A kill switch that’s actually system-level, actually on, and actually tested by you — through a reboot, not just a simple disconnect — is a meaningfully different thing from a kill switch that’s merely listed as a feature. The gap between those two is exactly what RTINGS’ 2025-2026 lab testing and the earlier 2022 academic research both measured, and exactly what IVPN’s own incident shows can open up on a platform a provider doesn’t fully control.