VPN Keeps Disconnecting On Mobile Data
Short answer
Phones drop VPN tunnels for two reasons: battery optimisation killing the client in the background, and the network address changing as you move between cells or between Wi-Fi and mobile data. Exempt the VPN app from battery optimisation first, then switch the protocol to WireGuard or IKEv2, both of which survive an address change without rebuilding the tunnel.
On this page
A VPN tunnel on a phone is fighting two things a laptop never deals with: an operating system designed to kill background processes, and a network address that changes as you walk down a street.
Both produce the same symptom. Neither is a fault with the VPN service, and both have settings that fix them.
Which of the two is yours
| When it drops | Likely cause | Fix |
|---|---|---|
| After the screen has been off a while | Battery optimisation | Stop the system killing it |
| Moving between Wi-Fi and mobile data | Address change | Pick a protocol that survives it |
| While walking or on a train | Cell handoff | Same as above |
| In a specific building or area | Weak signal, or a filtering network | Signal and filtering |
| Every few minutes regardless | Carrier-grade NAT timeout | Keepalive |
Work out which pattern you have before changing anything. The fixes do not overlap, and applying all of them at once tells you nothing.
Stop the system killing the client
This is the most common cause on Android and the easiest to fix.
Android suspends background apps aggressively to save power. A VPN client that gets suspended cannot maintain its tunnel, and depending on the implementation it may not notice it has been suspended until you unlock the phone.
- Android: Settings → Apps → your VPN app → Battery → set to Unrestricted. The exact wording varies by manufacturer; Samsung puts a second layer under Settings → Battery → Background usage limits, where you may need to remove the app from the sleeping-apps list.
- Also check: Settings → Apps → your VPN app → Mobile data → ensure background data is allowed and data saver is not restricting it.
Manufacturer battery management is the recurring culprit here. Several Android makers ship far more aggressive policies than stock Android, and they survive app updates. If the app works for an hour and then silently dies, this is almost certainly it.
On iOS there is no equivalent exemption. The system manages background execution and you cannot override it. What you can do is enable the VPN profile’s Connect On Demand option, where the provider’s app offers it, which asks iOS to re-establish the tunnel when network traffic starts.
If the pattern reminds you of apps that stop notifying you, it is the same mechanism: delayed Android notifications covers the battery policies in more detail.
Pick a protocol that survives the handoff
The older way of building a tunnel binds it to your device’s IP address. When that address changes, the tunnel is invalid and has to be rebuilt from scratch.
Two protocols handle this better:
- WireGuard identifies peers by cryptographic key rather than by address, so a changed address does not invalidate the session. It resumes almost instantly, often without the app showing a disconnection at all.
- IKEv2 has an explicit mobility extension designed for this exact case, which is why it was the default on phones for years.
In the client’s settings, under Protocol or Connection, choose one of those two explicitly rather than leaving it on Automatic. OpenVPN is the one to avoid on mobile; it is perfectly reliable on a fixed connection and poor at handoffs.
When the carrier’s NAT table forgets you
Mobile carriers almost universally put subscribers behind carrier-grade NAT, sharing public addresses across many customers. The NAT table has a timeout, and an idle UDP conversation gets evicted.
The symptom is a tunnel that drops after a consistent period of inactivity — often a few minutes — and reconnects as soon as you use the phone.
The fix is a keepalive, which sends a tiny packet periodically to keep the entry alive. In WireGuard configurations this is PersistentKeepalive, usually set to 25 seconds. Some clients expose it as “keep alive” in advanced settings; others set it automatically.
The cost is negligible data and a small battery impact from waking the radio. It is worth it if this is your pattern, and pointless if it is not.
Weak signal and filtered networks
Not everything is a configuration problem.
A tunnel on a connection with heavy packet loss will drop, because the protocol eventually decides the peer is unreachable. In a basement, on a train through cuttings, or at the edge of coverage, the VPN failing is downstream of the connection failing. Check whether ordinary browsing is also struggling before blaming the tunnel.
Some networks also filter. Corporate guest Wi-Fi and a few public networks block the UDP ports VPN protocols use, which produces a connection that establishes and then stalls. Switching to OpenVPN over TCP port 443 makes the traffic resemble HTTPS and usually gets through, at a meaningful cost in speed.
Always-on, and why it is not the same fix
Android offers Always-on VPN alongside the block-without-VPN toggle, and people reach for it when disconnections are the complaint. It helps with one cause and not the others.
Always-on tells the system to re-establish the tunnel whenever it drops, and to start it at boot. That genuinely addresses a client killed by battery optimisation, because the system brings it back. It does nothing about a weak signal, and it does nothing about a protocol that cannot survive an address change, since in both cases the tunnel is being rebuilt repeatedly anyway.
The setting lives under Settings → Network & internet → VPN → the gear next to your VPN → Always-on VPN. It requires the VPN to be configured with stored credentials, so a client that prompts for a login each time will not accept it.
The cost is that a reconnection loop in poor coverage becomes continuous rather than occasional, which uses battery. If you enable always-on and your battery life gets noticeably worse, that is the signal to go back and fix the underlying cause instead.
The kill switch interaction
If you have a kill switch or Android’s “Block connections without VPN” enabled, every one of these disconnections becomes a complete loss of connectivity rather than a brief gap.
That is the feature working correctly, and on a phone it is considerably more disruptive than on a laptop because the drops are more frequent. When a kill switch is worth having goes through the trade-off; on mobile data specifically, the answer is usually no.
Realistic expectations
With battery optimisation disabled and WireGuard selected, a VPN on a phone should stay connected through normal use including network handoffs, with occasional brief reconnections you will not notice.
What will not go away entirely is dropping in poor coverage. The tunnel cannot be more reliable than the connection underneath it, and a mobile connection in a lift is not reliable. Any client claiming a tunnel in those conditions is simply queueing packets that are not going anywhere.