What Is a VPN Kill Switch and How Does It Actually Work

When a VPN connection drops — a bad WiFi handoff, the server rebooting, the app crashing — your device doesn't just stop working. By default, most operating systems fall back to routing traffic through your normal, unencrypted connection instead, because staying connected to the internet is the default behavior any OS is built around. That fallback is fast, often under a second, but it's long enough for a website, a game server, or a torrent swarm to see your real IP address before you notice anything went wrong.

A kill switch is what closes that gap. This guide covers what it actually does at a technical level, the real difference between the two ways providers implement it, and why that difference determines whether it protects you or just gives you a false sense of security.

What happens in the gap, and what a kill switch changes

This is a direct application of a general security-engineering principle called failing closed: when a control fails, the safe default is to deny access rather than allow it, even at the cost of some inconvenience. The alternative — failing open, where a failure defaults to allowing traffic through — prioritizes staying connected over staying protected. A VPN with no kill switch fails open by default: if the tunnel drops, your device's normal networking takes back over automatically, silently, and immediately.^[3]

Two different implementations, and they are not equally reliable

System-level (firewall) kill switches

The stronger implementation works at the operating system's firewall layer, independent of the VPN app itself. On Windows this means rules written directly into the Windows Filtering Platform (WFP); on macOS, Packet Filter (PF) rules; on Linux, nftables. These rules block every network interface except the VPN's virtual adapter at the kernel level — they stay enforced even if the VPN app itself crashes or is killed by the OS, because the blocking doesn't depend on the app continuing to run. Mullvad's own technical documentation describes this explicitly: the firewall is built to "fail closed, meaning if the packets don't leave encrypted in the way the app intends, then they can't leave at all."^[1]

App-level kill switches

The weaker implementation monitors the VPN connection from inside the VPN application and reacts when it detects a drop — closing specific programs, or blocking traffic through the app's own mechanisms rather than the OS firewall directly. This is meaningfully less reliable: it depends on the app itself remaining alive and responsive. If the app crashes at the same moment the tunnel drops — a genuinely common failure pattern, since both can be caused by the same underlying network event — there's nothing left running to enforce the block. NordVPN's own documentation illustrates this split clearly: its Windows "App Kill Switch" closes specified programs on disconnect and is off by default, while its iOS, macOS App Store, and Android 8.0+ versions implement true system-wide blocking instead.^[2]

• A kill switch that can be toggled off is an app-level or optional feature — check whether it's on by default, since several major providers ship with it disabled
• A kill switch described as "always on" or one with no on/off setting at all is usually the strongest signal of a true system-level, firewall-based implementation
• Platform matters: the same provider's kill switch can be implemented completely differently on Windows versus iOS versus Android — check the specific platform you actually use
• You can test this yourself: start a download, manually disable your network adapter or pull the WiFi, and confirm the connection actually stops rather than silently reconnecting on your real IP

Why this matters most for torrenting

The highest-stakes case for a kill switch is BitTorrent specifically, because the exposure window doesn't need to be long to matter. Every peer in a torrent swarm can see the IP address of every other peer directly — that's how the protocol works — and copyright-monitoring organizations run automated tools that log exactly this. A VPN drop of even a few seconds is enough for your real IP to be logged in that swarm's peer list, and unlike a briefly-interrupted webpage load, there's no undoing a peer connection that already happened. This is also why interface binding — telling a torrent client like qBittorrent to only use the VPN's network adapter, refusing any other connection outright — is worth combining with a kill switch rather than relying on either alone.