Does a VPN really drain your battery? What to measure first

Battery drain that appears after a VPN is switched on is usually a change in workload wearing a different label. A tunnel that sits idle, a nightly backup and a client reconnecting every few minutes consume very different amounts of power. The icon in the status bar cannot tell you which of those you are looking at.

Separate the tunnel from what it carries

A photo backup or a video call pushes data that the VPN then has to encrypt, authenticate and forward. Some of that power cost belongs to the application that generated the traffic, and only part of it belongs to the tunnel itself. Reading a battery report next to network and screen statistics is how you split the two. Start there before you change a single setting.

Platform reporting also attributes work in its own way. A component labelled as the VPN may include radio time that would have been spent anyway, and it rarely isolates cryptographic overhead on its own. Treat the percentage as a starting point rather than a measurement.

adb shell dumpsys batterystats --charged com.example.vpn | head -60
adb shell dumpsys netstats detail | head -40

The first command prints per-component power attribution for the last charging cycle. The second shows which interfaces moved how much data, which is the context that turns a percentage into a workload description. Compare the two before drawing a conclusion about the tunnel.

If the device runs hot during transfers, compare clients or protocol settings under identical conditions. Weakening cryptography to chase a power number trades a known cost for an unknown one.

Reconnects keep the radio awake

An idle-looking screen does not mean an idle network. Messaging, sync and update checks still send packets, and each small exchange can wake the radio for far longer than the packet itself lasts. That difference between packet duration and radio-on time is where idle drain hides. It also explains why an idle tunnel can still cost more than an idle device.

Keepalives exist for a reason: they hold a NAT mapping open or detect a peer that has gone away. Their interval belongs to the protocol and the network in use. Disabling them may reduce activity while making the tunnel unusable after an idle stretch.

grep -i keepalive /etc/wireguard/wg0.conf
wg show wg0 latest-handshakes

The first shows whether a persistent keepalive is configured and at what interval. The second shows when the last handshake happened, which separates a quiet tunnel from one that keeps rebuilding itself.

Connection history matters most when drain begins after moving between networks. Fixing repeated recovery is usually worth more than switching between exit locations, because a client that reconnects constantly spends power on recovery rather than on transfer.

When the platform suspends the tunnel

Operating systems restrict background execution, and a tunnel that vanishes when the screen turns off may be a casualty of that policy rather than a server failure. From the user's side the two look identical, which is why the platform log matters.

Exempting every application from power management changes the workload and makes any later comparison meaningless. Exempt the VPN client and the one application that needs it, then measure again against the same baseline.

Decide separately what should happen after sleep. Always-on operation, a block-without-VPN rule and ordinary battery optimization answer different questions, and a setting that saves power by silently dropping required coverage has not met the original requirement.

Compare like with like, then decide

Use the same task, the same network and the same duration for both runs, and note transferred volume, reconnect count, temperature and signal strength. Short battery percentage changes are noisy, so a repeated pattern under comparable use is the only evidence worth acting on. One run is an anecdote.

Move optional large transfers to a charger and an unmetered network where the schedule allows. Then look at the whole day again, because a tunnel that idles for hours costs far less than one that is busy for twenty minutes.

Write down what you changed and what the second run showed. Without that record the next comparison starts from a different baseline and the same argument restarts from zero.