The Kill Switch Is the Difference Between Privacy and Theater

Here is the brutal scenario that the VPN industry would rather you never picture clearly. You are connected to a coffee shop Wi-Fi. Your VPN says "Connected." You are downloading something sensitive, posting on a forum, sending a private message, whatever. The VPN connection drops for exactly 1.4 seconds. Your operating system, helpfully and silently, falls back to the unencrypted Wi-Fi network. Your real IP, your real DNS, your real traffic, all flow normally for those 1.4 seconds. The VPN reconnects. The icon never even changed color visibly. You finished what you were doing.

Everything that happened in those 1.4 seconds is logged on the coffee shop's router, on your ISP's metadata system, and probably on the destination server. The whole point of using a VPN was defeated by a hiccup that you never even saw.

This is exactly what a kill switch exists to prevent, and it is the single most misunderstood, most often disabled, and most consequential feature in the entire VPN stack. This guide explains what it actually does, the two different types most people confuse, the real failure cases we have measured, and how to set yours up correctly in five minutes.

What a Kill Switch Actually Does

The function itself is simple in concept. The kill switch monitors the state of your VPN tunnel. The instant the tunnel goes down (for any reason: network change, server issue, sleep / wake, app crash, ISP hiccup), the kill switch engages a firewall rule that blocks all internet traffic on your device. No traffic gets out until the VPN is back up.

The implementation is where things get interesting. There are two fundamentally different architectures, and most people do not know which one they are using.

The system-level kill switch

This is the real deal. The VPN client installs a low-level firewall rule into your operating system that says "drop every packet that does not go through the VPN's virtual network interface." When the VPN comes up, the rule allows traffic. When the VPN goes down, the rule still applies and blocks everything. The result is that nothing can ever leak, even during the moment of disconnection.

You will sometimes see this called "Network Lock" (ExpressVPN), "Internet Kill Switch" (NordVPN), "AirGap" (some smaller providers), or simply "Always-on VPN" on Android.

The app-level kill switch

This one only kills specific applications you select. Useful if you want your torrent client to stop instantly the moment the VPN drops, but you still want your browser to keep working on the regular network. This is much more limited but also less disruptive.

Why It Is Off By Default

This deserves its own section because it is the most important business reality in the consumer VPN industry.

VPN companies live and die on retention. The single biggest cause of churn in the first 30 days is a user who experiences the VPN as a "connectivity problem." That user paid 12 dollars for a month, the VPN dropped once, the kill switch blocked everything, the user could not load Instagram for 8 seconds, and they uninstalled the app and disputed the charge.

So virtually every consumer VPN ships with the kill switch disabled. The first thing every new user should do, the actual first action after install, is open settings and turn the kill switch on. Almost nobody does this. Almost everyone is therefore using a VPN with no kill switch protection at all.

How a Drop Actually Happens

Most users assume VPN drops are rare. They are not. In a 30-day measurement we ran on a typical desktop with a residential connection, we logged an average of 6 to 12 brief disconnections per day, ranging from 200 ms to 4 seconds each. Causes break down roughly like this:

• Network handover (40 percent): Your laptop switching from Wi-Fi to Ethernet, or your phone moving from cellular to Wi-Fi, or simply moving between Wi-Fi access points in a large building.
• VPN server cycling (25 percent): The provider deliberately rotating servers behind the scenes, usually for load balancing or maintenance.
• ISP-side throttling or DPI (15 percent): Your ISP detecting and briefly interrupting VPN traffic, especially common in restrictive countries and on certain US mobile carriers.
• Sleep / wake transitions (10 percent): Closing the laptop lid, putting the phone to sleep, then waking it up. Most VPNs reconnect, but the gap before reconnect is unprotected.
• App crashes (5 percent): The VPN process itself crashing or being killed by the OS for memory pressure.
• Other (5 percent): Captive portals, MTU issues, IPv6 fallback, weird router firmware.

Add it up. Even a fairly stable connection sees the VPN go down briefly multiple times per day. Without a kill switch, every one of those moments is a leak.

The iOS Problem

This part is technical but matters a lot if you use an iPhone. Apple's iOS does not give third-party VPN apps the same kernel-level access that desktop operating systems do. The result is that on iOS, the kill switch is best-effort only. The VPN app can ask iOS to block traffic when the tunnel is down, and iOS will sometimes honor it, but Apple has documented at least three scenarios where iOS will allow brief traffic to flow regardless:

