VPN Kill Switch Explained: How It Works, When You Need It, and How to Test It

Quick answer

Use the guide, then verify the browser-visible VPN route: visible IP, DNS, WebRTC, IPv6, and browser/session signals. Save a Privacy Receipt only after comparing the before and after state.

Article to tool flow

VPN setup advice is hard to trust if the visible route is never checked.

ProblemVPN setup advice is hard to trust if the visible route is never checked.

Run testRun a before/after VPN Leak Test in the same browser session.

ResultReview the exposure estimate and each signal category instead of treating one green or red flag as the whole answer.

Next actionFix one setting at a time, reconnect the VPN, and retest.

Run VPN Leak Test Open Privacy Receipt DNS Leak Test WebRTC Leak Test IPv6 Leak Test

A Privacy Receipt is a reduced, share-safe diagnostic summary. It removes raw IP addresses, exact city, full User-Agent, resolver IPs, and WebRTC candidates. It is not proof of anonymity, a VPN provider audit, or a security certificate.

Summary FAQ

What should I do after reading this article?

Run the linked VPN Leak Test first, then compare one related tool if the result does not match what you expected.

What should I save or share?

Use the Privacy Receipt when you need a safe summary. Avoid posting raw IPs, exact location, full User-Agent, resolver IPs, or WebRTC candidate strings publicly.

Does a clean-looking result mean everything is private?

No. MyIPScan checks visible browser/session signals in this context. It helps you find review items, but it does not certify a VPN, device, provider, account, or network.

Internal links for the next step

VPN Setup and Troubleshooting HubOpen the next step in the diagnostic path. VPN Leak TestOpen the next step in the diagnostic path. Privacy ReceiptOpen the next step in the diagnostic path.

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

A VPN kill switch is a safety mechanism that monitors the state of your VPN tunnel and immediately blocks all network traffic if that tunnel drops — preventing your real IP address from being exposed over an unprotected connection. It solves a specific, concrete problem: when a VPN connection fails, your operating system does not wait for instructions. It instantly reroutes your traffic through your regular internet connection, as if the VPN never existed. Without a VPN kill switch, that rerouting happens silently, and your real IP address becomes visible to every server you connect to.

The Core Mechanism

Under the hood, a VPN client runs a watchdog process or listens for OS-level network interface events. The moment it detects the tunnel has gone down, it pushes firewall rules that block all outbound and inbound traffic outside the VPN interface. On Linux, this typically means iptables or nftables rules. On Windows, the Windows Filtering Platform (WFP) is used. On macOS, the built-in pf packet filter handles enforcement. These rules stay in place until the tunnel is successfully re-established, at which point normal routing resumes.

Think of it like a circuit breaker: it cuts the power the moment it detects a fault, rather than preventing the fault from happening in the first place. That distinction matters. A kill switch is reactive, not proactive. There is always a brief window — milliseconds to seconds — between the moment the tunnel drops and the moment the firewall rules activate. Any traffic that exits during that gap travels unprotected. This is an inherent limitation of the approach, not a flaw unique to any one provider.

VPN tunnel drops are also a normal network event, not a rare edge case. Unstable Wi-Fi, server-side timeouts, mobile network handoffs, and sleep/wake cycles all cause them. Understanding how network transport protocols handle connection interruptions helps explain why no tunnel can be assumed to stay up indefinitely.

What a Kill Switch Does Not Cover

A kill switch only addresses one specific threat: IP exposure caused by the VPN tunnel dropping. It does not protect against WebRTC leaks, a separate and common vulnerability where browsers expose your real IP address through STUN requests — even while the VPN tunnel is fully active and the kill switch has never fired. These are two distinct problems requiring two distinct checks.

Similarly, if your VPN client does not explicitly block IPv6 traffic, that traffic can bypass the VPN kill switch entirely and route directly through your ISP connection. Many users have kill switches enabled while unknowingly leaking their IPv6 address on every connection.

The only way to know whether your setup is actually protecting you is to test it. Run a VPN leak test, a WebRTC leak test, and an IPv6 leak test while your VPN is connected to establish a baseline — then check what happens when the tunnel is interrupted. The results will tell you far more than any marketing claim on a VPN provider’s feature page.

System-Level vs. App-Level Kill Switch: Which One Do You Need?

The two architectures solve the same problem in fundamentally different ways, and choosing the wrong one for your situation can leave you exposed when it matters most.

How Each Architecture Works

