When a VPN Kill Switch Fails: Common Scenarios and What to Check

What does it mean when a VPN kill switch is "not working"?

"My kill switch isn't working" actually describes several different problems, and figuring out which one you have is most of the battle. Sometimes it means the kill switch didn't trigger at all — the VPN dropped, and your device kept browsing normally over your regular, unprotected connection without any interruption. Sometimes it means the opposite: the kill switch triggered and then never let go, leaving you with no internet at all long after the VPN reconnected. And sometimes it means something quieter and harder to notice — the kill switch is technically doing something, but not covering everything you assumed it covered, so part of your traffic is protected and part of it isn't, with no obvious sign of the gap.

All three of those are worth treating as distinct problems, because the fix is different for each. This guide walks through the specific, concrete scenarios that produce each kind of failure, what's actually happening on your device in each case, and what to check to confirm it and fix it. If you want the basics first — what a kill switch is and how it's supposed to work when everything goes right — our companion guide on what a VPN kill switch is covers that ground; this one picks up from there and focuses specifically on failure.

One framing that's worth keeping in mind throughout: a kill switch failing doesn't necessarily mean your VPN provider did something wrong, or that the app is broken. Several of the scenarios below are caused by how operating systems, network interfaces, and background processes interact with any third-party app that tries to control network traffic — not by bad engineering on the VPN provider's part specifically. That doesn't make the failure less worth fixing, but it does mean the first step is almost always diagnosis, not switching providers.

Why is my VPN kill switch not working? The most common failure scenarios at a glance

Before going scenario by scenario, here's a quick map of the territory. A VPN kill switch not working generally falls into one of these buckets, roughly ordered from "most commonly reported" to "less common but still real":

• The kill switch never triggered when the VPN connection dropped, and traffic quietly fell back to your normal connection.
• The kill switch triggered correctly but never released, leaving you disconnected from the internet entirely even after the VPN reconnected.
• The kill switch protects some traffic (usually your browser or the VPN app itself) but not other apps or background processes running at the same time.
• The kill switch behaves differently across networks — for example, it works reliably on home Wi-Fi but not on mobile data, or the reverse.
• Your device auto-reconnected to a network it considers trusted, in a way that sidestepped the kill switch's logic entirely.
• The setting simply isn't turned on — often after an app update, a reinstall, or a switch to a new device, where a setting that used to be enabled quietly reset to its default.
• You're running a router-level VPN setup, which usually has no equivalent kill switch protection at all unless configured separately.
• A firewall, antivirus tool, or another security app on the same device is interfering with how the VPN app tries to block traffic.

The rest of this guide goes through each of these in more detail, plus how to actually test for the problem rather than guess at it.

Scenario 1: The kill switch didn't trigger when the VPN connection dropped

This is the scenario most people mean when they say a VPN kill switch is not working: the VPN disconnects — because of a network hiccup, a server-side issue, or the app crashing in the background — and instead of cutting off your internet access, your device just keeps working normally, silently routed over your regular, unencrypted connection with your real IP address visible again.

The most common underlying cause is the type of kill switch the app is using. There are, broadly, two different technical approaches, and they don't fail in the same way:

Monitoring-based ("application-level") kill switches work by having the VPN app periodically check whether the tunnel is still up, and reacting if it detects a drop. This approach is simpler to build and is common in consumer VPN apps, but it has an inherent gap: there's a small window between the moment the tunnel actually drops and the moment the app's monitoring loop notices and reacts. During that window, if anything tries to reach the internet, it can go out over your normal connection before the kill switch has caught up. On a stable network, that window might be too short to matter in practice. On a network with frequent brief drops, it can mean small amounts of unprotected traffic slip out repeatedly, in a way that never shows up as an obvious, sustained "no internet" event.

