VPN Disconnects When Switching Networks: The Fix Was Recovery, Not Another Server

The airport announced my gate change while a production rollback was halfway through.

I was sitting in a lounge at Amsterdam Schiphol, connected to its Wi-Fi through my regular VPN. On the laptop screen, a client’s administrative portal showed twelve failed orders waiting to be reprocessed.

The fix was simple enough: confirm the rollback, wait for the service to restart, then verify that new orders were moving again.

The difficult part was timing.

Boarding would begin in fourteen minutes.

My new gate was at the other end of the terminal.

I clicked Confirm rollback, closed the laptop halfway and started walking. The lounge Wi-Fi weakened near the escalator, so I enabled my phone’s hotspot before the laptop lost its connection completely.

Windows joined the hotspot.

The VPN disconnected.

The administrative portal turned white.

When the tunnel returned, the client’s system displayed:

Your session has expired

I blamed the hotspot first.

The phone had full 5G service, and a speed test showed more than enough bandwidth for a browser session.

I reconnected the VPN, selected a nearby Netherlands server and entered my credentials again.

The client sent a verification code.

Before it arrived, the laptop found another airport Wi-Fi access point and switched away from the hotspot.

The VPN dropped again.

A second security alert appeared on my phone:

New login attempt detected

The rollback was still running, but I could no longer see whether it had completed safely.

I had always judged VPNs by how quickly they connected and how many nearby servers they offered.

At that moment, neither measurement mattered.

I needed one protected session to survive the walk from Wi-Fi to mobile data and back again.

Changing networks changes the route beneath the VPN

When a phone or laptop moves between Wi-Fi, cellular data and a hotspot, the internet does not simply become stronger or weaker.

The device receives a different underlying path. Its address may change, and the route to the VPN server changes with it.

Android can notify a VPN when a new underlying network becomes available, while Apple can start or stop VPN connections according to Wi-Fi and cellular conditions. (Android Developers) (Apple Developer) Those platform features recognise the transition, but the VPN still has to carry the protected session across it.

A conventional tunnel may lose the old path and build a fresh connection through the new one. During that gap, a kill switch blocks unprotected traffic while applications wait.

For ordinary browsing, that may mean a page pauses and reloads.

For an authenticated work session, the consequences are larger:

The portal invalidates the login.

A remote terminal closes.

A file transfer restarts.

A meeting returns to the lobby.

That was exactly what had happened to me. Two usable networks were available, yet moving between them turned one rollback into repeated logins and security alerts.

The kill switch protected the gap, not the task

My established VPN provider had a long public history, a large support operation and many European locations.

Those were real strengths.

Its kill switch was also doing its job.

When the tunnel disappeared, the laptop did not quietly send traffic through the new network without protection.

The problem came immediately afterward.

Once the laptop moved from airport Wi-Fi to the phone hotspot, the VPN took several seconds to establish a fresh tunnel. By the time it returned, the administrative portal had already discarded the session.

I disabled automatic Wi-Fi so the laptop would remain on the hotspot.

That stopped one type of switching, but the phone itself briefly lost data as I entered a crowded corridor.

The tunnel reconnected.

The portal expired again.

I tried another server.

Then another protocol.

Each attempt produced a working VPN connection.

Each one arrived after the application had already decided I was gone.

Other users describe the same frustration in simpler terms: the VPN drops during a Wi-Fi-to-mobile transition and does not recover cleanly without manual intervention. (Reddit: r/ProtonVPN)

That detail corrected my diagnosis.

The hotspot was not broken.

The airport Wi-Fi was not uniquely bad.

My VPN was treating every network change as a new beginning.

Reconnecting was not the same as continuing

I reached the train between terminals and opened the laptop again.

The VPN showed Connected.

The client portal showed a login page.

I entered my credentials for the third time.

Another verification code arrived.

This time, I reached the rollback screen. The service status read:

Restart in progress

I had no way to tell whether it had been in that state for thirty seconds or five minutes.

Then the train entered a section where the phone’s signal weakened.

The hotspot remained visible, but data stopped moving.

The kill switch blocked the laptop.

When mobile service returned, the VPN rebuilt its connection.

