An always-on VPN is designed to connect automatically and reconnect when needed. A VPN kill switch stops traffic from using an unwanted route when the VPN is unavailable. Those functions can work together, but enabling automatic reconnection does not necessarily enable traffic blocking. Your apps may be able to connect directly while the VPN is trying to reconnect.

If you need particular traffic to stay inside the tunnel, check what happens both when the VPN connects and when it fails. A device that keeps reconnecting may still allow traffic outside the VPN between attempts. A device with blocking enabled may instead leave the affected apps offline until the tunnel returns. The choice is whether those apps should lose access or be allowed to use a direct connection.

Reconnecting and Blocking Traffic

A VPN connection can drop when you move between WiFi and cellular service, when the VPN server becomes unreachable, or when the app restarts. Automatic reconnection starts another attempt to reach the VPN server. It cannot guarantee that the server is available or that the attempt will succeed immediately. Any blocking rule must therefore work during the period when no usable tunnel exists.

A kill switch may cover the whole device or only selected applications. Split tunneling, which sends some traffic outside the VPN, can also affect what the kill switch blocks. Some apps combine these features; others do not support using them together. Check whether the applications you care about are included and whether the selected blocking mode applies only to an unexpected drop or also to an intentional disconnect.

These choices affect availability as well as privacy. A call or upload may stop when the VPN fails and its kill switch blocks the connection. Allowing a direct connection can keep an app online, but the destination may then see the public IP of your ordinary internet connection. If an app must use the VPN, a connection failure is preferable to silently sending its traffic over another route.

Android Uses Separate Connection and Blocking Settings

With a compatible VPN app, Android's Always-on VPN setting starts the VPN service when the device boots and keeps the service running. The VPN app still has to establish the connection to its server. A running service is therefore not proof that a working tunnel exists. Menu locations and available options vary by device and app.

Block connections without VPN is a separate Android control for preventing apps from connecting outside the selected VPN. With blocking enabled, apps excluded from the VPN can lose network access instead of connecting directly. For Proton VPN on Android, the kill switch setup uses both Always-on VPN and Block connections without VPN. Check both controls when you need the VPN to reconnect and traffic to remain blocked while it is unavailable.

Desktop and Mobile Apps Can Behave Differently

Proton VPN on Windows and in its Linux graphical app offers standard and advanced kill switch modes. Standard mode blocks traffic after an accidental loss of the VPN connection, but allows internet access after you deliberately disconnect. Advanced mode continues blocking without a VPN connection, including after a restart. Pressing Disconnect therefore tests different expected behavior in the two modes.

A feature with the same name can also have platform-specific limits. With Proton VPN on macOS, switching servers can briefly expose the device's ordinary public IP. Some DNS requests from Apple services can bypass the VPN on macOS, iOS, and iPadOS even with the kill switch enabled. Treat these as limits of those particular implementations, rather than assuming that a kill switch guarantees that every kind of traffic stays in the tunnel.

Test the Behavior You Expect

Use a device and network you control when no important call, upload, or work session is in progress. Note the operating system, VPN app version, blocking mode, and any app exclusions. Close unrelated apps that could send data during the check. Keep public IP addresses and account details out of shared notes.

Connect the VPN, check its status, and use a public IP check page to confirm that the browser is using the expected VPN exit address. Keep the underlying WiFi, Ethernet, or cellular connection available. Turning off the only network connection would stop traffic regardless of the kill switch, so that would not show whether the blocking rule works.

If your selected mode is supposed to block traffic after a manual disconnect, disconnect using the VPN app while leaving that mode enabled. For example, this checks the manual-disconnect behavior of Proton VPN's advanced mode on Windows. Try to request a fresh, nonsensitive web page, then reconnect the VPN and check that access returns through the expected exit. Do not use this method to judge a mode that intentionally allows traffic after a manual disconnect.

For a mode that blocks only after an accidental drop, use the provider's supported test procedure for that app and platform. If no such procedure is available, record that the accidental-drop behavior has not been verified. If a public IP check succeeds and shows your ordinary address, the tested request went outside the VPN. A failed load alone is inconclusive: a broken underlying connection can produce the same result as a working block. A browser check also says nothing definite about untested apps, protocols, or DNS requests.

Restore Access and Recheck the VPN Settings

If blocking leaves the device offline, check the VPN app's error or connection status first. Confirm that the underlying network is available, then use the app's supported reconnection steps. A different VPN server may help if the original server is unavailable. On a managed device, ask the administrator before changing a required VPN policy.

If you turn off blocking to regain direct access, treat subsequent traffic as outside the VPN unless you have confirmed otherwise. Re-enable the intended settings and check the VPN connection before resuming work that depends on the tunnel. Record which mode you checked and what happened; a result from one mode should not be treated as proof that another mode behaves the same way.