A system-level kill switch (also called a network-level or OS-level kill switch) operates directly at the operating system’s firewall layer — using mechanisms such as iptables or nftables on Linux, the Windows Filtering Platform on Windows, or pf on macOS. When the VPN tunnel drops, the firewall rules block many app traffic paths while the firewall rule is active, depending on implementation. Some app paths may be blocked while the rule is active, but behavior depends on the OS, VPN client, and network stack.

An app-level kill switch (sometimes called a per-app or split-tunnel kill switch) takes a narrower approach: it only cuts internet access for the specific applications you’ve designated as protected. Every other app on the device continues using your regular, unencrypted connection as if the VPN never existed.

Comparison at a Glance

Feature	System-Level Kill Switch	App-Level Kill Switch
Traffic blocked on VPN drop	All device traffic	Selected apps only
Non-protected apps during drop	Fully blocked	Continue unprotected
Typical use case	Journalists, activists, torrent users, sensitive data handling	Users needing uninterrupted access to specific services
Risk of connectivity confusion	Higher — full internet loss if VPN is off	Lower — other apps stay online
Overall reliability	Generally stronger	Depends on implementation

Which One Fits Your Situation

If you handle sensitive data — journalism sources, legal communications, or activity tied to financial accounts such as VPN for crypto accounts and IP linkability risks — a system-level kill switch is the correct choice. There is no safe traffic to leave unprotected. The same applies to anyone routing torrents through a VPN: an app-level kill switch that only covers the torrent client still leaks every other application’s traffic the moment the tunnel drops.

App-level kill switches are a reasonable trade-off when you need a business VoIP tool or a local network printer to remain accessible without interruption, while keeping a browser or download client strictly inside the tunnel. The key is being deliberate about what you leave unprotected — not relying on default settings you haven’t reviewed.

Implementation Quality Is Not Uniform

Enabling a VPN kill switch toggle in a VPN app does not guarantee zero leaks. On macOS, sandboxing constraints can limit how reliably third-party apps enforce firewall rules. A provider like Mullvad implements its kill switch using iptables and nftables rules that persist even if the VPN application itself crashes — a meaningfully stronger guarantee than software-only enforcement. For a detailed look at providers that treat kill switch robustness as a first-class feature, see this Mullvad vs IVPN kill switch comparison.

One leak vector that neither kill switch type addresses by default is IPv6. Many VPN tunnels carry only IPv4 traffic, leaving IPv6 packets to route directly over your ISP connection if the implementation doesn’t explicitly block them. Before relying on any VPN kill switch, run an IPv6 leak test and a full VPN leak test to confirm your implementation actually covers both protocol families.

Why Your VPN Connection Drops and When a Kill Switch Saves You

VPN tunnels drop more often than most users expect, and the causes range from mundane to unavoidable. Understanding each scenario makes it clear why a kill switch is not just a nice-to-have feature — and also why enabling it is not the end of the story.

Common Causes of VPN Tunnel Drops

• Unstable Wi-Fi: Signal fluctuations cause momentary packet loss that can exceed the VPN protocol’s timeout threshold, forcing the tunnel to close. The kill switch intervenes by blocking all outbound traffic the moment the tunnel state changes, preventing your real IP from being transmitted.
• Network switching: Moving from Wi-Fi to mobile data — or between two Wi-Fi networks — forces the OS to assign a new network interface. The VPN client must re-establish the tunnel on the new interface, and during that gap your traffic would otherwise route unprotected.
• ISP throttling: Sustained throttling of specific ports or protocols can starve the VPN connection of bandwidth until the session times out, triggering a drop mid-session.
• Server overload during peak hours: When a VPN server becomes overloaded, it may forcibly terminate sessions. This server-side disconnection is outside your control, making an active kill switch the only reliable safeguard.
• Device sleep and hibernate states: This is among the most dangerous scenarios. When a device wakes, the OS restores network interfaces before the VPN client finishes re-establishing the tunnel, creating a window of unprotected traffic. VPN kill switch implementations that operate at the OS firewall layer handle this more reliably than app-level switches.
• OS network stack resets after software updates: A system update can reset firewall rules or restart network services, briefly bypassing any in-memory kill switch configuration that has not been written as persistent rules.

The Highest-Risk Moments

