VPN Drops When the Screen Turns Off: Which Lifecycle?

The transfer stops the moment the screen goes dark, and the badge follows a few seconds later. Three different things produce that picture: the client process gets restricted, the path goes idle and loses its mapping, or the application loses a session the tunnel never noticed. Each has its own evidence, and each fix belongs to a different layer. The order below separates them with one controlled test instead of a settings sweep.

Three Failures That Look Identical

A restricted background process stops sending keepalives, and the peer eventually declares the tunnel dead. An idle mapping on the path can expire while the device sleeps, so return traffic never reaches a client that is still perfectly alive. An application can lose its own connection while the tunnel stays up, which produces an error dialog with a healthy VPN badge behind it. From the user's seat all three read as the VPN dropped at screen-off.

The distinction matters because the remedies contradict each other in practice. Exempting the client from power restrictions fixes the first case and does nothing for a mapping that expired. Extending keepalives fixes the second and wastes battery in the third, where nothing network-related was wrong to begin with.

Compare Active and Idle Under Control

Hold everything constant: same device, same network, same endpoint, same application. Lock the screen for a short fixed interval and note three observations, namely whether the client reports a disconnect, whether a fresh request works on unlock, and whether the existing transfer resumed. Then repeat with a keepalive or a periodic request running and compare the two runs. One variable changed between two runs beats a week of anecdotal reports.

Timing belongs in the record. A drop after ninety seconds smells like a mapping or a keepalive interval, while a drop at the moment of lock points at process suspension. Write down both the trigger and the interval, because the next attempt needs something to compare against.

Read the Platform's Background Policy

On Android the VPN service lifecycle is part of the platform, and always-on plus block-without-VPN are separate switches with separate effects. A client that is not always-on can be stopped when the system reclaims resources, and no in-app setting changes that. iOS applies its own background limits to the tunnel provider, and the documented behaviour differs from a desktop daemon that simply keeps running. Read the platform documentation for the component in question rather than a generic battery-optimisation guide.

Managed devices add another layer. A policy can override a personal setting, so a change that appears to work reverts at the next policy refresh. Use the organisation's supported exception process if the requirement is genuine, and write down why the exception exists.

What the Device Does After Wake

Automatic reconnection is not the same as blocking traffic during the gap. Check both: whether the tunnel returns, and whether an application that tried to send during the gap went out unprotected. A client that reconnects in two seconds while leaking a DNS query in the first one has the wrong failure policy for a work device. Test with harmless requests and a destination you control.

Application recovery is the third question. A tunnel that returns does not repair an SSH session that timed out, and users often report that session loss as the VPN failure. Keep the trigger, the client build and the exact timing together in the report, because that combination separates a predictable screen-off lifecycle from a server failing independently of the device.