VPN kill switch explained: how it works and why it's non-negotiable

A VPN client's settings page typically shows a dozen toggles. Of that list, only one makes the difference between real protection and a false sense of security: the kill switch. When the tunnel drops — and it does drop, multiple times per session on some networks — without a kill switch your traffic keeps leaving in the clear through your ISP for 5 to 30 seconds. Those seconds are enough to leak your real IP to Netflix, send a sensitive DNS query to your ISP, or expose your torrent client to trackers.

This guide covers the exact firewall-level mechanics, the two variants (app vs system), the activation procedure for the four major VPNs in 2026, edge cases for Linux / router / mobile, and the situations where the kill switch becomes counterproductive.

Why a kill switch exists — the silent disconnection problem

The scenario that justifies the kill switch is trivially easy to reproduce and invisible when it happens. You're connected to a VPN server in Amsterdam from your hotel in Bangkok. Server overload, a micro-outage on the hotel's side, a Wi-Fi channel handover — your tunnel disconnects for three seconds. Without a kill switch, your OS keeps sending traffic via the default route, meaning the direct Wi-Fi interface. During those three seconds, your HTTPS email leaves with your real IP, your DNS query for Netflix passes through the hotspot's DNS, and your BitTorrent tracker receives your real Thai public IP.

You see nothing. The VPN client reconnects in the background, the interface shows "Connected" again. But those three seconds of leakage have already been logged by trackers, ISP logs, and potentially the anti-VPN counters of streaming services. Under the Investigatory Powers Act in the UK or the DMCA in the US, a single un-tunnelled peer-to-peer connection is enough to trigger a notice — the defence "I had a VPN" doesn't hold against a timestamped log.

The kill switch is the structural response. Rather than relying on tunnel stability (which can never be 100% guaranteed), it installs firewall rules that make any traffic outside the tunnel impossible. Tunnel up: traffic flows. Tunnel down: nothing leaves, your internet appears cut off, you fix it manually. Same logic as a fire door — you accept a momentary inconvenience to guarantee airtight containment. The concept is documented on Wikipedia: Internet kill switch.

The 2 types of kill switch: app vs system

The confusion between the two types is fuelled by vendor marketing, which often presents the "per-app kill switch" as a premium feature when it is technically inferior to system mode. Understanding the difference determines whether your VPN actually protects you.

The app kill switch — also "App Kill Switch" or "per-app kill switch" — operates at the OS level. You define a list of processes (chrome.exe, qbittorrent.exe) and the VPN client monitors their network state. If the tunnel drops, those processes are killed or blocked via OS hooks. Advantage: you can let other apps continue over the normal connection (a corporate mail client that must stay reachable). Major drawback: everything not on the list passes in the clear. If you only list your browser but Dropbox is syncing in the background, Dropbox exposes your real IP during tunnel drops. False sense of security in the vast majority of use cases.

The system kill switch — Internet Kill Switch on NordVPN, Network Lock on ExpressVPN and Mullvad, "Permanent Kill Switch" on ProtonVPN — operates at the OS firewall level. On Windows, it inserts WFP (Windows Filtering Platform) rules blocking all outbound traffic outside the tunnel interface. On macOS, it programs pfctl. On Linux, it manipulates iptables or nftables to forbid any route outside tun0 or wg0. Advantage: structural protection, independent of the app list and client bugs. Drawback: if the VPN service crashes without cleaning up its rules, internet remains blocked until manual intervention. Rare on mature clients, but worth knowing.

General rule. Unless you have a specific use case (separate corporate VPN, traffic legitimately outside the tunnel), system mode is the only genuinely protective option. App mode is a comfort feature, not a sensible default.

How to enable the kill switch on NordVPN, ExpressVPN, Surfshark, ProtonVPN

The four major VPNs in 2026 all implement a kill switch, but with different naming conventions and defaults. Here is the exact procedure for each, current as of May 2026.

NordVPN

