How to verify a VPN kill switch

Quick answer: With the kill-switch mode enabled, a protected request made while the VPN tunnel is confirmed down should wait or fail; it should not succeed through your baseline ISP address. Record the normal address with the VPN off, the VPN address while connected, and what happens during an observed interruption. A test where the whole network went offline, or the tunnel never visibly dropped, is inconclusive.

Important constraint: Decide which disconnect state your setting claims to protect before testing it. Proton VPN’s standard mode and Mullvad’s built-in kill switch address accidental tunnel loss, while their stronger modes cover deliberate disconnect differently. On Android, Always-on VPN alone is distinct from Block connections without VPN. A manual-disconnect “failure” may simply test a state the selected standard mode was never meant to block. Sources: Proton kill switch, Mullvad app guide, Android VPN guidance.

Run this on a personal, noncritical device and network when a brief loss of connectivity is acceptable. Avoid testing during work that requires continuous access or during an activity that depends on privacy. Use harmless requests to an IP-observation endpoint and, optionally, a DNS test you trust. Do not send secrets. The procedure gives you evidence about your device, selected mode and observed states. It cannot certify every future network transition or every app.

Identify what the selected mode promises

“Kill switch” can describe more than one behavior. A standard setting may intervene when the VPN drops unexpectedly but allow ordinary traffic after the user chooses to disconnect. A lockdown or persistent setting may keep non-VPN traffic blocked until the VPN is restored or the stronger mode is disabled. The exact behavior can vary by operating system and app version, so record those before interpreting a result.

These are current Proton, Mullvad and Android documentation examples, not measured provider reliability rankings. Check the mode description in the actual app and operating system before the test. If a feature’s platform availability has changed, the current in-app setting and vendor guidance control what can reasonably be expected.

Decide what is protected traffic for your configuration. A browser intentionally excluded by split tunneling can use the ordinary connection by design; it cannot be the sole probe of the protected path. Conversely, a browser test says little about a desktop app if only the latter is protected. Write down any proxy, second VPN, firewall, browser DNS-over-HTTPS setting or custom DNS service that might affect the observation. Keep the intended security configuration rather than turning off tools merely to make the test appear clean.

Make a compact five-state record

Choose an external endpoint that reports the request’s public IP address, or use one you control. Refreshing a page once is easy to miss during a short interruption, so make repeated harmless requests while you observe the VPN app or its log. Record time, OS version, VPN app version, mode, network type, tunnel status, whether each request completed, observed IPv4/IPv6 address where available, and DNS result. You need an actual tunnel-down interval to interpret the central test.

The useful comparison is State 2 against States 0 and 1. If the protected request succeeds via the baseline ISP IPv4 or IPv6 address while the tunnel is confirmed down, the observed configuration did not block that traffic in that state. Stop relying on that configuration for privacy-sensitive activity until the cause is fixed and the result is rechecked. A request that fails during the gap and later succeeds through VPN egress is the expected pattern for that sampled interruption.

If the underlying Wi-Fi or mobile network disappeared entirely, failed requests do not establish that the kill switch acted: the device had no route regardless of VPN behavior. A handoff that completes too fast to establish a tunnel-down interval is also inconclusive. Repeat under a safer, observable condition rather than calling the first attempt a pass. Do not induce a failure by exposing real credentials, private traffic or another person’s network to risk.

Read a result as failure, inconclusive or limited pass

Write the result beside the state that produced it. This avoids collapsing a full device test into a single “IP was different” screenshot.

Even a limited pass is bounded. It cannot show what happens on an untested Wi-Fi network, after a future update, during a different server switch, or from another app. Proton’s current help page documents specific macOS and Apple-service DNS caveats, which illustrate why a provider-wide “all traffic is always blocked” conclusion would exceed a single local observation.

Check DNS, IPv6 and app exclusions separately

A web page that shows a VPN IPv4 address answers one question: where that request appeared to exit. It does not prove that every DNS query or IPv6 connection followed the same path. If the device has IPv6 access in State 0, include an IPv6-capable observation in the connected and interruption states. If an app is excluded by split tunneling, label it excluded in the log rather than treating its normal ISP egress as a kill-switch failure. Test an application that the VPN is meant to protect, especially if the use case extends beyond a browser.

Use a DNS observation as another bounded check. Mullvad’s DNS guidance explains that browser DNS-over-HTTPS, custom DNS and system settings can affect what a DNS leak test reports. A browser may resolve through its own path while another application uses the operating system resolver. Note those settings in the log and interpret the result for the path observed. If you temporarily change a setting for diagnosis, restore the intended configuration afterward and repeat the relevant check in that real configuration.

On Android, confirm both the app’s mode and the system’s Always-on and Block connections without VPN settings. Check any permitted or excluded applications before drawing a device-wide conclusion. On a desktop, distinguish the VPN app’s status from the mere presence of network connectivity. A green “connected” display after reconnection is useful but does not tell you what an attempted request did during the preceding gap; that is why timestamps and repeated probes matter.

Keep a result you can revisit

Save a short record with the configuration, observations and conclusion, without recording private browsing data. For example: “On this OS/app version and standard accidental-drop mode, the tunnel was visibly down from 14:02:10 to 14:02:14; five protected requests failed during the gap; a later request used the VPN address.” That would be a limited pass for the observed gap. If the interval could not be confirmed, mark it inconclusive. If a protected request used the baseline address, investigate before trusting the mode.

Repeat the check after major OS or VPN-app updates, a change in split-tunnel rules, or a new network arrangement. The objective is to know what your selected configuration did in a specific state and to catch an obvious exposure path before depending on it. The privacy hub covers broader choices; this procedure remains a local verification step rather than a promise that any provider is leak-proof.