Appearance
How to test your VPN kill switch
A kill switch is a promise — "if the tunnel dies, nothing leaks" — and like every promise in security, it's worth ten minutes to verify rather than a lifetime of assuming. The test is simple: watch your public IP continuously, force the tunnel down the ungraceful way, and see whether the world glimpses your real address in the gap. This guide walks it end to end.
Maintained by the ipconfig.io team · Reviewed 1 July 2026
What the kill switch is actually for
VPN tunnels drop silently: servers go down, Wi-Fi blips, processes crash, laptops wake from sleep faster than the client reconnects. Without a kill switch, every app on your machine falls back to the bare connection instantly — same downloads, same sync, same open tabs, now over your real IP — with no visible sign anything changed. The kill switch's job is to make that failure loud: no tunnel, no traffic.
The test
1. Start the watcher. In a terminal, fetch your public IP once a second:
bash
while true; do curl -s --max-time 2 ipconfig.io || echo "BLOCKED"; sleep 1; doneWith the VPN connected you should see the VPN server's IP repeating. (Confirm it's not your real one before proceeding.)
2. Kill the tunnel ungracefully. Don't press disconnect — that's the graceful path the client controls, and many clients relax the kill switch for it. Simulate a real failure instead:
bash
# Linux/macOS — kill the VPN process outright:
sudo pkill -9 -f openvpn # or wireguard/your client's processOther honest simulations: toggle Wi-Fi off and on mid-loop, or block the VPN server's address in your firewall so the tunnel starves.
3. Read the verdict.
| Loop output after the drop | Meaning |
|---|---|
BLOCKED / timeouts until the tunnel returns | Kill switch working — fail closed |
| Your real IP appears, even for one line | Kill switch failed — that's a leak window every app on your machine shares |
| VPN IP again within a second or two | Client auto-reconnected faster than a 1s poll — retest with the firewall-block method to hold the tunnel down longer |
4. Test the boot gap too. Reboot with "auto-connect on startup" enabled and run the loop immediately: some setups have a window between network-up and tunnel-up. The permanent/system-level kill switch modes (some clients call it "always-on" or "network lock") exist precisely for this.
If it failed
Check the setting exists and is set to the strongest mode (system-wide, not per-app), update the client, and re-test. If the client simply doesn't offer a real fail-closed mode, that's worth knowing before you rely on it — the honest list of what a VPN does and doesn't cover is the bigger picture, and a firewall rule that only allows traffic via the tunnel interface is the DIY fail-closed for advanced setups.
Frequently asked questions
What is a kill switch? A fail-closed rule: when the VPN tunnel drops, all traffic stops instead of falling back to your real connection.
How do I test it? Loop curl ipconfig.io every second, then kill the VPN process or cut the network — not the app's disconnect button. Failures should replace answers; your real IP should never print.
Why not the disconnect button? It's the graceful path — clients often relax the switch for deliberate disconnects. The switch exists for crashes and drops, so that's what you simulate.
Is it on by default? Frequently not, or only in a weak mode. Find it in settings and prefer the system-wide variant.
Next steps
- Check if your VPN is leaking your real IP — the steady-state test to run before this failure test.
- Does a VPN hide everything? — the honest boundary of what the tunnel covers.
- What is a DNS leak? — the other quiet failure worth testing while you're here.