Three scenarios stand out as particularly high-risk. Switching networks on a laptop at a cafГ© is a classic exposure point — the moment you toggle from one Wi-Fi to another, your device is live on the new network before the tunnel reconnects. Waking a phone from sleep on a different network — say, arriving home after commuting — compounds the problem because the device may aggressively attempt to sync apps before the VPN is ready. If you experience persistent drops on mobile, the causes and fixes are covered in detail in why your VPN keeps disconnecting on iPhone. Server-side disconnections during peak hours are invisible to the user until after the fact, which is precisely when passive kill switch monitoring earns its value.

The Limits You Must Understand

A kill switch only activates after the VPN connection drops. It does not protect traffic that was already transmitted in the brief interval before the disconnection event was detected. That exposure window is typically small, but it exists, and no kill switch implementation eliminates it entirely.

There is a second, frequently overlooked gap: IPv6. Many VPN tunnels only carry IPv4 traffic by default, and if the kill switch does not explicitly block IPv6 packets, those requests route directly over your ISP connection, fully unprotected. Not all VPN clients handle this automatically. You must confirm that your client blocks IPv6, or disable IPv6 at the OS level entirely, to close this leak path. To verify your actual exposure, run an IPv6 leak test and a VPN leak test after enabling your VPN kill switch — because assuming the feature works correctly, without testing it, is precisely how leaks go unnoticed.

How to Enable a Kill Switch on Every Major VPN Client

Finding the VPN kill switch toggle varies more than it should across VPN clients. Below are exact locations for the five most widely used apps, plus what each implementation actually does under the hood.

ExpressVPN — Network Lock

ExpressVPN calls its kill switch Network Lock. It uses OS-level firewall rules to block all traffic outside the encrypted tunnel. By default it is system-level — every application on the device is covered, not just the VPN client.

1. Open the ExpressVPN app and click the hamburger menu (в‰Ў) -> Options (Windows) or Preferences (Mac).
2. Select the General tab.
3. Check Stop all internet traffic if the VPN disconnects unexpectedly (Network Lock).
4. Click OK to save.

Note for macOS: Some providers, including ExpressVPN on newer macOS versions, implement the VPN kill switch through the built-in Always On VPN profile via the Network Extension framework rather than a separate toggle. The protective behavior is identical — the setting location in System Settings differs.

NordVPN — Kill Switch Tab

NordVPN offers both an app-level kill switch (blocks only the NordVPN app’s traffic) and a system-level Internet Kill Switch (blocks all traffic). You can choose which mode to use.

1. Open NordVPN -> click the gear icon -> Kill Switch tab.
2. Toggle Internet Kill Switch on for system-level protection, or App Kill Switch to restrict specific applications only.

Mullvad — Lockdown Mode

Mullvad’s implementation is among the most robust available. Its firewall rules using iptables and nftables on Linux persist even if the VPN application crashes — a true system-level block.

1. Open the Mullvad app -> click the Settings (gear icon).
2. Under the VPN settings section, toggle Lockdown Mode on.

Lockdown Mode is system-level by default; there is no app-level alternative.

ProtonVPN — Permanent Kill Switch

ProtonVPN provides two kill switch tiers: a standard kill switch that activates when the tunnel drops, and a permanent kill switch that blocks all traffic even when you are not connected to ProtonVPN at all.

1. Open ProtonVPN -> click the hamburger menu -> Settings.
2. Under the Connection tab, locate the Kill Switch toggle.
3. Choose Kill Switch (standard) or Permanent Kill Switch depending on your risk level.

Both modes are system-level on Windows and macOS.

Private Internet Access — VPN Kill Switch

1. Open the PIA app -> click the hamburger menu -> Settings.
2. Go to the Privacy tab.
3. Enable the VPN Kill Switch toggle.
4. Optionally enable Advanced Kill Switch to block traffic even when PIA is not running.

The standard option is app-level; Advanced Kill Switch is system-level.

After Enabling: Verify, Don’t Just Trust the Toggle

A kill switch that is toggled on is not automatically a kill switch that is working correctly. Sleep/wake cycles and network interface changes are common failure points. After enabling any VPN kill switch, run a full VPN leak test to confirm your real IP is not exposed. Also run an IPv6 leak test separately — IPv6 traffic can bypass a VPN kill switch entirely if the VPN client does not explicitly block IPv6 packets, since many tunnels carry only IPv4 by default.

Finally, enabling a VPN kill switch without also configuring your VPN to launch at login leaves a gap: your device connects to the internet before the VPN tunnel is established. Make sure you also auto-connect your VPN on startup so the kill switch is in place from the moment your network interfaces come up.