Firewall-based ("system-level") kill switches work differently: rather than watching for a drop and reacting afterward, they set firewall rules in advance that only allow traffic to leave your device through the VPN's virtual network interface, full stop. If the VPN tunnel disappears, there's no separate detection step required — the firewall rule itself simply has nothing to route through anymore, and traffic doesn't get an unprotected path to fall back to in the first place. This approach tends to be more reliable specifically because it doesn't depend on noticing a drop after the fact.

What to check: Look in your VPN app's settings for any language distinguishing the two — some apps explicitly label their kill switch as "firewall-based" or mention it uses your operating system's built-in firewall (Windows Filtering Platform on Windows, pf on macOS, iptables or nftables on Linux). If your app only offers a basic, unlabeled toggle and you've confirmed through testing (covered later in this guide) that traffic leaks during a drop, that's a meaningful signal the implementation is the monitoring type, and it's worth checking whether the app has a more aggressive or "always-on" variant of the setting, or considering a provider whose documentation is explicit about using firewall rules.

Scenario 2: Internet access stays blocked even after the VPN reconnects

This is the mirror-image problem: instead of failing to trigger, the kill switch triggers and then doesn't release properly, leaving you with no internet access at all — not even through the VPN — for longer than the actual outage lasted. People sometimes describe this as "the kill switch is stuck" or assume it means the feature is broken, when more often it's the app's reconnection logic that's lagging behind the kill switch's blocking logic.

A few specific causes show up repeatedly here:

The VPN app is trying to reconnect to a server that's temporarily unreachable — due to a server-side outage, a network change, or a firewall on the local network blocking the VPN protocol — and the kill switch, correctly, keeps blocking traffic the entire time because from its perspective the tunnel genuinely isn't up. This isn't the kill switch malfunctioning; it's doing exactly what it's supposed to do while the underlying reconnection attempt keeps failing. Switching to a different server location, or a different protocol (see our guide to VPN protocols for what the options actually mean), can sometimes get past a specific server or protocol issue faster than waiting for the same one to keep retrying.

The device went to sleep or changed networks mid-reconnection — closing a laptop lid or switching from Wi-Fi to a wired connection while the VPN app is in the middle of trying to reconnect can leave its internal state confused about what it's actually monitoring, sometimes requiring a full app restart (not just a reconnect click) to clear.

A stale or corrupted kill switch rule persists after the app closes unexpectedly. Firewall-based kill switches work by writing rules into your operating system's firewall configuration. If the VPN app crashes, gets force-closed, or the device loses power unexpectedly, those rules can sometimes remain in place even though the app that set them is no longer running to manage them — which looks exactly like "no internet, kill switch stuck," because functionally, that's precisely what's happening. Restarting the VPN app (so it can clean up and reapply its own rules correctly) or, if that doesn't help, restarting the device, resolves this in the large majority of cases.