The portal expired again.

The provider had protected every new connection.

It had not preserved the task moving across them.

That was when I stopped looking for the fastest server. The comparison had changed from connection speed to handover speed.

I needed the network switch itself to become uneventful.

The smaller app began with movement

I had OnlydogVPN installed as a backup.

The service offers fewer server locations than the established provider, has a shorter public history and has accumulated fewer independent reviews. Someone who needs a particular city may consider that a meaningful limitation.

I did not need another city.

I needed the existing administrative session to remain alive while the underlying network changed.

The app organised its choices around situations rather than a server map. I selected the preset for working while moving between Wi-Fi and mobile networks.

It established one protected route.

I reopened the client portal.

I signed in.

The verification code arrived, and the rollback screen appeared.

The service status had changed to:

Restart complete

One final step remained. I needed to submit a test order and confirm that it passed through the repaired system.

I created the order.

The portal began processing it.

At that moment, the train reached the next terminal and the laptop detected airport Wi-Fi again.

I watched the network icon change from the phone hotspot to Wi-Fi.

The page paused.

The VPN did not fall into a long reconnecting state.

The order status moved from Submitted to Processing.

Then it changed to:

Completed

I refreshed the order list.

The twelve failed transactions had started moving again.

I sent the client a message:

Rollback verified. Orders are processing normally.

The reply arrived before I reached the escalator:

Confirmed here too. Thank you.

The urgent task was finished.

The network transition had still happened.

It simply had not become another login.

The technical difference was the handover

The service uses HTTP/3-based transport with additional traffic obfuscation. Its QUIC foundation can move an existing connection onto a new network path instead of rebuilding the entire session after every address change. (RFC 9000)

On the laptop, the result was brief:

The hotspot weakened.

Airport Wi-Fi became available.

The protected route recovered.

The portal continued.

I could not observe every internal routing or filtering decision made by the airport networks, mobile operator or client portal. I could observe what survived.

The established provider reconnected after each network change.

The smaller app recovered before the portal discarded my session.

For mobile work, that mattered more than how quickly a fresh tunnel could be created after the old one was already gone.

The phone solved the next problem

The gate was boarding by the time I closed the laptop.

I still needed to watch the client’s status channel until the first batch of delayed orders finished processing. The messaging app was already on my phone, but the smaller service was not configured there.

It allowed me to link the phone using a verification code.

I approved the code from the laptop and connected the phone without creating another conventional email-and-password account.

That feature had not saved the rollback. The main task was already complete.

It solved the next piece of friction.

I put the laptop away and joined the boarding line.

Near the jet bridge, the phone moved from airport Wi-Fi to mobile data.

The protected connection recovered.

A message appeared:

All delayed orders cleared. No new failures.

I acknowledged it and switched the phone to airplane mode before taking my seat.

For the first time that afternoon, a network change had become something the VPN handled rather than something I had to supervise.

What I now test before trusting network switching

I no longer test a mobile VPN by connecting once at a desk.

I begin with a real session that would be inconvenient to lose:

A work portal.

A voice call.

A cloud upload.

A remote terminal.

Then I force the transition that usually causes trouble.

I start on Wi-Fi and begin the task.

I move the laptop onto a phone hotspot without closing the application.

Then I return to Wi-Fi.

On a phone, I walk out of range of the access point and let cellular data take over.

Most importantly, I watch the application rather than the VPN icon.

A successful handover means the call continues, the upload resumes from the same position or the authenticated page remains open.

A failed handover means the VPN eventually says Connected, but the task above it has already restarted.

Kill switches and automatic reconnection still serve useful purposes.

The kill switch prevents traffic from escaping during the transition.

Automatic reconnection restores the tunnel afterward.

The deciding question is whether the session survives between those two moments.

My established provider still offered more countries, more protocol controls and a longer support history.

Those advantages did not keep the administrative portal alive while the laptop moved between airport Wi-Fi and my phone.

The smaller service offered fewer geographic choices, but its changing-network preset carried the protected session across the handover and allowed me to verify the rollback before boarding.

A VPN that reconnects after every network switch may protect the next task. The one I needed protected the task already in progress.