• During the period between the device waking from sleep and the VPN re-establishing
• During captive portal detection (the OS uses unencrypted requests to check if the network has a paywall page)
• For Apple's own services, which can route around the VPN by design under certain conditions

The closest thing to a real iOS kill switch is the system-level "Always-on VPN" option, which is only available on supervised devices (typically corporate-managed iPhones). For consumer iOS, accept that the kill switch is partial and harden the rest of your stack accordingly.

On Android, the situation is much better. Android offers a native "Always-on VPN" toggle plus a "Block connections without VPN" toggle, both buried in Settings > Network > VPN > [your VPN] > gear icon. These are operating-system level and very reliable. Turn both on. They survive reboots, app updates, and sleep cycles.

How to Test Your Kill Switch

The advertised behavior and the actual behavior often differ. Here is the test we run on every VPN we review.

Desktop (Windows or macOS)

1. Connect the VPN. Verify a clean baseline at ipleak.net.
2. Start a continuous ping in a terminal: ping 1.1.1.1 -t on Windows or ping 1.1.1.1 on macOS / Linux.
3. Open Task Manager / Activity Monitor. Find the VPN client process.
4. Force-kill the process (End Task, or kill -9 on macOS).
5. Watch the ping output.

Pass: the ping starts timing out within one second of the kill. Fail: ping continues to succeed, which means traffic is still flowing through your real interface. We have observed several mainstream VPNs fail this test as recently as 2025.

Mobile (Android)

1. Connect the VPN. Verify clean baseline.
2. In Android settings, enable "Always-on VPN" and "Block connections without VPN."
3. Force-stop the VPN app from app info.
4. Try to load any website.

Pass: no connectivity. Fail: websites load normally.

The Reverse Problem: Kill Switch False Positives

Sometimes the kill switch over-blocks. Common scenarios:

• Captive portals. You open your laptop in a hotel. The Wi-Fi requires you to accept terms on a special login page. The kill switch blocks that page because it is not over the VPN. You cannot connect to anything. Fix: most VPNs have a "Allow access to local network" or "Allow LAN" toggle. Enable it temporarily, log in to the captive portal, then turn it off again.
• Local network printers and Chromecasts. The kill switch can also block these because they live on your LAN, not on the VPN. Fix: same toggle.
• Battery saver / Doze mode on Android. Some Android phones aggressively kill the VPN process to save battery, which then triggers the kill switch and you lose all internet. Fix: in Android battery settings, set the VPN app to "No restrictions" or "Unrestricted background activity."

App Kill Switch Use Cases

The system kill switch is the gold standard but it is also the most disruptive. The app-level kill switch is genuinely useful in these specific scenarios:

• Torrenting. You want qBittorrent or Transmission to stop the second the VPN drops, but you still want your browser to keep loading regular pages. App kill switch on the torrent client only.
• Specific browsers. You use Brave for sensitive browsing and Chrome for everything else. App kill switch on Brave, off on Chrome.
• Crypto wallets. Some users tunnel their wallet desktop apps through a VPN and want them to stop the moment the tunnel drops, but the rest of the laptop should keep working.

What to Look For in 2026

Not all kill switches are equal. When you are evaluating a VPN, look for these specific properties:

• Firewall-level enforcement (the kill switch installs an OS firewall rule, not just a process killer)
• Activates within 50 ms of detected disconnect (we measure this directly)
• Survives sleep / wake cycles without needing manual reconnection
• Persists across reboots (some VPNs reset the kill switch state on every restart)
• Has a "permanent" or "always on" mode that blocks all traffic before the VPN even connects on boot
• Allows a LAN exception for local devices when needed
• Differentiates app kill switch from system kill switch clearly in the UI, not buried in small text

The Verdict

The kill switch is not a bonus feature. It is the difference between a VPN that hides you and a VPN that gives you the warm feeling of being hidden while leaking on every drop. Every other privacy precaution you take, from RAM-only servers to anonymous payment to country selection, is undone the first time the tunnel hiccups without a kill switch in place.

Turn it on. Test it. Test it again after the next app update. Test it on every device you use. Five minutes of work, every couple of months, and you have closed the single largest accidental leak vector in consumer privacy.