Why Your VPN Keeps Disconnecting: Idle Timeouts, Roaming and the MTU Loop (2026)

“Unstable connection” is not a diagnosis. A tunnel that dies after exactly five minutes of inactivity, one that dies when you walk out of the door, and one that dies during large downloads are three unrelated faults that happen to share one symptom. The pattern tells you which you have, and the pattern is free to observe.

Read the pattern first

• Drops when the screen has been off a while, recovers when you unlock → power management. The tunnel is being killed, not failing.
• Drops when you move between Wi-Fi and mobile, or between access points → roaming.
• Drops after a fixed, repeatable interval of doing nothing → an idle timeout, on the server or on something in the middle.
• Drops during large transfers, fine when idle → MTU.
• Drops after a few minutes of heavy use on one network only → the network is identifying and throttling the tunnel.

Power management: the tunnel is being killed

The most common cause on phones and laptops by a wide margin, and the one least often recognised, because from the outside it looks exactly like an unreliable server. It is not: the operating system suspended the VPN process to save battery, and the tunnel went with it.

1. 1Android: Settings → Apps → your VPN → Battery → Unrestricted. On Xiaomi, Samsung, Oppo and OnePlus also enable autostart and remove the app from any sleeping-apps list — those layers are considerably more aggressive than stock Android.
2. 2iOS: turn off Low Data Mode for the network in question, both under Wi-Fi and under Mobile Data Options.
3. 3Windows: Device Manager → your network adapter → Power Management → clear “Allow the computer to turn off this device to save power”.
4. 4macOS: check that “Put hard disks to sleep” and aggressive Low Power Mode are not in play on battery.

Details specific to each platform are in the Android guide and the iPhone and iPad guide.

Roaming: the network changed underneath the tunnel

Every tunnel is anchored to a local address. Change networks and that address changes, so the tunnel has to be rebuilt. How gracefully depends entirely on the protocol.

• WireGuard handles roaming well: it is connectionless and simply resumes from the new address, usually within a second.
• IKEv2 handles it deliberately well through MOBIKE, which is why it has been the mobile default for years.
• OpenVPN over TCP handles it worst — a TCP session cannot survive its endpoint moving, so it must be torn down and rebuilt.
• Wi-Fi Assist on iOS and its equivalents elsewhere make this happen more often than you would expect, by switching you to mobile data whenever Wi-Fi weakens rather than when it fails.

Idle timeouts, and the middlebox nobody mentions

If the drop happens after a consistent, repeatable period of doing nothing — five minutes, thirty minutes, an hour — something is enforcing an idle timeout. It is not always the VPN server. Corporate firewalls and carrier NAT devices expire idle mappings on their own schedule, and when the mapping is gone your packets have nowhere to return to.

1. 1Enable persistent keepalive in the client. For WireGuard, PersistentKeepalive = 25 is the standard value: it sends a tiny packet every 25 seconds, which keeps NAT mappings alive without meaningful battery or data cost.
2. 2If the client has no such setting, a background ping to the tunnel gateway achieves the same thing crudely.
3. 3If the interval is exactly the same every time, note it — a timeout that repeatable is a configured value somewhere, and it identifies which device is doing it.

The MTU retransmission loop

This one deserves its own section because it does not look like an MTU problem. The tunnel is stable while idle and collapses under load. What happens is that oversized packets are dropped silently, the sender retransmits them unchanged, they are dropped again, and eventually the client decides the link is dead and reconnects. The cause is packet size; the symptom is a disconnect.

The tell is that it correlates with activity rather than time. If the tunnel survives an hour of nothing and dies ninety seconds into a download, stop looking at stability settings and go to MTU and fragmentation.

When the network is doing it on purpose

The last pattern is the least pleasant. The tunnel connects, works for a few minutes, then degrades or drops — and only on one network, reproducibly. That is a system identifying the traffic and acting on it: a corporate filter, a hotel's traffic shaper, or a carrier that treats tunnelled traffic differently from the rest.

1. 1Confirm it is the network: run the same client on a phone hotspot for the same period. If it stays up, the network is the variable.
2. 2Change what is visible to that network — a protocol carried inside an ordinary TLS session on port 443 is not distinguishable from normal browsing by the mechanisms that do this.
3. 3Do not confuse this with bandwidth. Throttling of a recognised tunnel and a slow connection look different: throttling starts fine and gets worse, a slow connection is slow from the first second. Measure it properly before deciding which you have.

The mechanisms behind identification, and what actually resists them, are covered in TLS fingerprinting and VLESS Reality.

Frequently asked