VPN Kill Switch on Android and iOS: Mobile Setup Guide

Mobile devices handle VPN kill switches very differently depending on the operating system — and the gap between Android and iOS is significant enough to change how much you can actually rely on this protection.

Android: A True System-Level Kill Switch Built Into the OS

Android 7.0 and later ships with a native kill switch that operates independently of any VPN app you install. The Always-on VPN setting combined with Block connections without VPN enforces traffic blocking at the OS level, meaning no application on your device can send data outside the tunnel if the VPN drops. This is a system-level control, not an app-level one — it survives app crashes and applies to every process on the device.

To enable it on stock Android:

1. Open Settings -> Network & internet -> VPN
2. Tap the gear icon next to your VPN profile
3. Enable Always-on VPN
4. Enable Block connections without VPN directly beneath it

On Samsung devices, this is found under Settings -> Connections -> More connection settings -> VPN. The toggle names remain the same.

One important caveat: even with this enabled, IPv6 traffic can bypass the tunnel if your VPN client does not explicitly handle IPv6 blocking. Check your VPN app’s settings for an IPv6 disable or block option, and verify the result with an IPv6 leak test after connecting.

iOS: Best-Effort Protection, Not a True Kill Switch

Apple’s restrictions on the Network Extension framework mean that no third-party VPN app can implement a genuine system-level kill switch on iOS. Brief traffic leaks of several seconds can and do occur during tunnel reconnection events — for example, when switching between Wi-Fi and cellular, waking the device from sleep, or after the OS temporarily suspends the VPN extension. There is no iOS equivalent to Android’s Block connections without VPN toggle.

ProtonVPN, Mullvad, and NordVPN all offer a VPN kill switch toggle within their iOS apps. In practice, these work by attempting to re-establish the tunnel as quickly as possible and refusing to route traffic through unprotected interfaces — but this is enforced at the app layer, not the kernel layer. The protection is meaningful for sustained disconnections, but it cannot guarantee every exposure window is removed during brief reconnection windows.

If you use a VPN to protect a crypto wallet or exchange account on your iPhone, this limitation matters directly. Read about VPN for crypto accounts and IP linkability risks to understand why even a short unprotected window can be enough to associate a transaction with your real IP address. iOS VPN users in high-sensitivity contexts should treat the VPN kill switch as a best-effort safeguard, not a guarantee.

After any reconnection event — switching networks, coming out of airplane mode, or a simple tunnel drop — run a VPN leak test to confirm your IP is still masked and check for a DNS leak as well. If you notice your VPN reconnecting frequently, understanding why your VPN keeps disconnecting on iPhone can help you reduce the frequency of those exposure windows in the first place.

IPv6 is equally a concern on iOS. Not all iOS VPN clients block IPv6 by default, and an unblocked IPv6 address leaking during reconnection defeats the purpose of the VPN kill switch entirely. Confirm your client’s IPv6 handling in its settings before relying on it for sensitive activity.

Common Kill Switch Myths You Should Stop Believing

Marketing copy around VPN kill switches tends to be optimistic to the point of being misleading. Here are five persistent myths — and why each one falls apart under scrutiny.

Myth 1: A Kill Switch Is a Privacy Certificate

A kill switch does one specific thing: it blocks traffic if the VPN tunnel drops. That’s it. It has no effect on browser fingerprinting, cookies, account logins, or WebRTC leaks. Even with an active VPN tunnel and a functioning kill switch, browsers can expose your real IP address through WebRTC STUN requests — a completely separate threat that a kill switch is not designed to prevent. Anonymity requires far more than a single feature. Readers who’ve encountered oversimplified marketing around this should find VPN features explained in plain English a useful corrective.

Myth 2: All Kill Switches Work the Same Way

They don’t — not even close. A system-level kill switch operates at the OS firewall layer and blocks all traffic device-wide, while an app-level implementation only controls traffic from the VPN client itself. Beyond that architectural difference, implementation quality varies by provider, operating system, and even protocol. On macOS, for example, sandboxing and system integrity protections can limit how reliably a third-party kill switch enforces its rules. Enabling a toggle in a VPN app is not a guarantee of zero data leaks in all scenarios.

Myth 3: A Kill Switch Protects You from Malware and Surveillance

A kill switch monitors VPN tunnel state and blocks unencrypted traffic when the tunnel fails. That’s the entire scope of its function. It does nothing to protect against malware on your device, traffic analysis by the VPN provider itself, or any form of surveillance that doesn’t depend on your IP address being exposed through a dropped connection. Conflating these protections is a category error.

