My VPN Kill Switch Was On—Traffic Still Escaped During the Handoff

The upload kept moving after the VPN disconnected.

That was the moment I stopped breathing for a second.

I was in an airport lounge, sending an embargoed interview package to an editor before boarding. The folder contained audio, photographs and a draft that was not supposed to leave our protected workflow.

My laptop had gone to sleep while I moved to a quieter table. When I opened it again, the airport Wi-Fi reconnected immediately. The cloud client resumed the upload.

The VPN did not.

Its window said Reconnecting. The kill switch was enabled.

Yet the progress bar had advanced from 46% to 51%.

I cancelled the upload and opened an IP-checking page. It showed the airport network’s public address, not the VPN server.

At first, I blamed the test page. Perhaps it was displaying a cached result. I refreshed it, opened another browser and cleared the DNS cache.

The same address appeared.

I restarted the VPN, changed servers and repeated the sequence with a harmless test folder.

Close the lid.

Wait.

Open the laptop.

Wi-Fi returned. The test upload resumed. The VPN followed several seconds later.

The kill switch looked active in the settings. During the moment that mattered, it had not behaved like a switch at all.

A kill switch has to survive the failures you actually experience

I had assumed the feature followed one simple rule:

VPN connected, internet available.

VPN disconnected, internet blocked.

In practice, VPN applications enforce that rule in different ways. Some rely mainly on routing changes. Others create firewall rules. Some begin blocking only after a tunnel has connected, while stricter modes are meant to block traffic before the first connection and during reconnection.

That distinction matters because pressing the Disconnect button is the easiest possible test. The application knows exactly what is happening.

Travel produces messier failures.

A laptop wakes before the VPN process is ready. Wi-Fi disappears and a phone hotspot takes over. The operating system decides that a newly available network is usable while the tunnel is still rebuilding.

Current kill-switch testing therefore checks several events separately: an application crash, loss and restoration of internet access, sleep, wake and reboot. A service may block traffic correctly during a manual disconnect yet leave a brief gap during one of those transitions.

My test had found such a gap.

Windows had already accepted the airport Wi-Fi. The cloud client saw a working route and resumed. The VPN was still reconnecting.

The kill switch had lost the race.

That gave me a more useful test than the setting label: when the tunnel disappeared unexpectedly, did the task stop?

The established provider passed the easy test

The VPN I was using had sensible strengths.

It had operated for years, maintained a large support organisation and offered servers across many locations. I had trusted it on previous trips without noticing a problem.

That history was why I tried to repair the setup rather than replace it.

I disabled split tunneling.

I turned off local-network access.

I changed the kill switch from standard mode to its strictest option.

Then I tested again.

A normal server disconnect worked correctly. The browser lost access immediately.

The sleep-and-wake test was less reliable. Sometimes the laptop stayed offline until the VPN returned. Sometimes a background application connected first. On one attempt, the browser loaded part of a page before the tunnel reappeared.

Other users have reported the same unnerving detail after sleep: a chat or background application reconnects before the VPN does, even though the kill switch is enabled. (Reddit: r/ProtonVPN) That was enough to confirm why my manual test had been misleading.

The feature worked when I disconnected the VPN neatly.

It became unpredictable when the network changed without asking permission.

Public Wi-Fi adds another route at exactly the wrong moment

The airport network made the handoff more complicated.

A VPN application can still display “connected” while the operating system sends selected traffic through another route. Research disclosed in 2024 showed how a local network could use DHCP routing information to create a path outside a routing-based VPN. The VPN’s control connection could remain active while some traffic avoided the encrypted tunnel entirely.

The encryption was not broken. The traffic simply took another road.

I could not observe the airport network’s internal routing rules, so I had no basis for claiming that anyone was actively manipulating my laptop. The practical lesson was enough: a green VPN icon did not prove that every packet was following the tunnel.

That changed the way I thought about the kill switch.

It was not a feature I could verify once and forget. It was behaviour that had to survive the transitions my laptop made during an ordinary trip:

Sleep to wake.

Lounge Wi-Fi to terminal Wi-Fi.

Wi-Fi to hotspot.

Signal loss to reconnection.

Those were not unusual edge cases. They were the normal shape of the workday.

More controls made the failure harder to isolate

The established application offered several ways to respond.

I could change protocols, choose another server, alter split-tunneling rules, switch kill-switch modes and decide whether local traffic remained available.

Each control had a legitimate purpose.

