Why Your VPN Keeps Disconnecting, and How to Make It Stay Up

Six causes, in the order you should check them: sleeping devices, network switches, MTU, keepalive, battery optimisation and active blocking. Each with the setting that fixes it.

A VPN that disconnects every few minutes is worse than no VPN, because you cannot tell which traffic went through the tunnel and which did not. The frustrating part is that the connection usually is not broken in any meaningful sense - something on your device, in your router, or on the path deliberately took it down. Six causes account for nearly all of it. They are ordered here by how often they turn out to be the answer, so work down the list rather than starting with the exotic one.

One: no keepalive, and your router forgot you

This is the most common cause and the least known. WireGuard is deliberately quiet: it sends packets only when there is something to send. That efficiency collides with the way home routers work.

Your router keeps a table mapping your internal device to the external connection. Entries expire when idle, often after thirty to sixty seconds. If your tunnel sends nothing for a minute, the entry disappears, and packets coming back from the server no longer have a path to your device. Outgoing traffic re-establishes it instantly, which is why the connection appears to work the moment you touch it and appears dead whenever you return to it.

The fix is one line in the Peer section of your configuration:

• PersistentKeepalive = 25. Sends a tiny packet every 25 seconds, which is under every common expiry timeout, keeping the mapping alive at negligible cost in data and battery.

Configs we issue already include it. If you assembled a tunnel from a provider that omits it, add the line yourself - it belongs under Peer, not Interface, and putting it in the wrong section silently does nothing.

Two: the device went to sleep

Laptops suspend network interfaces on sleep, and when they wake the tunnel is stale: the interface exists, the client shows connected, and no packets move. Mobile devices do a harsher version of this, freezing background apps entirely.

What it looks like: the VPN is always dead after the machine has been closed, and reconnecting by hand always works immediately.

The fix on desktop is a client that detects wake and rebuilds the tunnel, which the official WireGuard clients do. On macOS also check that On-Demand is enabled in the tunnel settings. If you are using a hand-rolled setup with wg-quick, wire it to a resume hook, or accept a manual reconnect after each sleep.

Three: you moved between networks

Walk out of the house and your phone switches from Wi-Fi to mobile data. Your local IP changes and the tunnel, which was bound to the old interface, is now sending from an address the server does not recognise.

WireGuard handles this better than most protocols thanks to roaming: the server accepts a peer's new address once it receives an authenticated packet from it. But this only works if your client keeps sending, which brings you back to keepalive. Without it, roaming has nothing to trigger on.

On iOS, enable On-Demand in the tunnel settings so the connection is rebuilt automatically on network changes. On Android, Always-on VPN does the same, and it is under Settings, Network and internet, VPN, next to your client.

Four: MTU, the cause of the weirdest symptom

If your connection stays up but behaves strangely - text pages load, large downloads stall, video buffers forever, some sites never finish - the cause is almost always MTU.

Every packet gains overhead when wrapped by WireGuard. If the result exceeds what the path allows, it has to be fragmented or dropped. Fragmentation is often blocked, and the notification that would tell your device to send smaller packets is frequently filtered too, so your device keeps sending packets that vanish. Small requests fit and succeed; large transfers do not, which is exactly the pattern people describe as 'connected but broken'.

The fix: set MTU explicitly in the Interface section. Start at 1360 and work down in steps of 40 if the symptom persists. On mobile networks and PPPoE connections, values near 1280 are often required. This costs a fraction of throughput and removes the problem entirely.

• Connected but nothing loads is not a connection problem. It is almost always a packet-size problem, and it is fixed in one line.

Five: the phone killed your client

Android battery optimisation terminates background apps aggressively, and VPN clients are prime targets. Some manufacturer skins are far more aggressive than stock Android - the behaviour is well documented across vendors, and it is the reason a tunnel dies in your pocket but never while you are looking at the screen.

The fix on Android, in order of effect:

• Exempt the client from battery optimisation. Settings, Apps, your VPN client, Battery, set to Unrestricted.
• Enable Always-on VPN. The system rebuilds the tunnel itself rather than relying on the app staying alive.
• Enable Block connections without VPN. This is a system-level kill switch: while it is on, traffic outside the tunnel does not leave at all.

On iOS the equivalent is On-Demand, which the system honours reliably. iOS is stricter about background execution but better at keeping a VPN profile up, because the profile is a system object rather than an app process.

Six: something is blocking it on purpose

The previous five causes are accidents. This one is not, and it has a distinctive signature: the tunnel connects and then dies after a predictable interval, or it works on one network and never on another, or it stopped working nationwide on a date you can name.

Standard WireGuard has a recognisable handshake, and deep packet inspection identifies it in milliseconds. Once identified, it can be dropped, throttled, or allowed to connect and then killed - the last of which is deliberately confusing, because it looks like an unstable connection rather than a policy.

No MTU value fixes this, because the problem is not packet size but packet appearance. The answer is a protocol whose traffic does not look like a VPN: AmneziaWG, which pads and randomises the handshake, or VLESS/Reality, which imitates ordinary TLS. Our comparison of the three protocols covers when each is worth the overhead, and our configs include AmneziaWG profiles for exactly this case.

A diagnostic order that saves an evening

Rather than changing five settings at once, isolate the layer first:

• Does it drop on one network or every network? One network points at blocking or that router's timeouts. Every network points at your device.
• Does it drop when idle or under load? Idle means keepalive. Under load means MTU.
• Does it survive with the screen on? If yes, it is battery optimisation, not the tunnel.
• Does a different location behave the same? If one exit is stable and another is not, the problem is the path, not your configuration.
• Does it die at a consistent interval? A predictable number of seconds every time is a strong sign of active interference rather than an accident.

FAQ

Why does my VPN reconnect constantly on mobile data?

Usually two causes stacked: the mobile network changes your address more often than Wi-Fi, and battery optimisation freezes the client between uses. Enable On-Demand on iOS or Always-on plus a battery exemption on Android, and make sure PersistentKeepalive is set.

Is a reconnect dangerous?

It depends on your kill switch. During the gap between drop and reconnect, traffic can leave through your normal connection, exposing your real address. Android's Block connections without VPN prevents that at the system level, which is why it matters more than the reconnect itself.

Why does it stay connected but nothing loads?

MTU, in the large majority of cases. Set MTU to 1360 in the Interface section and retest; if the symptom persists, keep stepping down. A tunnel that is up while transfers stall is the classic packet-size signature.

My VPN worked and then stopped nationwide. Why?

That timing points at blocking rather than a fault. Standard WireGuard is fingerprintable and gets filtered as a category. Switch to an obfuscated profile such as AmneziaWG; no amount of reconfiguring plain WireGuard helps once it is being identified.

Does changing server location help?

It tells you where the problem is. If one exit is stable and another is not, the path or that host is the issue. If every exit behaves identically, the cause is on your device or in your router.

If the drops turn out to be deliberate: WireGuard vs OpenVPN vs AmneziaWG