Windows/macOS desktop: Settings → Kill Switch. Two separate toggles — "Internet Kill Switch" (system mode, must be enabled) and "App Kill Switch" (app mode, optional). The Internet Kill Switch is disabled by default at installation — this is the most common mistake. Linux: nordvpn set killswitch on, verify with nordvpn status. Android: the system setting Settings → Network → VPN → NordVPN gear icon → "Permanent VPN" + "Block connections without VPN" is more reliable than the option built into the app. iOS: no dedicated button, but the "Connect on demand" profile in advanced settings plays this role at the system level.

ExpressVPN

ExpressVPN calls its system kill switch Network Lock. Windows/macOS: Settings → General → "Stop all internet traffic if the VPN disconnects unexpectedly". Enabled by default since 2023 — a notable differentiator from NordVPN. Linux (CLI expressvpn): Network Lock is active automatically on connection. Android: "Network Protection" option. iOS: "On-Demand" profile, like all others.

Surfshark

Surfshark offers a simple Kill Switch, with no variants — system mode by default. Settings → VPN → Kill Switch → enable. Linux: surfshark-vpn killswitch on. A more minimal client in terms of options, which reduces misconfiguration risk but limits granularity.

ProtonVPN

ProtonVPN offers two distinct modes. Standard Kill Switch blocks traffic only when the connection drops unexpectedly. Permanent Kill Switch is stricter — it blocks all traffic outside the tunnel even when the user voluntarily disconnects — useful for journalists or activists who want to eliminate any risk of forgetting. Settings → Connection → Kill Switch or Permanent Kill Switch. See the ProtonVPN Kill Switch page for per-OS implementation details.

Edge cases: Linux, router, iOS/Android mobile

Non-standard setups deserve separate treatment because the kill switch logic is implemented differently there — sometimes with no setting in the app at all.

Linux. Official clients (NordVPN, ExpressVPN, ProtonVPN) use iptables or nftables injected at tunnel startup. If you use WireGuard or OpenVPN directly without a proprietary client, configure it manually via PostUp/PostDown in the WireGuard config. Mullvad publishes excellent open-source guides reproducing this config. The Tails distribution natively implements an equivalent kill switch via pre-configured iptables.

Router. VPN at the router level (DD-WRT, OpenWRT, AsusWRT-Merlin, pfSense) protects every device on the network but requires an explicit kill switch config — never active by default. On pfSense, create a gateway group with the VPN as primary and no fallback: if the VPN drops, routing fails rather than falling back to cleartext WAN. The most robust config for a household where TVs, consoles, and IoT devices all route through the tunnel. For the underlying radio encryption, our WPA2 vs WPA3 Wi-Fi security guide explains why WPA3 closes the KRACK gap and hardens the layer underneath the VPN tunnel.

iOS. iOS doesn't expose a direct kill switch API. Clients rely on the "Connect on Demand" profile from the Network Extensions framework, which forces reconnection on any outbound traffic. Functionally equivalent in 95% of cases, with a window of a few hundred milliseconds during reconnection. Sufficient for everyday use, with limitations for strict privacy.

Android. Since Android 8, the system setting "Always-on VPN" + "Block connections without VPN" under Settings → Network → VPN → app gear icon. This is the most robust kill switch available on mobile — OS-level, it survives app crashes. Systematic recommendation: system-level Always-on in addition to the app kill switch; the two layers complement each other.

When the kill switch can be counterproductive

The kill switch isn't an absolute — there are three operational contexts where it becomes a nuisance or even a blocker. Knowing them lets you disable it temporarily and deliberately, rather than in a panic.

Hotel or airport captive portal. The public Wi-Fi operator intercepts your first HTTP request and redirects it to an acceptance page. This interception happens before the tunnel is established — a strict system kill switch blocks the request to the captive portal, making you unable to authenticate and therefore unable to access the internet. Modern clients (NordVPN, ExpressVPN, ProtonVPN) handle this via a temporary exception for detected captive portal requests. If detection fails, temporarily disable the kill switch, accept the portal, reconnect the VPN, re-enable. Procedure in our public Wi-Fi guide 2026. On the road, switching to your phone's tethering remains the simplest option: see mobile hotspot vs public Wi-Fi security for the throughput/exposure trade-off.