Together, they made it difficult to tell which layer had failed.

I spent fifteen minutes changing settings and repeating tests. Every combination required another sleep cycle, another interruption and another check for traffic outside the tunnel.

Meanwhile, the real interview upload remained cancelled.

My boarding time was approaching, and the editor was waiting.

At that point, the problem was no longer a shortage of security features. Maintaining the secure state had become a separate technical project.

A kill switch is supposed to protect the brief moment when a VPN fails. If the tunnel is slow to recover whenever the network changes, that brief moment becomes the centre of the experience.

I needed the upload to pause automatically, the protected route to return and the task to continue without giving the physical network a head start.

The smaller app treated the handoff as normal

I opened OnlydogVPN, which I had installed as a travel backup.

It has fewer server locations than the established provider, a shorter public history and fewer independent reviews. Those limitations would matter if I needed a specific small city or the longest possible record of external testing.

I did not need a city.

I needed to move between airport Wi-Fi and my phone hotspot without exposing the upload in between.

The smaller app organised its choices around situations rather than geography. I selected the option for a weak or changing public network and connected.

Before trusting it with the embargoed folder, I repeated the same harmless test.

I started uploading a video.

At 38%, I switched off Wi-Fi.

The progress bar stopped.

The laptop joined my phone’s hotspot a few seconds later, but the upload did not escape through the new route. The VPN restored its connection first.

Then the upload resumed from 38%.

I checked the visible IP address. It still belonged to the protected route.

Next, I closed the laptop, waited and opened it again.

The browser remained offline while the tunnel returned. Once it had reconnected, the page loaded and the upload continued.

I repeated the handoff a third time.

The behaviour stayed the same:

Traffic paused.

The tunnel recovered.

The task continued.

That was the result I had expected when I first enabled a kill switch.

Recovery reduced the gap the switch had to defend

The service uses an HTTP/3-based transport with additional traffic obfuscation.

HTTP/3 runs over QUIC, which is designed to recover efficiently when packets are lost or the underlying network path changes. The obfuscation also keeps the connection from presenting the most obvious pattern of a conventional VPN tunnel.

On the laptop, the result required no long technical explanation.

The tunnel handled a network change without treating it as the end of the session.

When Wi-Fi disappeared, the upload paused instead of moving to another interface unprotected. When the hotspot became available, the protected route returned and the transfer continued.

The kill switch still mattered. But it was no longer being forced to rescue the connection every time the airport network stumbled.

That changed my comparison standard.

I had been asking which provider offered the strictest-sounding kill-switch mode.

The better question was which VPN could maintain a secure state while the device moved through the transitions that caused the old setup to leak.

The real upload survived the gate change

I restarted the interview upload.

At 54%, the departure board changed our gate.

I packed the laptop without cancelling the transfer and walked to another part of the terminal. The lounge Wi-Fi disappeared in the corridor. My phone hotspot took over near the new gate.

When I opened the laptop, the upload was paused.

The VPN reconnected.

The progress bar continued from 54%.

It reached 100% while passengers were forming a queue beside the desk.

The editor confirmed that the folder had arrived intact. I sent the password through our separate channel and closed the laptop.

I did not have to rebuild a firewall rule, inspect a server list or wonder whether a background application had reached the internet first.

The secure behaviour had become boring.

That was exactly what I needed.

How to test a kill switch properly

Do not begin by trusting the label in the settings menu.

Start a harmless upload or continuous connection, then reproduce the events that happen during real use:

Put the device to sleep and wake it.

Turn off Wi-Fi and allow a hotspot or mobile connection to take over.

Interrupt internet access without closing the VPN application.

Restart the VPN process or reboot the device.

During each transition, watch the task itself. Does it pause, or does it continue outside the tunnel? Check the public IP and DNS path after the handoff, not only while the original connection is stable.

Also inspect split tunneling and local-network exceptions. An excluded application may be doing exactly what the configuration allows while appearing to defeat the kill switch.

If sensitive traffic continues after the tunnel drops, stop the task until the cause is understood. A feature is not reliable merely because it works when the user presses Disconnect.

My established provider still offered more locations, a longer history and more advanced controls. Those advantages remained real.

They did not protect the moment when the airport Wi-Fi returned before the tunnel.

The smaller service offered fewer decisions, but it kept traffic paused and restored the protected route across every handoff I tested.

The kill switch had promised to stop traffic after failure. What finally protected the interview package was a VPN that did not turn every ordinary network change into a failure in the first place.