What to check: If you're stuck with no internet and the VPN app also won't reconnect, try closing and reopening the app fully before restarting the device — this fixes it more often than not, and is faster. If it happens repeatedly on the same network, that points toward a local network issue (like a firewall blocking your VPN's protocol or port) rather than the kill switch itself being at fault.

Scenario 3: The kill switch protects some traffic but not everything running on your device

This is the quieter, harder-to-notice version of a VPN kill switch not working: your browser might be fully protected, but a background app — a sync client, a messaging app, an automatic update process — keeps sending traffic over your normal connection during a VPN drop, because the kill switch was scoped to specific apps rather than the whole device.

This distinction usually comes down to whether the kill switch is system-wide or per-app (application-level):

A system-wide kill switch blocks all outbound (and often inbound) traffic at the network level the moment the VPN drops, regardless of which app is trying to send it. Nothing gets an exception unless you've explicitly configured a split-tunneling rule to allow it — see our guide to split tunneling for how that interacts with a kill switch.

A per-app kill switch, by contrast, is configured to block traffic only from apps you've specifically selected — often the browser you've designated, or the VPN app itself — while other apps on the same device are left untouched and can keep communicating normally even during a VPN drop. This mode exists because it's genuinely useful in some cases: it lets you keep a specific background download or a video call running uninterrupted even if the VPN briefly drops, at the cost of that traffic being unprotected during the gap. The problem is when someone assumes they have full, device-wide protection because "the kill switch is on," without realizing it was scoped narrower than that.

What to check: Open your kill switch settings and look specifically for language like "apps," "select apps," or a list with checkboxes, rather than a single on/off toggle. If you see a per-app list, confirm every app you actually care about protecting is on it — and be aware that background system processes (OS-level telemetry, automatic updates, other apps you forgot were running) may not appear on that list at all, meaning a fully comprehensive system-wide kill switch is the safer default unless you have a specific, deliberate reason to exempt certain traffic.

Scenario 4: It works on Wi-Fi but fails on mobile data (or the other way around)

A kill switch that behaves reliably on one type of network connection and inconsistently on another is a specific, reported pattern, and it comes down to how operating systems — mobile ones especially — handle network interface switching differently from how desktop operating systems do.

On mobile devices, switching between Wi-Fi and cellular data isn't always a clean "disconnect from one, connect to the other" event from the operating system's point of view; some mobile OS versions will briefly run both interfaces at once during a handoff, or will let background traffic move through whichever interface currently has connectivity, in ways that a kill switch built primarily around a single, stable network path doesn't always fully anticipate. A kill switch that works reliably on a laptop's Wi-Fi and ethernet connections doesn't automatically translate to identical behavior on a phone moving between a cell tower and a Wi-Fi access point, because the underlying OS networking APIs a VPN app has access to are meaningfully different in each case.

Mobile operating systems also impose stricter limits on what background apps — including VPN apps — are allowed to do to manage power and battery life, which can affect how quickly (or whether) a kill switch reacts if the app itself has been put to sleep by the OS in the background.

What to check: If you've noticed the problem specifically on mobile, check whether your VPN app has a separate, explicit kill switch toggle for iOS or Android — some providers implement it differently per platform, and on iOS specifically, Apple's own "Always-on VPN" configuration profile (a different, OS-level mechanism from a typical app's in-app kill switch) is sometimes a more reliable option if your provider or a mobile device management setup supports it. Also check whether your phone's battery optimization or background app restrictions have been applied to the VPN app — those settings, found in your phone's own settings menu rather than the VPN app's, can throttle a background app's ability to react quickly to a dropped connection.

Scenario 5: Your device auto-reconnects to a "trusted" network and bypasses the kill switch

This scenario trips people up because it doesn't feel like a VPN failure at all — it feels like a normal, convenient thing your device just does. Many operating systems let you mark certain Wi-Fi networks as trusted or automatically reconnect to previously used networks without any prompt. Some VPN apps, in turn, offer a setting like "automatically connect on untrusted Wi-Fi" or "don't automatically connect on trusted networks" — logic that's meant to save you from running a VPN unnecessarily at home, but that can also mean the VPN, and by extension its kill switch, simply isn't active at all on a network the app has been told to treat as safe.

The failure mode here isn't the kill switch malfunctioning — it's a kill switch that was never engaged in the first place, because the surrounding automation decided a VPN connection wasn't needed on that particular network. If you've renamed a network, moved a router, or are connecting somewhere your device recognizes from a past connection (a friend's house, a previous workplace, a hotel you've stayed at before), you can end up with no VPN and no kill switch active without any deliberate choice on your part in the moment.

What to check: Review any "trusted network," "auto-connect," or "smart connection rules" settings in your VPN app specifically, not just the kill switch toggle itself — a kill switch can be switched on and working correctly and still provide zero protection if the surrounding automation decided the VPN itself shouldn't be running. If you want consistent protection regardless of which network you're on, turning off automatic trusted-network exceptions, so the VPN (and its kill switch) is always expected to be active, removes this particular gap. This matters most on public Wi-Fi, where the assumption that a network is "known" or "trusted" is far less safe than at home.

Scenario 6: The setting exists in the app, but it was never actually turned on

This is the most mundane cause on this list, and also one of the most common in practice: the kill switch simply isn't enabled, and whoever's using the VPN assumed it was because they remember turning it on at some point in the past, or because they assumed it comes on by default.

A few specific situations cause this more often than you'd expect:

App updates resetting settings. Some VPN app updates — particularly major version updates — rebuild the settings menu or reset advanced options to their defaults, and a kill switch that was manually enabled before the update doesn't always carry over automatically. This is worth checking specifically after any update that changes the app's interface noticeably.

Reinstalling the app, or switching to a new device, starts you from the app's default configuration every time, and kill switches are frequently off by default rather than on by default — providers vary on this, and it's not something to assume either way without checking.

The setting exists but requires an additional permission the app was never granted. On several platforms, a firewall-based kill switch needs elevated system permissions (like a VPN configuration profile on iOS/macOS, or specific network permissions on Android) to function, and if that permission was denied or revoked at some point — sometimes by an OS update changing permission defaults — the toggle in the app can still show as "on" while the underlying protection it depends on isn't actually functioning.

What to check: Don't just glance at whether the toggle looks switched on — actually open the setting, confirm any related permission prompts have been granted (check your device's own system settings for VPN or network permissions granted to the app, not just the app's internal settings screen), and then run the drop test described later in this guide to confirm it's functioning rather than just enabled in name.

Scenario 7: A router-level VPN setup has no equivalent kill switch protection

If you've configured a VPN directly on your home router — so every device on the network is covered without installing an app on each one — it's worth knowing that most router-level VPN setups don't include an equivalent kill switch feature unless it's been separately configured, and many consumer router firmware options don't support one at all.

The practical effect: if the VPN connection configured on the router drops, most router setups will simply route traffic normally over your regular internet connection instead, with no blocking behavior kicking in — the router-level VPN silently stops protecting the network, and every device connected through it reverts to an unprotected connection without any visible warning on the devices themselves, since the router is where the VPN logic lives, not the individual phones and laptops using it.

What to check: Some more advanced router firmware (certain builds of OpenWrt, DD-WRT, or similar) support firewall rules that can approximate kill switch behavior by blocking outbound traffic on the router's WAN interface unless it's routed through the VPN's virtual interface — but this has to be configured deliberately; it isn't a feature most consumer routers offer out of the box just because a VPN client is running on them. If you're relying on a router-level VPN for kill switch–equivalent protection, confirm your specific router firmware actually supports this kind of rule, and test it the same way you'd test an app-level kill switch, rather than assuming router-level VPN coverage implies kill switch coverage by default.

Scenario 8: A firewall, antivirus tool, or another security app is interfering

Kill switches on most platforms work by modifying firewall rules at the operating system level, which means they're operating in the same space as any other security software you have installed — antivirus suites, third-party firewalls, ad blockers with network-filtering components, or corporate endpoint security tools. When two pieces of software both try to manage firewall rules, conflicts are a real possibility, and the symptoms can look exactly like "the kill switch isn't working" even when the VPN app's own logic is functioning correctly.

This can show up in either direction: some security software strips out or overrides firewall rules it doesn't recognize as belonging to itself, which can quietly undo a kill switch's rules without any notification. In the other direction, some third-party firewalls block a VPN app from writing its own rules in the first place, which can prevent the kill switch from ever engaging even though the app's toggle shows it as enabled.

What to check: If you run third-party antivirus or firewall software alongside your VPN, check whether that software has a log or notification history showing it blocked or modified another app's network activity around the time of a suspected kill switch failure. As a diagnostic step (not a permanent fix), temporarily disabling other firewall or security software and re-running the drop test can help confirm whether a conflict is the cause; if it is, most security software lets you add a specific exception or allowlist entry for your VPN app rather than requiring you to keep it disabled long-term.

How do you actually test whether your kill switch is working right now?

Nearly every scenario above is easier to diagnose with a deliberate test than by waiting for a real, unplanned VPN drop to happen and hoping you notice what happened during it. The good news is that testing a kill switch doesn't require special tools:

1. Connect to your VPN normally, and confirm in the app that it shows a fully connected state before starting.
2. Open a page that shows your current public IP address in a browser tab, and leave it visible — this is your reference point for "am I actually protected right now."
3. Force the VPN connection to drop in a way that simulates a real failure, rather than just clicking "disconnect" in the app (which some apps handle differently, more gracefully, than an unexpected drop). Turning off Wi-Fi briefly and back on, switching networks, or — if you're comfortable with it — closing the VPN app's process directly (not just quitting normally) are all reasonable ways to simulate an unexpected drop rather than a clean disconnect.
4. Immediately check whether your internet access stops entirely. Try refreshing the IP-address page, or loading a new site. If everything freezes or fails to load, that's the kill switch behaving as expected. If pages keep loading normally, refresh the IP-checking page specifically and see what address it reports — if it shows your real IP address rather than the VPN's, that's a confirmed kill switch failure for scenario 1 above.
5. Let the VPN reconnect on its own, and time roughly how long it takes for internet access to resume — this gives you a baseline for whether a future "no internet, kill switch stuck" moment (scenario 2) is normal reconnection time or an actual problem.
6. Repeat the test on each network and device you actually use regularly, given how much the scenarios above depend on network type and platform specifically. A clean result on home Wi-Fi with a laptop doesn't tell you anything about how the same VPN app behaves on your phone on mobile data.

This test takes a few minutes and is worth running once after setting up a new VPN, again after any major app update, and again after switching devices — the same testing discipline that's worth applying to other silent-failure risks like DNS leaks, which can coexist with a working kill switch and address a genuinely different gap.

Does the operating system itself ever undermine a kill switch, separate from the VPN app?

Yes, and this is worth understanding because it explains why an otherwise well-built kill switch can still have gaps that aren't the VPN provider's fault at all. A few OS-level behaviors matter specifically:

IPv6 traffic bypassing an IPv4-focused kill switch. Much like the IPv6 leak issue that affects DNS resolution, a kill switch built primarily around blocking IPv4 traffic can leave a second, untunneled path open if your device also has active IPv6 connectivity and the VPN app doesn't explicitly account for it. Disabling IPv6 at the device or network level, if your VPN doesn't fully support tunneling it, closes this specific gap.

Sleep and wake cycles. Closing a laptop lid, letting a phone screen lock, or a device going into a low-power state can sometimes let the VPN connection quietly drop in the background without the kill switch's monitoring loop getting a chance to react before the device is actively being used again — meaning by the time you're back at the keyboard, the VPN may already be disconnected, and any activity that happened in that gap (background syncing, notifications, automatic checks) could have gone out unprotected.

Operating system network stack updates. Major OS updates occasionally change how the underlying networking APIs a VPN app relies on behave, and a kill switch implementation that worked reliably on a previous OS version can develop new gaps after an update until the VPN provider ships a corresponding app update. This is part of why keeping both your operating system and your VPN app reasonably current — rather than delaying updates on either side — reduces the odds of this specific kind of drift.

Captive portals on public networks. Hotel, airport, and coffee-shop Wi-Fi networks that require you to accept terms or log in through a browser page before granting real internet access can interact awkwardly with a kill switch, since the kill switch may need to temporarily allow some unencrypted traffic through for the captive portal page to load at all — a legitimate, narrow exception that's different from a genuine failure, but one that's worth being aware of if you're testing a kill switch on this kind of network specifically.

What should you check first when you suspect your VPN kill switch isn't working?

If you're troubleshooting a specific, real incident rather than doing a general test, a rough order of checks tends to be efficient:

First, confirm the setting is actually enabled and that any required system permissions (VPN configuration profiles, network permissions) haven't been silently revoked — this alone resolves scenario 6 and is the fastest thing to rule out.

Second, check the scope — system-wide versus per-app — to confirm the kill switch was ever supposed to cover the traffic you're worried about in the first place, ruling out scenario 3.

Third, check any "trusted network" or auto-connect exceptions in the app, since these can mean the VPN itself wasn't active at all, which is a different problem from the kill switch failing (scenario 5).

Fourth, run the deliberate drop test described above, on the specific network and device where you noticed the problem, to confirm whether it's scenario 1 (didn't trigger), scenario 2 (didn't release), or something more intermittent tied to network type (scenario 4).

Fifth, rule out interference from other security software running on the same device (scenario 8), particularly if you've recently installed new antivirus or firewall software around the time the problem started.

Working through checks in roughly this order avoids the common trap of assuming the VPN provider's app is broken before confirming the setting was even correctly configured and active in the first place.

Is a firewall-based kill switch more reliable than an app-level one?

In general, yes, for the reasons covered in Scenario 1 — a firewall-based kill switch doesn't depend on detecting a drop after the fact, since it works by only ever allowing traffic through the VPN's interface in the first place, with no separate reaction step required. That structural difference means it tends to close scenario 1 specifically (the kill switch not triggering at all) more reliably than a purely monitoring-based approach.

That said, "more reliable in general" isn't the same as "immune to every scenario on this list." A firewall-based kill switch can still fail to release properly (scenario 2), can still be scoped to specific apps rather than system-wide (scenario 3), can still be undermined by a conflicting firewall or antivirus tool (scenario 8), and can still simply not be turned on (scenario 6). The underlying implementation approach affects which failure modes are more or less likely, not whether failures are possible at all — which is exactly why testing your own actual setup, rather than assuming a specific technical approach guarantees protection, remains the most reliable way to know where you stand. If reliability here is a priority for you, it's a reasonable thing to look for specifically when comparing providers, alongside other trust signals like a documented no-logs audit or independent security audit — our individual reviews, including our NordVPN review and Proton VPN review, are a starting point for checking how a given provider documents its own kill switch implementation.

When is a kill switch failure a serious problem, and when is it just an inconvenience?

The stakes of a VPN kill switch not working depend heavily on why you're using a VPN in the first place, and it's worth being honest with yourself about which category you fall into rather than treating every gap as equally urgent.

If you're mainly using a VPN for casual privacy from your ISP, for accessing region-specific content, or for a bit of extra protection on networks you already trust reasonably well, an occasional brief gap during a VPN drop is a real issue worth fixing, but not typically a high-stakes one — the practical exposure is a short window where your real IP address might have been visible, not an ongoing or catastrophic compromise.

If your reason for using a VPN is closer to the higher-stakes end of the spectrum — protecting reporting work as covered in our guide for journalists, or any situation where a brief, unprotected window carries genuine personal risk — a kill switch failure is worth treating with real urgency: testing it deliberately before it matters, choosing a firewall-based implementation specifically if your provider documents one, and building the habit of re-testing after any app update, OS update, or device change, rather than assuming a setting that worked once keeps working indefinitely. The overlap between "kill switch reliability" and "privacy" more broadly is covered in our general guide to VPNs for privacy, which is worth reading alongside this one if a dropped connection at the wrong moment would be a real problem for you rather than a minor annoyance.

Practical takeaway

A VPN kill switch not working is rarely a single, simple bug — it's usually one of a specific, identifiable set of scenarios: a monitoring-based implementation with a detection gap, a kill switch that's scoped to certain apps rather than the whole device, network-specific quirks on mobile, a "trusted network" exception that kept the VPN from ever engaging, a setting that quietly reset after an update, a router-level setup with no equivalent protection, or a conflict with other security software on the same device. Each of those has a specific, checkable cause rather than a vague "it's broken," and each is worth ruling in or out with a deliberate test — forcing a drop and watching what actually happens to your internet access and your visible IP address — rather than trusting that a toggle switched to "on" means the protection is functioning as intended. Prefer a firewall-based, system-wide implementation where your provider offers one, test it on every network and device you actually use rather than just once, and re-test after any app update, OS update, or new device, since several of the scenarios above are specifically the kind of thing that resets or drifts quietly over time.