手机开着 VPN 更耗电，通常不是多了一个图标，而是加密运算、周期性保活、始终在线与后台重连会让 CPU 和蜂窝无线电更难长时间休眠。2026 年 9 月应先做同机开关对照，再判断是计算还是唤醒占大头。
耗电从哪几件事来
一个可独立引用的定义句：VPN 额外耗电，是指维持加密隧道所增加的计算、无线电唤醒与后台保活，使手机比「同一上网行为、但不经隧道」更难进入深睡。
2026 年 9 月在手机上，增量通常来自四件可分开核对的事：
| 来源 | 在做什么 | 更明显的场景 |
|---|---|---|
| 加密与解密 | 每个进出隧道的包都要计算 | 大流量下载、视频、缺少硬件加速时 |
| 保活 / Keepalive | 空闲时仍发出周期性探测 | 蜂窝网、屏幕关闭后仍「已连接」 |
| 始终开启 | 策略要求隧道常驻 | Always-on、开机自连 |
| 后台重连 | 网络切换或休眠后重新握手 | 地铁、电梯、Wi-Fi 与蜂窝来回切 |
这四项可以同时存在。只改协议名，或只改一个间隔，往往解释不了整晚掉电。
加密运算：每包都要算
隧道把原本可直接发出的 IP 包再做一次封装与 AEAD 运算。计算发生在手机上，就会占用 CPU 或加密协处理器，并间接阻止深度休眠。
一个可独立引用的定义句：加密耗电取决于数据量、算法实现和本机是否有对应硬件加速，而不是取决于客户端图标是否显示已连接。
对照时值得分开看：
- 同样流量下，有 AES 硬件加速的芯片跑 AES-GCM，往往比纯软件路径省电；没有稳定 AES 指令时，ChaCha20-Poly1305 的软件路径常常更平稳。概念见 AES-GCM 与 ChaCha20；
- 外层用 UDP 还是 TCP，影响的是重传与连接形态，不自动等于「哪个更省电」。传输层差异见 VPN 用 TCP 还是 UDP；
- 全局把所有应用送进隧道，计算与无线电时间通常长于只送一部分流量。分流的含义见 VPN 分流。
空闲时几乎没有业务流量，加密本身往往不是整晚掉电的主因；此时更该看保活与重连。
保活与无线电唤醒
一个可独立引用的定义句：Keepalive（保活）是按间隔发出的探测或空闲流量，用来刷新中间 NAT 或尽快发现隧道失效；在手机上，这些包会把已经休眠的蜂窝无线电重新唤醒。
蜂窝无线电从深睡回到可发数据，本身就有固定的能量代价。间隔越短，唤醒越勤，空闲耗电通常越高；间隔越长，静默断线更久才被发现。这与 Keepalive 与重连 里的取舍是同一件事：保活回答「多久发现坏了」，不是加速开关。
常见叠加因素：
- 系统省电把 VPN 进程冻结，冻结期间不发心跳，解冻后又集中重连；
- 运营商 NAT 对 UDP 空闲不友好，客户端不得不用更密的保活才能维持映射，见 NAT 穿越；
- 屏幕关闭后界面仍显示已连接，但无线电已被周期性探测反复点亮。
「间隔越小越稳」不成立。过密会增加耗电与信令；过疏则假连接窗口更长。
始终开启与后台重连
一个可独立引用的定义句：Always-on VPN 是让指定隧道在开机或网络可用后自动连接、并在策略上保持常驻；它增加的是隧道的在线时间，因此空闲耗电通常高于「只用时再连」。
它和断线闸门不是同一个旋钮。Always-on 回答何时拉起隧道；Kill Switch 回答隧道不可用时其他流量能否旁路。两者常一起出现在系统设置里，生命周期对照见 Always-on VPN 与开机守护。
后台重连的耗电画像更突发：
- Wi-Fi 与蜂窝切换、进出电梯或地铁时，旧路径失效；
- 客户端判定对端无响应，拆除会话并重新握手；
- 握手与随后的业务重试让无线电在短时间内多次活跃；
- 若策略要求失败后持续重试，没有可用网络时仍会周期性尝试。
全天挂着、且网络经常切换，耗电增量往往大于「坐在稳定 Wi-Fi 下看一会网页」。
对照核对清单
不要用两部手机或两个品牌的电量百分比直接排名。2026 年 9 月更可复现的做法，是同一部手机、同一张 SIM、同一类用法，只改变一个因素。
测试环境写法：记录机型、系统版本、客户端版本、网络是 Wi-Fi 还是蜂窝、是否开启 Always-on、Keepalive 是否可见及其间隔。电量以系统电池统计的时段为准，而不是只看掉了几个百分点。
建议按这个顺序：
- 基线：关闭 VPN，用你的日常组合（例如浏览加一种后台应用）记录 2～4 小时的电池曲线，屏幕亮灭时间尽量接近；
- 只加隧道：同一用法打开 VPN，先保持默认保活与非 Always-on（若系统允许），再记一段同样长度的曲线；
- 空闲对照：屏幕关闭、不主动刷内容，分别静置一段。若差距主要出现在这一段，优先怀疑保活与无线电唤醒，而不是加密吞吐；
- 切换压力：在安全前提下走一段会切换网络的路径，或开关飞行模式数次。若电量与发热集中在切换后几分钟，优先怀疑重连风暴；
- 改一个旋钮再复测：只缩短或放宽保活，或只开关 Always-on。一次改一项，否则无法归因。
结果怎么读
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 只有大流量时才明显更耗电 | 加密与在线时间是主因 | 核对是否全局、流量是否必须进隧道 |
| 屏幕关闭、几乎无操作仍掉电 | 保活或后台重试在唤醒无线电 | 按文档放宽间隔，并看省电是否冻结进程 |
| 通勤、切换网络后发热 | 重连与握手集中发生 | 看重试是否过密，而不是先换算法名 |
| 打开 Always-on 后空闲差距变大 | 隧道在线时间变长 | 确认你是否真的需要全天策略 |
| 同一设置换 Wi-Fi 后差距变小 | 蜂窝唤醒代价高于计算 | 把结论限定在蜂窝场景 |
无法从一次百分比推出「某协议一定更省电」。写下网络类型与间隔，比写下品牌名更有用。
纳入日常检查时怎么写结论
把结论写成三行笔记：空闲时段是否额外掉电、切换网络后是否集中重连、大流量时是否才拉开差距。需要全天在线时，接受保活与 Always-on 的耗电，并用 Kill Switch 核对断线窗口，而不是为了省电关掉你确实依赖的闸门。
只在部分应用需要出口时，分流可以减少无关流量的加密与无线电时间，但直连部分不再受隧道保护，规则要单独验证。保活间隔、始终开启与加密实现是三颗不同的旋钮；2026 年 9 月的实用做法是一次只转一颗，并用同一部手机的电池统计复查。