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, so instead of guessing we can say what actually broke them.

“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.

How much of this is our own fault

An article about phones killing the connection turns very easily into a convenient “nothing to do with us”. So we went into our own server journals for the same two weeks and counted our share honestly. Here is what 22 August — 5 September 2026 looks like.

861 connection attempts, 76 of them failed. Eight of those 76 were a person pressing the button; the other 68 were healing attempts: the tunnel went quiet on its own, the app walked all four paths in turn and could not bring up a single one. That is exactly what “went to sleep protected, woke up without it” looks like from the inside.

Now about us. Every exit point reports to the control server roughly every 77 seconds. Over two weeks those reports failed to arrive three times:

Twenty of the 76 failed connections fall exactly inside those windows — one in four. During those minutes people could not connect not because their phone was saving battery, but because there was nowhere to connect to. Our monitoring caught each of the three within 4–10 minutes and raised an alert; all three ended on their own.

And now the unpleasant part. During the longest of them, on 25 August, three different people failed to connect one after another — eighteen attempts in seventeen minutes. One of them later wrote to us “it keeps disconnecting”, and the first thing we started studying was their phone. The alert about our own outage was already sitting in the duty chat at that moment — nobody put the two together. That is not about phones and not about Android: that one is on us.

What we take from it: a complaint about drops now starts not with the phone but with the question “what was happening on our side during those minutes”. The numbers earlier in this article still stand — the background restriction sits on almost every phone and really does break connections. It just does not explain everything, and blaming it for everything would be convenient and untrue.

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.

It drops when I open a game or YouTube

A separate and very common picture: the tunnel sits quietly, but the moment you open a heavy app — a game, YouTube, a bank — the connection breaks at once. People describe it differently: “it crashes”, “it interrupts”, “it drops as soon as I go in”. There are two causes here, and they are different.

• The system needed memory. A game is the hungriest neighbour of all; when it starts, the system frees RAM for it and closes background processes. The process holding the tunnel is just as background as the rest. This is the same mechanism as cause one, except it fires instantly rather than after an hour of idling — which is why it looks like “the game knocked it out”. The fix is the same: lift the background restriction and, on vendor shells, add the app to the protected list.
• The app itself dislikes tunnels. Some games and banking apps check for a VPN and refuse to work. Telling this apart from the first case is easy: look at whether the VPN icon is still lit and whether other sites open in the browser. If the tunnel is alive and only one app complains, nothing was broken — and battery settings will not help. If the tunnel is alive but the game’s ping jumps or it shows a “network error”, the problem is the path to the game server — a separate piece covers that.

The question most often asked in these words is whether Chinese phones interrupt VPNs. The honest answer: we have no measurement of our own by brand. Over the past month telemetry arrived from nine devices — you cannot compare Redmi with Honor on that, nor either of them with Samsung, and we will not pretend otherwise. What we can say with grounds: it is not about where the phone was assembled but about the vendor shell. Xiaomi, Honor, vivo and OPPO layer their own autostart and “protected apps” rules on top of Android, and the system “Unrestricted” switch is not enough for them — see above. On our own numbers the background limit was in place in 24 checks out of 28 on vivo, and that is the only brand for which we have any measurements at all.

It turns on and off every few seconds

One more picture described separately: the VPN icon blinks, the connection comes up and immediately falls, round and round. Here it is fair to say that part of that blinking is us.

While the app waits for the server to answer, it may re-raise the tunnel — that is cheaper than waiting it out, and usually nobody notices. But the system draws the icon on every raise, and from the screen it looks like “on and off”. In the journal for 21 August — 8 September 2026 this happened in 38 connections out of 401 that reported this counter: 31 times the tunnel was re-raised once, 7 times twice.

So blinking in the first seconds of connecting is most likely normal work, not a fault. What is worrying is different: if the blinking goes on for minutes and there is still no connection, that is a different case, and it is closer to “a VPN that worked yesterday stopped working”.

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.

One more cause has nothing to do with the phone: if the same key or config file is also used on a second device, the server remembers one address per key and the two devices keep snatching it from each other, so the link breaks for both, taking turns. We measured it separately — one key shared by two devices; the only cure is a key of its own for every device.

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.