VPN keeps disconnecting: the phone is usually to blame, not the network

The connection held for an hour and then vanished. Or it dropped twenty seconds after you pressed the button. Or the phone spent the night on the charger and the shield icon was gone by morning. We keep a log of these cases, and it says something specific: in the overwhelming majority of our measurements the tunnel was broken neither by the network nor by the server, but by the phone itself, to save battery. Below are the numbers, four causes in order of frequency, and the one that takes two taps to fix.

“Disconnected” is three different events

Before hunting for a cause, separate the cases. The app records them differently, and that is not bookkeeping: the three events have three different fixes.

The measurement window is 27–31 August 2026. Nine drops across 97 connections is a small number, and we are not going to pretend it is a statistic. But those nine have a shape, and the shape says more than the count. Here is how long each tunnel lived before it broke:

23 · 23 · 23 · 27 · 31 · 66 seconds, then 27 minutes, 3.5 hours and 11.6 hours.

Two clusters, two different problems. Six drops out of nine happened within the first 66 seconds: the tunnel came up, but there was no real way out behind it — which happens when a connection is formally established while no traffic passes through it (we covered that separately in “Connected, but there is no internet”). The remaining three are the opposite: the link worked for hours and then was lost. Those are the real “my VPN disconnected by itself”, and the rest of this article is about them.

Cause one: the phone is saving battery

Android limits background work for apps by default. That is sensible — otherwise fifty programs would wake the phone all night — but for an app whose whole job is to hold a tunnel, the limit takes away exactly the thing it was started for. The app does not “crash”: the system puts its process to sleep, timers stop ticking, service packets stop going out, and after a while the connection is dead even though the icon is still there.

How common is that? We can answer from our own numbers. The app has a connection self-check: you tap a button, the program collects a few dozen facts about the phone and the network and produces a verdict. Along with the facts it records whether the background limit has been lifted. Between 7 and 31 August 2026 there were 158 such checks from real phones, across six models.

143 checks out of 158. Three models out of six were never free of the limit. And this is not “power saving mode is on” — we record that separately, and across all 225 diagnostic reports (these 158 plus our test devices) it was on in exactly one, with deep sleep caught in two. The limit is simply the default: quietly, on an ordinary phone with a full battery.

The second number is about consequence rather than state. The self-check ends with a one-word verdict, and here is how they landed on those same real phones:

Of the 17 checks where something was wrong, eight named the background limit as the cause — more than any other: eight against five for a dead tunnel and three for a missing network.

Vendor shells are a story of their own. Huawei and Honor keep a list of “protected apps”; Xiaomi has “Autostart” and a per-app battery saver; vivo and OPPO have both under their own names. The system “Unrestricted” switch is not enough there: until the app is on the vendor’s list, the shell will put it to sleep by its own rules. Our own measurement agrees — on the vivo the limit was in place in 24 checks out of 28.

Cause two: silence inside the tunnel

The second cause works completely differently, and nothing about it is visible: the tunnel goes quiet.

Between the phone and the server there is always someone else’s equipment — a home router, the carrier’s network. It remembers where to send replies for a limited time, and if nothing has travelled the connection for a while, the entry is simply dropped. The phone learns nothing: outgoing packets still leave, incoming ones no longer arrive. From the outside it looks like “the VPN disconnected by itself”, although neither side closed anything.

The cure has been known for years and costs one config line: PersistentKeepalive — a tiny service packet on a timer. It carries no data; its job is to keep the routing entry fresh.

Our configs use 10 seconds rather than the usual 25, and not out of caution. Our exits run the AmneziaWG module, which tells its own service packet from ordinary data by one thing only — its length. But the same module prepends filler bytes to every packet, so the length never matches: the server takes its own service packet for data and waits for a reply that the protocol cannot produce. After 15 seconds of waiting it starts a fresh key exchange — and round it goes. An idle phone was renegotiating keys about every 15.6 seconds: extra radio work, extra battery drain, extra traffic. Any packet from the client clears that countdown, so we set 10 seconds — under 15 with room to lose one packet on the way.

