A second. Sometimes three. That is how long your unprotected connection can live after the tunnel goes down while you still have no idea it happened.
It is an everyday situation, and I have lived through it dozens of times: you are on a commuter train, VPN is on, the train enters a cutting, the connection drops for a moment and immediately comes back, the tray icon looks fine — but the tunnel has already gone down and is reconnecting, while the browser, messenger and a dozen background processes keep talking to the internet directly, from your real address.
That gap is exactly what Kill Switch was invented for. The logic is primitive: no tunnel, no internet. Not “a little direct traffic while we reconnect”, but nothing at all. Full disclosure: I work for a VPN service, so I have a vested interest. But there is nothing to take on faith here — you can test a Kill Switch yourself in three minutes. Test me too.
What can leak in those few seconds
The mechanics are boring, and that is what makes them especially annoying. It took me a while to accept that the problem is not a failure, but normal operation. When the VPN comes up, it changes routing so the default route points to the virtual tunnel interface; when the tunnel goes down, the interface disappears with it, and the system does exactly what it was designed to do — puts the route back on the physical network adapter because the connection is still available. Everything is technically correct. There is nothing to blame. The traffic simply bypasses encryption.
Then everything happens in fractions of a second, without you doing anything. Messengers rebuild their connections — now from your real IP. The browser finishes loading images. Background apps check for updates. If a torrent client is running, it cheerfully announces itself to the tracker and exposes your address to the whole swarm, which in my experience is the worst case: the trace is not left with one provider but with hundreds of random people. You cannot realistically notice it. The outage and reconnection together take less time than your eye needs to catch the icon blinking.
So what happens if the VPN disconnects? If you were watching cat videos, probably nothing. But if you were logged in somewhere where linking your account to your real address is something you explicitly wanted to avoid, exactly what you were protecting yourself from can happen.
[Image: two tunnel-failure scenarios — on the left, traffic goes directly to the ISP after the tunnel drops; on the right, Kill Switch blocks all outgoing connections]
How it works inside: three levels of protection
Kill Switch is not one technology but a generic name for several solutions with very different reliability, and a website description rarely shows the difference. The checkbox looks the same everywhere, and honestly, that annoys me.
Firewall-based. The client adds firewall rules: outgoing traffic is allowed only through the tunnel interface and only to the server address; everything else is dropped. Windows uses WFP, Linux uses nftables, macOS uses pf. The rules live in the kernel and do not depend on whether the client process is alive — it can crash, be killed by the system, or freeze completely, and traffic still goes nowhere. This is the only implementation I consider a real Kill Switch.
Application-based. The client monitors the connection and cuts traffic when it detects a drop. It works, and quite well — I used one myself for years. But if the application itself crashes rather than the tunnel, there is nobody left to cut the traffic.
System-level. The operating system itself enforces a policy of “do not access the network without VPN”. Android has this built in and it works well; iOS is a separate, less pleasant story.
I prefer this analogy. The first is an RCD in an electrical panel: it does not ask the kettle for permission, it simply cuts the circuit. The second is the kettle itself with a sensor: while it works, it monitors the situation; once it burns out, there is nobody left to monitor it.
Full, per-app and “VPN only”
Three modes can hide under the same name.
Full. The tunnel drops — the entire device loses network access. Blunt, but there are no gaps. This is my choice for a laptop.
Per-app. You specify which programs are not allowed to access the internet without the tunnel; everything else continues normally: email goes down with the VPN, music keeps playing. It looks convenient until you remember that this implementation is usually application-based. An intentional compromise. Still a compromise.
VPN only access. The strictest option: the device is not allowed out to the internet except through the tunnel — not only during an outage, but at all times. It makes sense on work machines where direct access is prohibited by policy; see our article on managing employee VPN access for more.
Why use Kill Switch in any of these modes? One answer: so the decision about whether your traffic is allowed outside the tunnel is made by you in advance, with a clear head, rather than by the operating system during a failure using the logic “the connection is available, so use it”.
Mobile devices: Android can do it, iOS is a compromise
This is where the platforms diverge sharply, and it is one of the hardest things to explain. Android has the system-level Always-on VPN option, alongside a switch that blocks connections without VPN. Together, they provide a genuine system-level Kill Switch that does not depend on the client or how well it behaves. The path is usually: Settings → Network & internet → VPN → the gear icon next to the profile. Names vary between vendors, and I stopped trying to memorize them. To enable Always-on VPN, turn on “Always-on VPN”, then “Block connections without VPN”. The second switch is unavailable until the first one is enabled. One small detail that once cost me an evening: some clients do not show the option until the profile has connected at least once.
[Image: Android system settings with “Always-on VPN” and “Block connections without VPN” enabled]
iOS is more complicated, and here comes the unpleasant part. Does iPhone have the same kind of Kill Switch? Honestly, no. The platform does not let a third-party app control the network stack deeply enough to guarantee that all traffic will be blocked when the tunnel drops, and I do not know whether that will ever change. Instead of blocking traffic, clients use on-demand connections: the system brings the tunnel back up automatically, reducing the leak window to a fraction of a second. But that is reconnection, not blocking. A full system-level equivalent is available only through corporate MDM profiles. Put simply: you have a stronger guarantee on Android and desktop, while iPhone requires a compromise.
Three-minute check: a step-by-step test
Now for the part this whole thing is about. How to check whether Kill Switch actually works for you — manually, without trusting descriptions. Including mine.
- Connect to the VPN and open the connection check page. Note your IP, country and DNS servers. That is your baseline.
- Now break the tunnel abruptly. Do not click “disconnect”: the client will shut down cleanly, which proves nothing. You need an emergency interruption — turn off Wi-Fi for five seconds or kill the client process.
- Immediately, without waiting for reconnection, refresh the check page.
- Look at the result. If it does not open and the browser reports a network error, the protection worked. If it opens and shows your real IP and your ISP’s DNS, the checkbox is decorative.
- Repeat the test on every device. Behaviour can differ even between clients on the same platform.
Also run the test over mobile data — that is where connection drops happen most often.
[Image: check result before and after a tunnel drop — VPN server address on the left, connection unavailable instead of the real IP on the right]
What can still leak with Kill Switch enabled
Here is the unpleasant part. Kill Switch closes exactly one hole — traffic escaping when the tunnel drops — and nothing more. I have seen people discover this only after months of feeling completely safe.
DNS. If DNS requests bypass the tunnel — which happens more often than you might think — your ISP can see the domains you request even while the VPN itself is working normally.
IPv6. A classic trap. The tunnel is configured for IPv4, your ISP provides IPv6, and traffic to IPv6-only endpoints goes directly. There was no tunnel failure, so there was nothing for Kill Switch to block.
Local network. Many implementations leave the local network accessible so your printer keeps working. Fine at home. On hotel Wi-Fi, where the local network includes everyone on the floor, not so fine; the risks of public networks are covered separately.
More precisely, these issues need to be handled separately: the mechanics of all three are covered in our article about DNS, WebRTC and IPv6 leaks. The topics belong together.
When it gets in the way and what to do
I’ll be honest: Kill Switch is annoying. Especially at first. The most common case is a café Wi-Fi network with a login page, and I have tripped over this one about twenty times: the browser needs to open the page with the “I agree” button, but all traffic is blocked because there is no tunnel, and there is no tunnel because you have not clicked “I agree”. A perfect loop. The fix is to disable the protection for a minute. The second case is printers, NAS devices and cameras. If there is an option to “allow local network access”, enable it at home and disable it when travelling.
The third case is Russian services that dislike foreign addresses: banks, government services and marketplaces. Kill Switch is not the culprit; the foreign IP is. The solution is not to disable protection, but to use split tunneling: the required apps go directly, everything else stays in the tunnel, and Kill Switch continues protecting the main traffic flow.
The rule I learned the hard way, at the cost of a couple of unpleasant evenings: make exceptions surgically instead of disabling protection completely “for a couple of hours”. A couple of hours turns into a week.
Checklist: what should be enabled
- Kill Switch is enabled on every device — not just your “main” device, but every device.
- The mode is chosen deliberately: full mode for a laptop, per-app mode if full blocking gets in the way.
- On Android, “Always-on VPN” and “Block connections without VPN” are enabled.
- On iOS, on-demand reconnection is enabled — and you remember that it is not the same thing.
- DNS requests go through the tunnel — verified, not assumed.
- IPv6 is either routed through the tunnel or disabled at the system level.
- Local network access is disabled when you are on an untrusted network.
- The emergency disconnect test has been passed.
- Banking exceptions are handled with split tunneling, not by disabling protection.
Half an hour of work once, and then you can stop thinking about it.
In short
Kill Switch is not an option for paranoids and not just another feature on a checklist. It is the thing standing between you and your real address in the seconds when the tunnel blinks. And it does blink: in the subway, in an elevator, when switching from Wi-Fi to mobile data. Test it manually: claimed support and a working implementation are two different things. A solid Kill Switch in 2026 is also a useful filter when choosing a service: if a provider cut corners here, it is worth asking what else they cut corners on, as discussed in our analysis of free VPNs. In the end, the choice is yours.
Check your protection now — it takes thirty seconds, and the result can be surprising. If something does not match, contact support. If you do not have a service yet, there is a 14-day trial with no card required to test on your own devices.
Frequently asked questions
What is Kill Switch in a VPN?
A mechanism that blocks device traffic when the VPN tunnel is disconnected — protection against VPN drops in its purest form. The goal is to stop the system from falling back to a direct connection and exposing your real IP. It can be implemented at the firewall, application or system level; reliability generally decreases in that order.
How do I check whether Kill Switch works?
Connect to the VPN, open the check page and note your IP. Then interrupt the connection abruptly and refresh the page immediately. If it does not open, the protection works; if it shows your real address, it does not.
Does iPhone have Kill Switch?
Not in the full system-level form: iOS does not let an app control the network stack deeply enough. Instead of blocking traffic, clients use on-demand connections, which reduce the leak window to a fraction of a second but do not eliminate it. The system-level equivalent is available only through corporate profiles.
Why use Always-on VPN?
It is an Android system setting that keeps the tunnel active and, together with “Block connections without VPN”, prevents traffic from bypassing it. Unlike protection implemented inside an app, it remains effective even if the client crashes. It is enabled in the VPN settings next to the profile.
