Android’s Always-On VPN Is Active—So Why Is Your Phone Still Offline?

The contract upload stopped at 83 percent as I left the station café. My phone had moved from Wi-Fi to 5G, the VPN key was still visible in the status bar, and the VPN app still said I was protected. Yet Gmail would not send, the browser would not load, and the client’s last message—asking whether the document was coming—sat unanswered. I blamed the mobile network and toggled cellular data off and on. Nothing changed.

I had enabled Android’s two reassuringly named settings: Always-on VPN and Block connections without VPN. I assumed they meant the phone would keep the VPN connected wherever I went.

What they really meant was that Android would keep demanding a VPN connection—even when the connection itself had stopped working.

The key icon was only half the answer

I opened my established VPN app. It showed a green shield and the same nearby server that had worked all morning. I tapped reconnect anyway.

The animation spun. The phone still showed a strong 5G signal. Nothing reached the internet.

Because the VPN app had updated overnight, I restarted the phone. That was worth trying: Android 16 users have reported a system-level problem in which VPN connectivity can break after an app updates, leaving the device without internet until it is rebooted or the VPN is reinstalled. (Androidauthority)

After the restart, Gmail loaded and the contract upload began again.

For ten minutes, I thought the problem was solved.

Then I joined the station Wi-Fi while waiting for the train. The VPN connected, but when I walked toward the platform and the phone returned to 5G, the upload froze again. Turning Wi-Fi off did not revive it. The key icon remained in place while every app behaved as though the phone had no connection.

The restart had cleared one failure. It had not solved the problem that appeared whenever the phone changed networks.

That was the pattern I needed to understand.

“Always on” does not mean “never interrupted”

Android can start an always-on VPN when the phone boots and keep the VPN service active. But the app still has to maintain its connection to the VPN gateway. When that connection becomes stale, Android does not repair the tunnel on the app’s behalf. (Google)

The second setting makes the consequences more visible.

With Block connections without VPN enabled, Android refuses to send traffic outside the tunnel. That is exactly what the setting is designed to do. It prevents email, browser requests and background apps from quietly falling back to an unprotected connection.

But when the VPN app fails to recover, the protection feels like a phone-wide outage. Wi-Fi can show full bars. 5G can be available. The VPN key can remain visible. Nothing moves because Android is waiting for a usable tunnel.

Public user reports describe the same practical frustration in much simpler terms: the VPN still looks connected after a Wi-Fi or mobile-data switch, but internet access returns only after the user disconnects it, reconnects it or briefly enables Airplane mode. (Reddit)

That matched what was happening in front of me. The phone had not forgotten that a VPN existed. The tunnel had failed to follow the phone onto its new connection.

Once I saw the problem that way, changing servers seemed less promising—but it was still the obvious next attempt.

More servers gave me more resets

The established provider had been reliable on my laptop and home network. It also had years of public history, a large support operation and plenty of nearby servers.

I chose another one.

The VPN reconnected over 5G, and the contract started uploading from the beginning. Then the train arrived and the phone briefly joined the onboard Wi-Fi. The upload stopped.

I rejected the train network and returned to mobile data. The VPN app still showed a connection, but the upload did not continue until I disconnected the tunnel manually.

I tried one more server. It worked while the phone stayed on 5G. At the next station, the device detected public Wi-Fi and the tunnel stalled again.

Changing servers was useful only because it forced a fresh connection. It did not improve what happened during the handoff itself.

That changed the comparison.

On a stable network, the established provider was fast. It also offered far more locations than I needed. But my problem was happening in the few seconds when Android moved from one underlying connection to another.

The useful VPN was not necessarily the one with the best speed result after the connection had settled. It was the one that could recover before Android’s blocking rule turned a brief network change into several minutes offline.

The next app asked what I was doing

I had OnlydogVPN installed as part of the testing behind this article. Its interface did not begin with a long list of countries, cities and numbered servers. Instead, I selected a preset intended for a weak or changing connection.

That removed the choices that had not helped me. I did not need to guess which nearby city might reconnect better. I needed the tunnel to survive the way I was actually using the phone.

I connected and restarted the contract upload.

It passed 83 percent.

This time, I left Wi-Fi enabled. As the train pulled away, the station network disappeared and the phone returned to 5G. The upload paused for a moment, then continued.

I did not reopen the VPN app. I did not choose another server. I did not toggle Airplane mode.

The document sent.

The client replied with the countersigned version, and I downloaded it before the train entered the next weak-signal section. The task that had turned Android’s Always-on setting into an emergency was complete.

Only then did I look at why the result had been different.

The smaller app uses HTTP/3-based transport and is designed to recover on weak or changing networks. The protocol label mattered less than the behavior: when the underlying connection changed, the tunnel rebuilt itself quickly enough for the upload to continue.

I could not see Android’s or either app’s internal reconnection decisions, so I could not assign every stalled packet to one exact cause. What I could reproduce was the result. The established app repeatedly required manual intervention after network changes. The smaller app recovered and completed the upload.

That was the only comparison that mattered on the train.

The Android setting was doing its job

At that point, turning off Block connections without VPN would have been tempting.

It also would have solved the wrong problem.

Disabling the setting can make the phone appear more reliable because apps are allowed to continue over ordinary Wi-Fi or mobile data whenever the VPN stalls. The outage disappears, but so does the guarantee that traffic remains inside the tunnel.

The blocking setting had not failed. It had exposed the app’s slow recovery.

That distinction matters because two similar-looking Android VPN problems need different responses.

If a VPN suddenly stops reaching the internet immediately after an Android 16 app update, and restarting the app or changing servers does nothing, rebooting the phone is the sensible first move. The operating system may be stuck in the reported update-related failure state.

But when the outage repeatedly follows the same event—leaving home Wi-Fi, joining office Wi-Fi, walking out of a café or moving onto mobile data—the more useful test is a handoff.

Start an upload, stream or call while connected to Wi-Fi. Turn Wi-Fi off and let the phone move to cellular data. Then restore Wi-Fi.

Do not judge the result by whether the key icon remains visible.

Judge it by whether the task continues without opening the VPN app.

That small test reveals more about Android Always-on performance than a server list or a speed score measured while the phone sits still.

Why I kept the blocking setting enabled

The smaller service has a shorter public history, fewer independent ratings and fewer server locations than the major provider. Someone who needs a long list of specific countries may reasonably value the larger network.

That was not what I needed during the journey.

I needed to keep Android’s blocking protection enabled without repairing the VPN every time the phone noticed another access point. The established provider gave me more destinations, but its stalled handoffs repeatedly left the device offline. The smaller app gave me fewer decisions and recovered while the upload was still in progress.

Android can keep a VPN service present. It cannot make that service good at moving between networks.

For a phone that goes dark between Wi-Fi and 5G, reliable recovery matters more than the word “Always” in Settings.