What a kill switch is and what it is not

A VPN kill switch is a safety feature designed to stop certain internet traffic if the VPN connection becomes unavailable. Its goal is to limit exposure during moments when your device is no longer sending traffic through the VPN tunnel.

A kill switch does not guarantee anonymity, safety, or uninterrupted access. What it blocks, what it allows, and how quickly it reacts depend on how the VPN client and your operating system implement the feature.

How it works in practical terms

A simple way to model a kill switch is: “If the VPN tunnel is gone (or deemed gone), restrict traffic so it can’t use the non‑VPN path.” In practice, that restriction is usually achieved through firewall/network rule changes or client-side control.

Key operating conditions to understand:

  • Detection: the client must reliably detect when the VPN is connected versus disconnected.
  • Scope: the kill switch may apply to all traffic, only certain apps, or only when specific network paths are in use.
  • Timing: there can be brief windows during reconnect, switching networks (Wi‑Fi to mobile), or client restarts.

Important limitations and exceptions

Common limitations to account for while diagnosing:

  • Performance and availability vary by device, network, location, and time.
  • “VPN down” can mean different things: DNS, routing, authentication, or partial connectivity may behave differently than a full tunnel drop.
  • Some traffic may not be covered by the kill switch depending on configuration and platform behavior.

Because these behaviors can vary widely and aren’t universally consistent, treat kill switch evaluation as configuration-specific rather than a one-time “it works” conclusion.

What to check while diagnosing or configuring

Use a verification route that matches your goals:

  1. Confirm the intended coverage: check whether the kill switch targets all traffic or only specific applications or interfaces. 2. Reproduce the failure scenario: disconnect the VPN intentionally and observe whether traffic is blocked as expected. 3. Include common edge cases: reconnect after Wi‑Fi changes, sleep/wake, and app restarts—these often reveal timing or scope issues. 4.