VPN Kill Switch Test

A VPN kill switch is a safety mechanism that blocks all internet traffic the moment your VPN connection drops. Without one, your device does something you never see: it silently falls back to the raw, unprotected connection and keeps transmitting. Every app with an open connection — your browser, your torrent client, your sync tools — carries on as if nothing happened, except now every packet carries your real IP address and your DNS queries go straight to your ISP.

VPN tunnels drop for completely ordinary reasons: your laptop wakes from sleep, your phone hops from WiFi to cellular, the WiFi signal dips for a few seconds, the VPN server undergoes maintenance, or a hotel network aggressively filters traffic. Each drop opens a gap that lasts anywhere from a couple of seconds to several minutes. The kill switch's entire job is to make sure that during that gap, nothing leaves your device outside the encrypted tunnel.

The problem is that a kill switch is a failure-mode feature: you only find out whether it works at the exact moment you need it. Most people enable the toggle, see nothing change, and assume they're covered. The tool above exists so you can trigger the failure deliberately — under controlled conditions, watching in real time — instead of discovering the answer during a real drop you never noticed.

The monitor sends a request to our own IP endpoint every 2 seconds and timestamps the answer. The first successful response becomes your baseline — with your VPN connected, that should be your VPN server's address (you can confirm with our What Is My IP tool). When you disconnect the VPN mid-run, exactly one of two things happens, and the log makes it impossible to miss:

The distinction in the last two rows is the heart of the test. A working kill switch produces a clean sequence: same IP, same IP, blocked, blocked, blocked, then (after you reconnect) a new or identical VPN address. A failed kill switch produces the dangerous sequence: same IP, same IP, then a different IP with no blocked rows in between — meaning your device kept talking to the internet over the raw connection, and whatever address appeared is what every website, tracker, and peer saw. That row is highlighted in red because if the exposed address matches your real one, the VPN's core promise was broken.

Everything runs in your browser tab: we don't store the log, and stopping the monitor (or the 3-minute auto-stop) ends the polling entirely. Because requests time out after just under 2 seconds, even a "hanging" network state registers as blocked rather than freezing the test.

Not all kill switches are built the same way, and the difference explains most real-world failures. There are two fundamental designs:

An app-level kill switch is a watchdog: the VPN app monitors its own tunnel and shuts off traffic when the tunnel fails. It handles the common case — a dropped server connection — well, but it depends on the app itself running correctly. If the app crashes or gets killed by the OS, the watchdog dies with it.

A system-level kill switch inverts the logic: instead of reacting to failures, it configures the operating system so traffic is only ever allowed through the VPN interface. If the tunnel disappears — or the VPN app itself crashes — there is simply no route for packets to take. Mobile platforms ship their own version of this: on Android, the OS-native "Block connections without VPN" setting, and on iOS, always-on VPN behavior via Connect On Demand. This test exercises both designs the same way — from the outside, all that matters is whether traffic escaped.

If you want to stress the difference yourself: run the test once using your VPN app's disconnect button (the easy case — almost any kill switch catches a graceful disconnect), then run it again force-quitting the VPN app entirely. Only a system-level enforcement reliably passes the second run.

All eight VPNs in our rankings ship a kill switch on desktop — it's table stakes for any provider we'd recommend. Mobile support varies between app-level toggles and reliance on the OS-native enforcement described above, which is part of what we verify in our testing methodology. Here's where each provider stands, with notes from our reviews:

Two practical notes. First, a kill switch existing is not the same as a kill switch being enabled — several apps ship with the toggle off by default, so check your settings before assuming you're protected. Second, whatever any provider claims, the test above is provider-agnostic: it observes actual traffic behavior from outside the app, which is exactly how a leak would manifest in the real world. Trust the log over the marketing page — including ours.

The basic run — start, disconnect via the app, watch — covers the most common failure. But real-world drops don't politely use the disconnect button. If you rely on your VPN for anything serious (torrenting, restrictive networks, sensitive work), repeat the test under these harsher conditions:

• Force-quit the VPN app instead of disconnecting gracefully. This is the scenario that separates app-level from system-level kill switches: if traffic keeps flowing with your real IP after the app dies, only an OS-enforced mode will save you.
• Toggle your network interface. Turn WiFi off for ten seconds and back on while the monitor runs. Many leaks happen during network transitions, when the tunnel is re-established a beat after the raw connection comes up.
• Sleep and wake your laptop mid-run. Waking from sleep is the single most common silent-drop moment for desktop VPN users — the OS restores connectivity before the VPN app finishes reconnecting.
• Switch VPN protocols between runs (for example WireGuard vs OpenVPN in your app's settings). Kill-switch behavior can differ per protocol because each uses a different tunnel interface.
• Check split tunneling. If you use split tunneling, make sure your browser is routed through the VPN — otherwise this test measures your raw connection by design and every run will look like a failure.

One repetition matters more than all of these: run the full scenario at least twice. Kill-switch failures are often intermittent — a race between the drop detection and the first escaping packets — and a single clean pass doesn't prove the race can't be lost. Two or three consistent passes under force-quit conditions is a result you can actually rely on.

A red "New IP exposed" row means traffic left your device outside the tunnel. Work through these steps in order:

1. Confirm the kill switch is actually enabled. Open your VPN app's settings and find the kill switch toggle. This fixes the majority of "failures" — the feature was never on.
2. Switch to the strictest mode available. If your app offers levels (often named "advanced", "permanent", or "always-on"), pick the system-level option, then re-run the test.
3. On Android, enable the OS enforcement. Settings → Network & internet → VPN → your app → turn on "Always-on VPN" and "Block connections without VPN". This works regardless of what the app itself does.
4. Disable split tunneling (or verify its rules) — an exclusion rule for your browser looks identical to a kill-switch failure in this test.
5. Re-test after every change — one variable at a time, so you know which setting fixed it.
6. If it still leaks, change providers. A kill switch that fails a controlled test will fail an uncontrolled drop. Our best VPNs for privacy ranking weighs exactly this kind of failure-mode behavior, and every provider on it offers a 30-day money-back guarantee — so you can run this same test risk-free before committing.

And once your kill switch passes, finish the job: run our WebRTC leak test and the combined Is My VPN Working? check. A kill switch guards the drop; WebRTC and DNS leaks can expose you while the tunnel is up and healthy.