Does a VPN Drain Your Battery? What the Radio Was Already Doing

A drain complaint usually arrives as "the VPN eats my battery", which is a conclusion rather than an observation. What the measurement shows is that some mixture of transfers, radio wake-ups and reconnects kept the device busy. Encryption contributes to that bill, and on a modern phone it is rarely the largest line. Separate the three and the complaint becomes something you can actually test.

What a Tunnel Adds to a Packet's Journey

Every packet the tunnel carries is authenticated, encrypted, wrapped in another header and unwrapped at the far end. That work costs processor cycles and, more importantly, keeps the network interface busy for longer than the payload alone would. A backup that runs for ten minutes through a tunnel is still a ten-minute backup with slightly more overhead per packet. The bytes and the duration come from the application, not from the tunnel.

That is why a percentage in a battery report is a poor guide to overhead. The report attributes work by component, and the attribution rules differ between platforms.

Read the report next to a network counter and the screen-on time. When the transfer window matches the drain window, the workload explains the result and the protocol is an afterthought. When drain continues while the counters sit flat, something is holding the radio awake, and the next section is where to look.

Keepalives, Reconnects and the Radio's Awake State

A screen that looks idle does not prove an idle network. Synchronisation, messaging and update checks all send small amounts of traffic, and each one can pull the radio out of a low-power state for much longer than the exchange itself lasts. Small frequent traffic is expensive per byte because the fixed cost dominates.

A tunnel adds its own small traffic as keepalives, which exist to hold a NAT mapping open or to notice a peer that has gone away. Their purpose depends on the protocol and the network, and switching them off may reduce activity while leaving the tunnel unusable after an idle period. If you test a different value, record the original and confirm the tunnel still recovers afterwards. Never import an interval from another protocol, because a constant that suits one design is arbitrary in another.

Connection churn is the second cost. A client reconnecting every few minutes spends its time on handshakes instead of on payload, and the radio never gets a chance to settle.

When the Platform Stops the Tunnel to Save Power

Mobile operating systems restrict background execution, and a tunnel is not exempt from that policy. A connection that disappears when the screen turns off is usually a platform integration problem rather than a server refusing the session. The client's own battery guidance is the place to start, because it describes the supported way to stay connected across sleep.

Exempting everything from power management is not a fix. It creates a different workload and destroys the comparison you were trying to make.

Then decide what should happen when the device sleeps, because always-on operation, block-without-tunnel behaviour and battery optimisation answer three different questions. A setting that saves power by quietly dropping required coverage has not preserved the original goal, it has concealed the failure. Write the intended policy down before tuning anything. Without that, you end up choosing between a tunnel that drains and a tunnel that is simply absent, and calling either outcome a success.

Set Up a Comparison Instead of a Belief

Compare like with like: same task, same network, same duration, similar signal. Record the data transferred, the reconnect count, the device temperature and the signal conditions, because any one of those can move the result by itself. A few percent of battery over an hour is inside the noise of most phones, while a repeatable pattern across several runs is not. The Android VPN guidance describes the lifecycle and always-on behaviour a well-behaved client follows, which is useful context when one does not.

Move optional large transfers to a moment when power and network are both cheap.

Then act on what the comparison showed. If workload explains it, schedule the workload. If churn explains it, fix the network transition causing the churn. If the platform explains it, follow the supported battery policy for that client. Weakening cryptographic settings is the single change that improves the number while leaving the cause untouched, which is why it should be the last thing anyone reaches for.