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.<\/p>\n
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 \u2014 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.<\/p>\n
That gap is exactly what Kill Switch was invented for. The logic is primitive: no tunnel, no internet. Not \u201ca little direct traffic while we reconnect\u201d, 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 \u2014 you can test a Kill Switch yourself in three minutes. Test me too.<\/p>\n
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 \u2014 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.<\/p>\n
Then everything happens in fractions of a second, without you doing anything. Messengers rebuild their connections \u2014 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.<\/p>\n
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.<\/p>\n
[Image: two tunnel-failure scenarios \u2014 on the left, traffic goes directly to the ISP after the tunnel drops; on the right, Kill Switch blocks all outgoing connections]<\/em><\/p>\n 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.<\/p>\n Firewall-based.<\/strong> 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 \u2014 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.<\/p>\n Application-based.<\/strong> The client monitors the connection and cuts traffic when it detects a drop. It works, and quite well \u2014 I used one myself for years. But if the application itself crashes rather than the tunnel, there is nobody left to cut the traffic.<\/p>\n System-level.<\/strong> The operating system itself enforces a policy of \u201cdo not access the network without VPN\u201d. Android has this built in and it works well; iOS is a separate, less pleasant story.<\/p>\n 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.<\/p>\n Three modes can hide under the same name.<\/p>\n Full.<\/strong> The tunnel drops \u2014 the entire device loses network access. Blunt, but there are no gaps. This is my choice for a laptop.<\/p>\n Per-app.<\/strong> 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.<\/p>\n VPN only access.<\/strong> The strictest option: the device is not allowed out to the internet except through the tunnel \u2014 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<\/a> for more.<\/p>\n 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 \u201cthe connection is available, so use it\u201d.<\/p>\n 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<\/strong> 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 \u2192 Network & internet \u2192 VPN \u2192 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 \u201cAlways-on VPN\u201d, then \u201cBlock connections without VPN\u201d. 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.<\/p>\n [Image: Android system settings with \u201cAlways-on VPN\u201d and \u201cBlock connections without VPN\u201d enabled]<\/em><\/p>\n 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.<\/p>\n Now for the part this whole thing is about. How to check whether Kill Switch actually works for you \u2014 manually, without trusting descriptions. Including mine.<\/p>\n Also run the test over mobile data \u2014 that is where connection drops happen most often.<\/p>\n [Image: check result before and after a tunnel drop \u2014 VPN server address on the left, connection unavailable instead of the real IP on the right]<\/em><\/p>\n Here is the unpleasant part. Kill Switch closes exactly one hole \u2014 traffic escaping when the tunnel drops \u2014 and nothing more. I have seen people discover this only after months of feeling completely safe.<\/p>\n DNS.<\/strong> If DNS requests bypass the tunnel \u2014 which happens more often than you might think \u2014 your ISP can see the domains you request even while the VPN itself is working normally.<\/p>\n IPv6.<\/strong> 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.<\/p>\n Local network.<\/strong> 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<\/a> are covered separately.<\/p>\n 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<\/a>. The topics belong together.<\/p>\n I’ll be honest: Kill Switch is annoying. Especially at first. The most common case is a caf\u00e9 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 \u201cI agree\u201d button, but all traffic is blocked because there is no tunnel, and there is no tunnel because you have not clicked \u201cI agree\u201d. 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 \u201callow local network access\u201d, enable it at home and disable it when travelling.<\/p>\n 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<\/a>: the required apps go directly, everything else stays in the tunnel, and Kill Switch continues protecting the main traffic flow.<\/p>\n The rule I learned the hard way, at the cost of a couple of unpleasant evenings: make exceptions surgically instead of disabling protection completely \u201cfor a couple of hours\u201d. A couple of hours turns into a week.<\/p>\n Half an hour of work once, and then you can stop thinking about it.<\/p>\n 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<\/a>. In the end, the choice is yours.<\/p>\n Check your protection now<\/a> \u2014 it takes thirty seconds, and the result can be surprising. If something does not match, contact support<\/a>. If you do not have a service yet, there is a 14-day trial with no card required<\/a> to test on your own devices.<\/p>\n A mechanism that blocks device traffic when the VPN tunnel is disconnected \u2014 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.<\/p>\nHow it works inside: three levels of protection<\/h2>\n
Full, per-app and \u201cVPN only\u201d<\/h2>\n
Mobile devices: Android can do it, iOS is a compromise<\/h2>\n
Three-minute check: a step-by-step test<\/h2>\n
\n
What can still leak with Kill Switch enabled<\/h2>\n
When it gets in the way and what to do<\/h2>\n
Checklist: what should be enabled<\/h2>\n
\n
In short<\/h2>\n
Frequently asked questions<\/h2>\n
What is Kill Switch in a VPN?<\/h3>\n
How do I check whether Kill Switch works?<\/h3>\n