iPhone VPN Kill Switch Under Failure: Our Reproducible Test
TL;DR: Test an iPhone VPN kill switch by recording your normal IP, connecting the VPN, then triggering five failures one at a time. Before reopening the app, check IP and DNS. App updates deserve special caution because a late-April 2026 report documented tunnel termination and IP exposure. Results below remain pending.
What a kill switch on iPhone actually is (and what it isn’t)
As of September 9, 2026, an iOS VPN kill switch is not a switch that you can find in the Settings app. The behavior is implemented by the VPN app through Apple’s Network Extension includeAllNetworks flag, which routes traffic into the tunnel subject to some mandatory system exceptions that Apple describes in its VPN routing documentation. A separate, optional excludeLocalNetworks flag — when an app enables it — deliberately keeps local-network traffic outside the tunnel. iOS has no user-facing system kill-switch control comparable to Android’s “Block connections without VPN” setting.
That distinction matters because a settings label cannot tell you what happens during a real failure. The useful question is narrower: while the tunnel is interrupted, does traffic stay blocked, or can the phone use its ordinary connection before protection returns? This protocol checks the outcome directly. For a broader explanation of tunnels and routing, start with what a VPN is and then read how WireGuard works.
This page defines the protocol before publishing results. RTINGS’ kill-switch robustness methodology provides prior art for testing real failures — killing the client, cutting and restoring the connection, rebooting — instead of treating a kill switch as a checkbox, and its Windows testing found that most VPN kill switches fail the reboot case because the OS restores connectivity before the VPN app launches. That result is from desktop testing and should not be assumed for iOS; it shows why the reboot window deserves its own test here.
How to test a VPN kill switch yourself
Use the same IP-check and DNS-check services throughout one run. Record the service names and test time so another person can understand exactly what you observed. A phone performs the test; a second device can log timestamps without requiring you to leave the failure state on the phone.
- Disconnect the VPN. Open the chosen IP-check page and record the public IP shown. Then run the chosen DNS check and record its output. This is the baseline that you do not want to see during a protected failure.
- Connect the VPN. Record the iOS version and full build number, VPN app version, connection type, date, and local time. If the app displays a selected location or server identifier, record exactly what is shown without interpreting it.
- Repeat the same IP and DNS checks. Record the VPN-assigned public IP and DNS output. Do not begin a failure scenario unless this result differs from the baseline in the way you expect.
- Trigger only one of the five scenarios below. Keep the IP or DNS check ready when the scenario permits it, but do not reopen or interact with the VPN app.
- Immediately check the public IP and DNS output before touching the VPN app. Record whether traffic was blocked, whether a page loaded, every IP or DNS result shown, and timestamps for each transition.
- End the run, restore the original network state, and reconnect deliberately. Begin the next scenario as a fresh run from step 1 rather than carrying state forward.
Know what this check can and cannot show. A webpage IP/DNS check observes the connection only at the moments you look. It cannot prove that no packet — from the browser or from background apps — escaped during the transition itself, and it observes nothing at all while the phone reboots or installs an update. Treat a clean web check as a screening result: “no exposure observed at the check points.” A rigorous run adds capture outside the phone — for example, a router or gateway that can mirror or log the phone’s traffic for the whole transition — which is the standard professional labs use. The PENDING blocks below will state which observation method each result used.
For reproducibility, preserve the sequence: baseline, confirmed VPN connection, induced failure, immediate observation, and recovery. If cleanup becomes difficult, use the iPhone VPN troubleshooting guide. Before an OS-update run, consult what changed for VPNs in iOS 27.
The five failure scenarios we test
Record the device, iOS build, app version, network, and time for every scenario you run. “Should” describes this protocol’s pass condition, not an assertion about a particular app or iOS build. RTINGS likewise tests failure scenarios rather than recording only whether an app presents a feature.
1. Airplane mode on/off
Start with the VPN connected and its assigned IP confirmed. Turn Airplane Mode on, wait until the phone has lost connectivity, then turn Airplane Mode off. Do not open the VPN app. As soon as connectivity appears to return, run the IP and DNS checks.
The desired result is blocked traffic while the tunnel is unavailable or the confirmed VPN IP after recovery. Seeing the baseline IP or DNS output is a failure under this protocol. No outcome is claimed before testing the named device, build, app version, and network.
2. Wi-Fi → cellular handoff
Connect over Wi-Fi, confirm the VPN-assigned IP, and prepare the IP check. Disable Wi-Fi so the phone has to move to cellular service. Before opening the VPN app, check IP and DNS and note the exact times at which the old connection stopped and a new result became available.
The desired result is no baseline exposure during handoff: traffic remains blocked until the tunnel is ready, or the first reachable check shows the confirmed VPN path. A brief result still counts. No measured handoff outcome is claimed yet.
3. Force-quitting the VPN app
With the tunnel connected and the assigned IP recorded, force-quit the VPN app. Do not relaunch it. Immediately try the same IP and DNS checks, and keep recording timestamps until traffic is blocked, the VPN path is confirmed, or the baseline appears.
The desired result is that force-quitting never makes the baseline IP or DNS output reachable. The outcome must be established on the recorded iOS build and app version; the protocol assumes nothing about what closing the app does to its tunnel.
4. Updating the VPN app while connected
Begin only when a real update for the VPN app is available. Record the installed and offered versions, connect the tunnel, and confirm the assigned IP. Start the update without first disconnecting. Keep checking reachability, IP, and DNS without opening the VPN app after installation finishes.
The desired result is no baseline exposure before, during, or after the update. This scenario has a documented failure pattern: in late April 2026, Mysk reported that an iOS update of a connected VPN app eventually terminated both the app and tunnel after a period of blocked internet, exposing traffic and IP until manual recovery — and published a live demo logging the iPhone’s IP every second during a background VPN-app update on iOS 26.4.2. Mullvad advises users of its strictest kill-switch mode to disconnect before updating the app.
5. OS update
Run this scenario only when an iOS update is available and after making whatever backup you normally require. Record the iOS version and full build before updating, plus the offered version. Connect the VPN and confirm its assigned IP, install the update, and after the phone restarts, check IP and DNS before opening the VPN app.
For this protocol, a pass means the baseline does not become reachable during the observable update and restart sequence. The first post-restart network check should either be blocked or show the confirmed protected path. This page does not predict recovery behavior for an untested combination of hardware, iOS builds, app versions, and networks.
Why the app-update scenario is the scary one
The app-update case is different because routine maintenance can create the failure without the user deliberately testing the tunnel. Mysk described the observed sequence in late April 2026: “When iOS updated the app with the kill switch on, it was a total mess: iOS blocked internet for nearly 6 minutes, then terminated the app and its VPN tunnel, exposing iPhone traffic and IP. The VPN required a manual restart.”
That is one documented report, not a universal measurement. Mullvad’s app-update guidance addresses the same failure window, and nothing in Apple’s iOS 27 beta release notes mentions a fix for it. The responsible conclusion is not that every update leaks. It is that an active-tunnel app update deserves its own repeatable test, with the exact iOS build and app version attached to the result.
Can the network itself route around your VPN? (TunnelVision)
Yes, on a hostile or misconfigured network, TunnelVision can use DHCP option 121 to install routes that send traffic around a VPN. Leviathan Security Group disclosed the technique on May 6, 2024; it is tracked as CVE-2024-3661 and affects Windows, Linux, macOS, and iOS. Leviathan’s technical disclosure and the NVD record document the issue.
Leviathan says the technique “does not affect Android as they do not have support for DHCP option 121.” Leviathan’s technical disclosure That makes Android structurally immune to this specific option-121 attack, not to every possible network or VPN failure.
For an iPhone user, the practical point is that a working-looking tunnel icon is not a complete routing test. Kill-switch or firewall-style mitigations can help by denying traffic that does not follow the intended path, but their actual behavior still needs verification under the specific OS build and app version — which is exactly what the protocol above is for.
What should you do this week?
Run steps 1 through 3 now: record your baseline IP and DNS, connect the VPN, and confirm the protected result. Save the date, iOS build, app version, and network beside those observations. That gives you a clean reference without manufacturing certainty from an app label.
Then treat VPN app updates as the risky moment identified by the available evidence. When an update arrives, either observe the connected-update scenario and check IP plus DNS immediately, or take the phone offline until you can reconnect and verify deliberately.
