VPN kill switch test 2026: how to prove yours actually cuts

Disclosure: This article contains affiliate links. If you buy through them we may earn a commission at no extra cost to you. We only recommend services we would use ourselves, based on published specs and public track record.

Almost nobody tests their kill switch. The toggle is on, the app says protected, and that is where it ends. Here is the uncomfortable part.

The setting is a claim, not a proof

A kill switch that is enabled and a kill switch that works are two different things, and the interface cannot tell them apart. The toggle reports what the application intends to do, not what the operating system will actually do when the tunnel dies at an awkward moment.

Three real failure modes, none of which changes the toggle:

the VPN process crashes before its firewall rules take effect, and there is nothing left to enforce anything;
the rules cover IPv4 and forget IPv6, so traffic leaves around the tunnel the moment the network offers it;
the device wakes from sleep with the network up and the tunnel not yet re-established.

Over-the-shoulder view of a laptop on a wooden table: the screen shows a blue VPN application with a white mountain logo and a toggle reading VPN, You are connected, a small potted cactus sits at the right of the table, and a person in a light blue sleeve holds a white phone in the blurred foreground

The screen in this photo says « You are connected ». That sentence is the application describing itself, and it is exactly what the tests below are for. Photo by Stefan Coders via Pexels.

The four tests, from easiest to most honest

1. Note your address, then break the tunnel on purpose

Check your public IP with the tunnel up and write it down. Then kill the VPN process rather than clicking disconnect, because clicking disconnect is the case the developer thought about.

Immediately check your IP again and try to load anything. If either succeeds and shows your real address, the switch did not cut.

2. Do it again while something is transferring

Start a large download or a video, then break the tunnel.

Many kill switches block new connections and leave established ones running. An idle machine passes a test that a working machine fails, which is why the idle test is the one that flatters your setup.

3. Check both IP stacks, not one

Use a checker that reports IPv4 and IPv6 separately. A rule set written for one and not the other is among the most common real failures, and a test that only shows IPv4 will hide exactly the leak you are looking for.

4. Sleep the machine, wake it, and look fast

Close the lid, wait, reopen it. The network usually comes back before the tunnel does. That gap is real traffic on a real route, and it is the failure people never notice because it lasts seconds and leaves no trace on screen.

What a kill switch does NOT cover

This is where most articles stop, and it is where the useful part starts.

It is not a DNS leak fix. A kill switch governs whether packets leave when the tunnel is down. A DNS leak is a query going to the wrong resolver while the tunnel is up. Different failures, different fixes, and a machine can pass one and fail the other. Our DNS leak prevention guide covers the second.

It is not a WebRTC fix. A browser can reveal a local address through WebRTC with the tunnel perfectly healthy. See our WebRTC leak test.

It does not make you anonymous. It keeps one specific promise: that traffic stops rather than escaping when the tunnel fails. That promise is worth having and it is narrow.

Application-level or firewall-level, and why it decides everything

Two implementations wear the same name.

Application-level: the VPN client stops the traffic it manages. If the client dies, the enforcement dies with it.
Firewall-level: rules in the operating system drop everything except the VPN endpoint. They survive the client crashing, which is the failure that matters most.

If you self-host, you write these rules yourself and you know which kind you have. Our Linux kill switch with iptables and systemd is the firewall-level version, and it keeps working when the tunnel process does not, because the rules do not depend on it.

That is the honest argument for self-hosting here: not that it is more secure by nature, but that you can read the rule that protects you. With a commercial client you are trusting a description of behaviour; with your own rules you are looking at the behaviour.

What to do with the result

If your kill switch fails one of these tests, the fix is usually not a different provider. It is a firewall-level rule that does not depend on any application staying alive, and on a VPS you control that is a handful of lines. Our ranking of the cheapest VPS for WireGuard compares providers on price and bandwidth.

And if it passes all four: write down the date. A kill switch is not a permanent property of a machine. An operating system update, a new network interface or a changed rule set can undo it, and the toggle will still say it is on.

★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→

Frequently asked questions

How do I test a VPN kill switch?

Note your public IP with the tunnel up, then break the tunnel without warning it: kill the VPN process, pull the network cable, or disable the adapter. Immediately check your IP again and try to load any site. If either succeeds and shows your real address, the kill switch did not cut. Repeat while something is actively transferring, because a switch that cuts new connections may leave an established one running.

Does the kill switch setting being on mean it works?

No, and this is the whole point of testing. The setting is a claim by the application about its own behaviour. Kill switches fail in ways the toggle cannot report: a crash that takes the process down before its firewall rules apply, a rule set that covers IPv4 and forgets IPv6, a device waking from sleep with the network up and the tunnel not yet re-established. The toggle stays on through all three.

What does a VPN kill switch actually do?

It blocks traffic from leaving the machine when the tunnel is not up. Implementations differ: some drop everything except the VPN endpoint by writing firewall rules, some just stop the applications they manage, and the difference matters enormously. A firewall-level switch survives the VPN process dying; an application-level one dies with it.

Should I use a VPN kill switch?

If the consequence of one unprotected packet matters to you, yes. If you use a VPN to reach your own machines or to keep a coffee shop network out of your traffic, the kill switch is what makes that guarantee hold across a disconnection. If your threat model tolerates a few seconds of exposed traffic, it is a convenience rather than a necessity. Decide from the consequence, not from the feature list.

Do kill switches leak IPv6?

Some do, and it is one of the most common real failures. A rule set written for IPv4 can leave IPv6 untouched, so the moment your network offers IPv6 the traffic goes out around the tunnel. Test with an address checker that reports both stacks, not one that only shows IPv4, otherwise the test itself will hide the problem.

Does a kill switch protect against DNS leaks?

Not by itself. A kill switch governs whether packets leave when the tunnel is down; a DNS leak is a query going to the wrong resolver while the tunnel is up. They are different failures with different fixes, and a machine can pass one test and fail the other. Test both.

Why does my connection stay alive for a few seconds after the VPN drops?

Because many kill switches block new connections but do not tear down established ones. A download or a video already in flight can keep running on the old route. This is why the honest test is done while something is transferring, not on an idle machine where everything looks clean.