Myth 4: You’ll Always Know When Your VPN Drops

This is only partially true, and the exceptions matter. Some kill switch implementations silently block all traffic when triggered — which from the user’s perspective looks identical to a broken internet connection, not a VPN kill switch activation. There’s no alert, no notification, no clear indication of what happened. This is particularly common during sleep/wake cycles, where the OS restores network interfaces before the VPN client re-establishes its tunnel, creating a window of unprotected traffic before the block kicks in. Run a VPN leak test after waking your device from sleep to check whether your implementation actually holds.

Myth 5: Kill Switch + VPN = Privacy Certificate Claim Claim

This is the most damaging myth because it sounds so reasonable. A kill switch addresses one leak vector: IP exposure during disconnection events. It does not block IPv6 traffic that your implementation hasn’t explicitly accounted for , does not prevent DNS queries from escaping outside the tunnel if DNS leak protection is absent , and does not neutralise WebRTC exposure. Run an IPv6 leak test and a DNS leak test independently of your VPN kill switch to understand what your actual exposure looks like. The EFF’s Surveillance Self-Defense guide on choosing a VPN covers the broader privacy context that no single VPN feature — kill switch included — can substitute for.

Do You Really Need a Kill Switch? Use Cases That Make It Essential

Whether a VPN kill switch belongs in your setup depends entirely on what you’re protecting and what happens if your real IP address appears in a log. Here’s a clear breakdown by risk tier.

Essential — Higher-Priority Review

• Journalists and activists: Any VPN drop that exposes a real IP to a network observer can compromise a source or reveal a location to a hostile government. A kill switch is the minimum viable protection here, not a luxury feature.
• Torrent users: Swarm participants log the IP addresses of every peer. A single two-second tunnel drop writes your real IP into potentially dozens of third-party logs. There is no undo.
• Crypto traders: Exchanges and on-chain analytics firms correlate IP addresses with wallet activity to build identity profiles. A disconnection at the wrong moment creates a linkable data point that persists permanently. See VPN for crypto accounts and IP linkability risks for a deeper breakdown.
• Public Wi-Fi users: On untrusted networks, any unencrypted traffic — even momentary — is exposed to the local network. A kill switch ensures that if the tunnel drops, nothing travels in plaintext.

Recommended — Meaningfully Reduces Risk

• Remote workers: Corporate resource access over VPN carries confidentiality obligations. A kill switch prevents accidental exposure of internal traffic if the tunnel fails mid-session.
• Frequent network-switchers: Moving between Wi-Fi, mobile data, and ethernet creates multiple tunnel-drop events per day. Kill switches are most likely to activate in exactly these transitions.
• Device sleep/wake users: The OS restores network interfaces before the VPN client re-establishes the tunnel, creating a reliable window of unprotected traffic every time the device wakes.

Probably Unnecessary

• Casual streamers geo-unblocking content: If a brief disconnection simply interrupts playback with no privacy consequence, a VPN kill switch adds friction without meaningful benefit.

Keep in mind that regardless of use case, a kill switch does not prevent WebRTC leaks — your browser can expose your real IP through WebRTC even when the tunnel is intact and the kill switch is armed. It also cannot protect traffic that left your device in the seconds before the disconnection was detected. It is one layer of a broader privacy posture, not a complete solution on its own.

Before You Rely on Your Kill Switch: Action Checklist

1. Enable the VPN kill switch in your VPN client settings — confirm it operates at the system level, not just the app level.
2. Enable IPv6 blocking explicitly, or disable IPv6 at the OS level. IPv6 traffic can bypass a VPN kill switch entirely if the implementation does not handle it.
3. Set your VPN to auto-connect your VPN on startup so there is no unprotected window between boot and tunnel establishment.
4. Run a VPN leak test at MyIPScan to confirm your real IP, DNS, and IPv6 address are all hidden under the tunnel simultaneously.
5. Also run a DNS leak test separately — a VPN kill switch and DNS leak protection are distinct features, and DNS queries can still escape the tunnel even when the kill switch is active.

For readers who want to evaluate which VPN providers implement kill switches to a high standard, Privacy Guides VPN recommendations and kill switch criteria documents provider-level implementation quality in detail. A kill switch is essential for high-risk users — but only when it’s implemented correctly, tested actively, and combined with DNS protection, IPv6 blocking, and auto-connect.