VPN kill switch: what gets blocked, and when?

What a kill switch is intended to do

A VPN kill switch is intended to prevent some traffic from taking an unwanted direct route when the VPN is unavailable. Its actual behavior depends on the app, operating system, mode and routing exceptions. A setting that handles an unexpected tunnel drop is not necessarily a setting that blocks traffic after you deliberately disconnect.

This distinction matters because users may want different behavior. Someone who needs all connectivity blocked until a VPN is active may choose a strict or advanced mode. Someone who expects normal internet access after manually turning the VPN off should verify that the selected mode permits it.

We explain current provider documentation here. We have not tested these modes on devices for The VPN Deal, so the guide does not certify event-by-event leak prevention or claim that a particular platform cannot expose traffic.

Four events to distinguish

A provider’s setup page may describe only some of these events. If another behavior matters to you, look for its exact documentation or confirm it with support. Do not infer persistent protection after a reboot from a generic statement about connection loss.

NordVPN: network blocking and selected-app closure

NordVPN documents two Windows controls: Internet Kill Switch and App Kill Switch. The first controls connectivity; the second closes selected programs and is off by default. Closing a browser or file-transfer application is a different action from leaving it open with no network access.

Its platform guide also distinguishes the website Mac version from the Mac App Store version. The website version has an app kill switch; the App Store version and iOS use routing-level protection called VPN bypass prevention in current guidance. Linux has system-wide blocking after a drop or manual disconnect, with Allowlist exceptions. Fire TV Stick lacks a kill switch in the cited platform guide.

NordVPN separately warns that Internet Kill Switch can take priority over split-tunnel exclusions. An excluded app may therefore be blocked even while a VPN connection exists. Read the current interaction guide instead of assuming that every exclusion always stays online.

Surfshark: soft and strict definitions

Surfshark describes soft protection after an unexpected disconnect and strict protection whenever the VPN is off, including manual disconnection. Its platform setup guide documents a kill switch across the main desktop and mobile systems, but does not establish that every operating system exposes both modes as selectable controls.

The practical step is to read the current app’s setting and the specific platform instructions. If you want normal internet access after manually stopping the VPN, that preference differs from requiring the tunnel for every connection. Select a documented mode that matches the requirement rather than assuming a default.

PIA: ordinary, advanced and mobile behavior

PIA’s desktop VPN Kill Switch covers connection loss. Advanced Kill Switch requires a VPN even when it has been turned off, and Windows support says its protection can persist with the app closed. Its desktop “Only VPN” rule can also require a selected app to have tunnel connectivity.

Android setup uses the operating system’s Always-on VPN and Block connections without VPN options. On iOS, PIA’s settings guide says the kill switch is enabled by default for unexpected drops and reconnection, but does not cover manual disconnect. A desktop advanced mode therefore should not be assumed to describe the iPhone app.

Split tunneling creates additional questions

When an app or network is deliberately allowed to bypass the tunnel, ask whether the kill switch also exempts it. NordVPN documents a Linux Allowlist that bypasses both. Other rule types can interact differently with blocking or DNS settings.

Keep the intended exceptions narrow. A direct route may be useful for a local device or an application, but it does not receive the VPN tunnel’s protection. HTTPS can still protect a website connection, which is a separate layer from the routing choice.

How to check your configuration responsibly

First read the exact platform guide and record the selected mode. Use ordinary, non-sensitive browsing to assess whether connectivity blocks during the documented events. Avoid experimenting with traffic that would cause harm if it used a direct connection.

Checking a public IP address alone does not establish complete protection. DNS, IPv6, browser routing and application exceptions are separate concerns. A single successful reconnection is not proof of behavior after every app exit or reboot. Our DNS leak guide explains the limits of browser-based checks.

If the app behaves differently from its documentation, retain the settings and version details and contact the provider’s support. A provider recommendation on this site cannot replace validating a configuration that matters to you.