Guide
How to test a VPN kill switch
Three ways to drop the tunnel without asking the client, what has to stop when you do, and how to test the one case most switches skip: the gap between the machine starting and the client connecting. Written against the clients of late 2026.
What this settles
A kill switch is a promise that when the tunnel fails, nothing falls back to the ordinary network. The client's settings page says whether the promise was made; the test below says whether it is kept, and under which failures. Run it once on any device that leaves the house, and again after a client update. What the switch is for is on the kill switch page.
Three drops, in order of how often they happen. A switch that survives the first and not the second is common, and a switch that survives all three but not the boot gap is more common still.
Before you start
- Turn the switch on in the client, and if it offers a second, stricter mode — permanent, always, at system start — note which you have chosen. The two are tested separately below.
- Start something that moves continuously and shows its own progress: a large download, a long video, a continuous ping in a terminal. A page that is already loaded proves nothing, because it has nothing left to fetch.
- Open an address page in a second window and note the exit's address while connected. You will reload it after each drop.
The three drops
1. Take the network away
Turn Wi-Fi off, or pull the cable, wait a few seconds and turn it back on. The tunnel drops because its path did, and the question is what the client does in the seconds after the network returns and before the tunnel does. The transfer has to stay stopped until the client shows connected again; a transfer that resumes before the client does is running on the bare network.
2. Kill the tunnel without asking the client
End the client's background process directly: its service in Task Manager on Windows, its process in Activity Monitor on macOS, a force stop from the application's settings on Android, or killing its process from a terminal on Linux. The client was not told to disconnect, so a switch that only acts on a polite disconnect is not involved. The transfer has to stop dead and stay stopped until you restart the client.
3. Change network underneath it
On a phone, turn Wi-Fi off while mobile data is on, so the device moves from one network to another; on a laptop, join a second Wi-Fi network or a phone's hotspot. Mobile operating systems rebuild the tunnel on a new network, and the window during the rebuild is where a weak switch leaks. Reload the address page as soon as the new network is up: the exit's address or nothing at all is a pass, your own address is a fail.
The boot gap
The switch most clients ship applies while the client is running. Between the machine starting and the client connecting, nothing applies, and on a laptop that resumes on a hotel network that gap is long enough for every application that starts with the system to call home over the open connection.
- Set the client to start with the system and connect at launch. Both are usually separate switches, and the second is off by default.
- Restart the machine, and before the client shows connected, reload the address page you left open. A loaded page with your own address is the gap; an error, or a page that waits until the client connects and then shows the exit, is the gap closed.
- If it loaded, look for the stricter mode of the switch — the one described as permanent or applying at system start — and repeat. On Android the system's own setting covers this case regardless of the client, below.
The system's own switch on Android
Android has a switch of its own, in the system settings for the VPN rather than in the client: Always-on VPN, with Block connections without VPN under it. Enforced by the operating system, it covers the client being killed, the network changing and the boot gap alike, which is more than most clients' own switches do. Turn both on, then run the three drops and the restart once more. The client's switch can stay on as well; the two do not conflict, and the system's one is the one that holds when the app does not.
What a pass means
What those checks prove
+A tunnel that fails, however it fails, becomes a dead connection rather than an open one
+The seconds between a network returning and the tunnel returning carry nothing
+On a device that starts on strange networks, the gap before the client connects is closed
What they do not
−They say nothing about what the provider keeps while the tunnel is up — that is answered on the retention pages
−A held switch does not fix a leaking tunnel: DNS and IPv6 are checked separately, in how to check your VPN is working
−A pass is a statement about this client version; an update can move or reset the switch
When the result is unclear
The download paused for a few seconds and then carried on
Read the client before deciding what that was. If it reconnected and the download resumed through the tunnel, the switch held and the pause was the reconnection. If the client still shows disconnected and the download is moving, the switch opened the network after a timeout, and that is a switch that does not hold.
An address check during the resumed transfer settles it: the exit's address means the tunnel is back, your own means it is not.
Nothing stopped, but the client says the switch is on
Then the switch is scoped more narrowly than you assumed. Many clients enforce it only while they consider themselves connected, so a tunnel they were told to close, or one that died with the process, does not trigger it. Look for a second mode with a name like permanent, always or at system start, and repeat the test with that mode on.
If no such mode exists, the switch is decorative under the drops that matter, and the operating system's own switch, where the platform has one, is the one to rely on.
Everything stopped and never came back
That is the switch working. A held switch is a dead connection until the tunnel returns, and a client that cannot reconnect leaves you offline until you tell it to disconnect properly or turn the switch off. On a laptop that is the behaviour you asked for; it only looks like a fault because the fault it prevents is silent.
Only some things stopped
Something is exempt. A split-tunnelling rule, a browser extension with its own proxy, or an application that holds a connection open from before the tunnel was up will keep moving through a held switch, and each of those is a configuration rather than a failure of the switch. Check the exemptions in the client, and then check the setting that governs connections made before the tunnel came up, which some clients leave alone by default.
Same steps, other machines
The rest of the platforms
Every platform has a guide of its own rather than a tab on this one. The steps diverge as soon as the installer opens, and a page that answers three platforms at once answers none of them properly.