The practical takeaway for anyone configuring a client by hand: check that the PersistentKeepalive line is there at all. Without it the connection lives exactly until the first long pause. What every config line means is covered separately in “How to configure AmneziaWG”.

Cause three: the network changed

You walk out of the house and the phone moves from Wi-Fi to mobile data. Its address is now different and the server does not know that yet: it keeps replying to the old one. WireGuard-family protocols survive this — the server learns the new address from the first correctly signed packet it receives. But a packet has to go out for that. If the phone is asleep at that moment (see cause one) or the tunnel is silent (cause two), the link comes back with a delay, and a person reads that delay as “it dropped”.

This is the one cause where waiting makes no sense: the network changed, so the tunnel must be rebuilt at once. Our app does exactly that; in the log it is a separate kind of self-healing — a rebind to the new network, seen once during the measurement window.

Two smaller things belong here as well, both usually blamed on the VPN. First: on some firmwares Wi-Fi sleeps together with the screen, and then every connection dies on lock, not just the tunnel. Second: hotel and airport networks with a sign-in page periodically throw the client back to that page — which always breaks the tunnel.

Always-on VPN and blocking connections without it

Android itself has two switches few people know about. Settings → Network & internet → VPN → the gear next to the app:

• Always-on VPN — the system brings the tunnel up when the phone boots and restores it if it falls;
• Block connections without VPN — what English-language articles call a kill switch: while there is no tunnel, the phone has no internet at all.

The first is worth turning on for almost everyone. The second has a price you should know in advance: with it the phone cannot open a hotel Wi-Fi sign-in page (and without that page there is no internet to bring the tunnel up either), and any breakage on our side becomes a total loss of connectivity for you rather than “sites open directly”.

What the app does on its own

Everything above is a problem the app is supposed to handle without you. Here is how ours does it:

• A tick every 3 seconds. The liveness watchdog lives as long as the tunnel does and survives the screen being closed: minimise the app and it keeps working. Until the end of July 2026 the watchdog lived inside the screen, and the notification froze on its last word; we measured 42 seconds in a row during which a person was being told “Protected” with the network switched off.
• It judges by facts, not by the icon. In order of reliability: is there any physical network at all; did the received-bytes counter grow since the last tick; is the handshake with the server fresh. All of it local and free, with no outside requests.
• It heals, but only on an external trigger. One rule: a working tunnel is rebuilt when something new happened outside (the network changed, traffic stopped), not when time has merely passed. We shipped an automatic “just in case” restart twice and made things worse twice.
• It walks the paths. If the link does not come back, the app tries the connection steps in order — covered separately in “Three paths to the network”.

During the measurement window every one of the nine drops was accompanied by self-healing in the same millisecond: the app noticed the loss and brought the link back up without waiting for a human.

What these numbers do not say

The most important part, and we would rather say it ourselves.

• This is not “user statistics”. 158 connection self-checks from six models and five accounts, nine drops over five days. The phones here are our own and those of people close to the project. A sample like that can explain how things work; it cannot promise “yours will behave the same”.
• “Background limited” ≠ “that is why it dropped”. 143 out of 158 is the state of the phone at the moment of the check, not a proven cause of a drop. The background limit was named as the cause in eight cases — a stricter claim, and the one that matters here.
• Three 23-second drops came from three different debug builds — almost certainly one and the same test phone rather than three separate cases.
• We do not know the cause of each individual drop. The “reason” field in our log currently says the same thing in all nine rows — “self-healing noticed it” — which answers “who saw it”, not “what happened”. That is our own shortcoming, not a fact of nature, and we are naming it here plainly.
• The window is short. The app event log was created at the end of August 2026 and the self-checks have been accumulating since 7 August. In a month these same rows will carry different weight.

If the link still breaks after all of the above, it is worth running four checks in a minute to see which step exactly is failing.