Does Your VPN's Kill Switch Actually Work?
We read your IPv4 address every two seconds. Force-quit your VPN app while the monitor runs and see whether anything gets out before it comes back.
How to Test Your Kill Switch
Live Event Log
What Is a VPN Kill Switch?
A kill switch is a safety mechanism that blocks all internet traffic the moment your VPN connection drops. Without one, your device does exactly what it was designed to do when a route disappears: it falls back to the ordinary connection and carries on as though nothing happened. Downloads continue, apps keep syncing, pages keep loading - all of it now over your real IP address.
The exposure window is short but it is not harmless. VPN reconnections happen routinely: switching between Wi-Fi and mobile data, waking a laptop from sleep, a server restarting on the provider’s side. Each of those events can leave a gap during which your traffic is unprotected, and background applications will use it. A single request is enough to link your real address to whatever you were doing.
The problem with kill switches is that they are unfalsifiable until tested. A checkbox in the settings panel proves that the feature exists, not that it fires. This page measures the behaviour directly rather than trusting the checkbox.
How to Read Your Results
The monitor reads your IPv4 address every two seconds while you force-quit the VPN app and start it again. It asks api.ipify.org, which has no IPv6 address. On a connection with both, a service reachable over IPv6 sees your IPv6 address instead - and if your VPN carries only IPv4, that address is your ISP’s before the drop and after it, so the drop goes unseen. These are the outcomes, and what each one means.
| What happens after the VPN app is force-quit | Verdict |
|---|---|
| IPv4 checks get no answer, and neither does our own server, until the VPN reconnects on the same address | Kill switch works |
| Everything is blocked and the connection never comes back while the monitor runs | Not confirmed - a kill switch and a network outage look the same from a browser |
| IPv4 is blocked, but IPv6 keeps answering through the block | Not a pass - IPv6 traffic was not stopped |
| Your IPv4 address changes to one on a network not listed as hosting or VPN, such as your ISP’s | Kill switch failed - traffic leaked |
| Your IPv4 address changes to one on a hosting or VPN network, or the same network you started on | Another server - the VPN app switched servers; not a leak, and not a pass |
| IPv4 changes briefly, then the connection is blocked | Kill switch failed - it reacted after traffic got out |
A working kill switch looks like a broken internet connection, and that is precisely the point. The last outcome is the one worth paying attention to: a kill switch that reacts in two seconds instead of instantly still leaked every request your device made during those two seconds. The event log above records when each check saw the change and the block, to the nearest check.
Because no answer is what a pass looks like, it is not taken on its own word: api.ipify.org can be down too. When it does not answer, the monitor asks our own server, api.vpnmeter.com, which also has only an IPv4 address. Only if that fails as well, with your browser still online, is the check counted as blocked. A check that finds the connection open without reading an address, or runs while your device is offline, is logged and counts for nothing - a pulled cable kills the connection as surely as a kill switch does.
When your IPv4 address changes, the monitor looks the new address up once you stop it, the way the leak test does: our server asks ip-api.com whose network it is and keeps no address. On a network listed as hosting or VPN, or the one you started on, your VPN app moved you to another of its servers; on any other, traffic went out through your own connection. If the lookup cannot be made, the run is a failure, and the verdict says the network could not be checked.
Your IPv6 address is read alongside, from api64.ipify.org, and shown under the IPv4 one and with the verdict. It cannot turn a run into a failure: whether an IPv6 address is your VPN’s or your ISP’s takes a lookup this monitor does not make. But it can keep a run from passing. If IPv6 answers while IPv4 is blocked, the kill switch let IPv6 traffic out, and if your IPv6 address changes during the run, it may have been outside the tunnel - either way the run is not offered for sharing as a pass. The IPv6 row of the leak test tells you whose the address is.
Application-Level vs System-Level Kill Switches
Not all kill switches protect the same things, and the difference matters.
- Application-level: closes or blocks a list of chosen applications when the tunnel drops. Everything not on the list keeps running unprotected - including your browser, if you forgot to add it.
- System-level (firewall-based): installs firewall rules that permit traffic only through the VPN interface. Nothing reaches the internet outside the tunnel, regardless of which application tries. This is the version worth having.
- Always-on / lockdown mode: the strictest variant, blocking traffic even before the VPN connects, so there is no exposure at boot. Android calls this “Block connections without VPN”; several desktop clients label it lockdown mode.
If your provider does not state which kind it implements, you can find out: start a download in an application that is not on the list, then force-quit the VPN app. A system-level switch stops the download; an application-level one does not. This page cannot see other applications, so watch the download yourself.
What to Do If Your Kill Switch Fails
- Check it is actually enabled. A client can ship with the kill switch off by default, and an update can reset it. Check this first: it is the quickest to rule out.
- Enable lockdown or always-on mode if your client offers it, so protection covers boot and reconnection as well as drops.
- Switch protocol to WireGuard. Faster reconnection means a smaller window even when the switch reacts imperfectly.
- Use the operating system’s own control - Android’s “Block connections without VPN” is enforced by the OS and does not depend on the client behaving correctly.
- Consider a firewall rule. On desktop you can restrict outbound traffic to the VPN interface directly, which is the most reliable arrangement available and independent of your provider entirely.
Once the kill switch passes, verify the tunnel itself is clean with our full IP leak test - a perfect kill switch protects nothing if the connection leaks while it is up.
🧰 Related VPN Tools
The tests run in your browser. Where one needs to know whose network an address is on, our server looks it up and keeps no address. Nothing is stored unless you choose to share the result.
📚 Read next
The longer version: what this test is looking for, and what to do with the answer.
VPN Kill Switch Test - FAQ
What a kill switch does, how to prove yours works, and what to do when it does not.
How do I test my VPN kill switch?
Start the monitor above, then force-quit your VPN app while it runs (a normal Disconnect can turn a kill switch off on purpose). The monitor reads your IPv4 address every two seconds. If the checks stop getting answers, our own server stops answering too, and the connection comes back on the same address when you start the VPN again, the kill switch held. If a different IPv4 address - your real one - appears at any check, traffic escaped and the kill switch failed.
Is a kill switch really necessary?
It matters because VPN connections drop - when you switch networks, wake from sleep, or a server restarts on the provider’s side. Each drop creates seconds of unprotected traffic that background applications will use immediately. If your reason for running a VPN would be undermined by a few seconds of exposure, then yes, it is necessary.
Why did my internet stop working during the test?
That is the expected outcome. A working kill switch blocks all traffic when the tunnel drops, which a browser cannot tell apart from an outage - so the test counts it as a pass only once you reconnect the VPN and the connection comes back on the same address. If your connection kept working normally after the VPN went down, the kill switch did not fire.
Can the test miss a leak?
A very short one, yes. It checks your IPv4 address about every two seconds, so traffic that slips out for less than that between two checks is not seen, and browsers slow timers down in background tabs - keep this tab in front while you test. It also watches what a browser can see: an app that sends traffic in the gap is not observed directly. A pass means no leak was seen at any check, not that none could happen.
What is the difference between a kill switch and always-on VPN?
A kill switch reacts to a drop: it blocks traffic once the tunnel fails. Always-on mode is preventive: it blocks traffic whenever the VPN is not connected, including during boot and before the client starts. Always-on covers the startup gap that a plain kill switch leaves open, and where both are available, enabling both is the right configuration.
How fast should a kill switch react?
Ideally instantly, because a firewall-based implementation blocks traffic at the moment the interface goes down rather than after detecting it. A switch that reacts only after detecting the drop leaks every request made in between. The event log above timestamps each check so you can measure your own window.
Does a kill switch protect against DNS leaks?
No - these are separate problems. A kill switch handles what happens when the tunnel fails; a DNS leak happens while the tunnel is working perfectly. You need both checks to pass. Run our DNS leak test alongside this one for the complete picture.
My VPN has no kill switch. What are my options?
On Android, enable “Block connections without VPN” in the system VPN settings - it is enforced by the operating system and works with any client. On desktop, configure your firewall to allow outbound traffic only on the VPN interface. Both approaches are more reliable than a client-side switch, since neither depends on your provider’s software behaving correctly.
Should I re-test after updating my VPN client?
Yes. Kill switches depend on firewall and routing rules that get rewritten during updates, and the setting itself is sometimes reset to its default. It is a regression worth checking for, and the test takes a few minutes - worth repeating after every client update or OS upgrade.