Corporate network with proxy. On some corporate networks, internet access runs through a corporate proxy (SSL inspection, DLP). Enabling a commercial VPN with kill switch cuts off access to that proxy. The two are incompatible; disable the commercial VPN during those sessions.

802.1X conference authentication. Some professional events deploy 802.1X with certificate-based auth. The kill switch active at EAP handshake time can cause the protocol to fail — certain 802.1X variants require out-of-tunnel requests. A rare but documented edge case.

Pragmatic rule: if the kill switch is blocking you, disable temporarily, understand why, re-enable as soon as possible. Structural protection is worth more than a permanent exception.

Testing your kill switch in 30 seconds

The feature is useless if it's never been verified at least once. Here is the minimal procedure to confirm your kill switch is doing its job — applicable in under a minute.

Step 1 — Start a large download. Begin downloading a file of several hundred megabytes (Linux ISO, Docker image, video) via your browser or a legal torrent client. Verify the transfer rate has been stable for 10–15 seconds.

Step 2 — Manually disconnect the tunnel. In the VPN client, click Disconnect. Do not close the client; just disconnect from the server. This is exactly what happens during a real network drop.

Step 3 — Watch the download. If the kill switch is active and working, the download must stop immediately — not in 5 seconds, immediately. The browser typically shows "connection lost" or "ERR_NETWORK_CHANGED". If the download continues, your kill switch is misconfigured or inactive. If only the download stops but another app (Spotify, Slack) keeps loading, you're in app mode rather than system mode.

Step 4 — Verify no residual leak. While the tunnel is still down, open our DNS Leak Test tool or an equivalent service (ipleak.net, dnsleaktest.com). No public IP, DNS, or IPv6 address should appear — everything should fail with a network error. If your real IP shows up, the kill switch firewall doesn't cover all traffic. Typical case: IPv6 not blocked when IPv4 is.

Step 5 — Reconnect and confirm. Reconnect the VPN. The IP shown by the tool should revert to the VPN server's address. Test a second time after a few minutes to ensure no residual state skews the result. The full procedure is detailed in our guide on how to check your VPN works, which covers the minimal checks to run at the start of every session.

Going further

The kill switch is a setting you enable once and forget — like a seatbelt. Pointless on 99% of journeys, indispensable on the one percent where it prevents an invisible and irreversible leak. On modern VPNs, the implementation is mature and the running cost is zero; there is no good reason not to enable it in system mode from your very first session.

For profiles beyond everyday use (journalists in sensitive environments, protected sources), layering kill switch + Android Always-on + VPN router + a dedicated machine constitutes standard OPSEC. For 95% of use cases — streaming, privacy browsing, public Wi-Fi, legal torrenting — system kill switch + auto-connect on unsecured Wi-Fi closes all structural exposure vectors. Without a kill switch, the tunnel is a convenience; with one, it's a protection.

The NCSC and similar national cybersecurity agencies emphasise in their guidance for remote and mobile workers the importance of an uninterrupted chain of trust on untrusted networks — this is precisely what the kill switch guarantees on the client side. Our complete audit in 9 tests treats it as a priority control, to be verified once per quarter.

Article published on 29 May 2026. Methodology: internal tests of kill switches on NordVPN (Internet Kill Switch + App Kill Switch), ExpressVPN (Network Lock), Surfshark (Kill Switch), ProtonVPN (Kill Switch + Permanent Kill Switch) on Windows 11, macOS Sonoma, Ubuntu 24.04 LTS, and Android 14 between March and May 2026. Verified by Wireshark capture and tcpdump during manual tunnel triggers. Additional references: ProtonVPN public documentation, Mullvad WireGuard guides, NCSC guidance on remote working. Reproducible test procedure available on editorial request via contact.