适合连接后手机发热、锁屏断流，或电池榜单里 v2rayNG 排名靠前的用户。先用相同条件记录待机耗电，再区分后台限制、其他应用流量和节点重试；最后只调整确有影响的电池权限、代理范围与连接方式，不靠反复杀后台解决问题。
一、先读懂电池统计，别把排名当成耗电结论
v2rayNG 使用 Android 的 VpnService 接收应用流量，再交给 Xray 内核处理。系统电池统计可能将隧道处理、网络活动的一部分开销记在它名下，具体归因随系统而异。因此，榜单靠前不等于客户端在空转，也不代表榜单中的百分比就是整块电池减少的百分点。
例如，某系统显示“占耗电量 20%”，通常指统计周期内已消耗电量中的占比；它与电量从 80% 下降到 60% 不是同一个概念。先看统计起止时间、前后台运行时长和手机实际掉电，再决定是否需要调整。刚更新系统、恢复大量照片或下载离线视频时，也不适合拿一次结果下结论。
-
打开电池统计
以 Android 14 常见界面为例，进入系统「设置」→「电池」→「电池用量」，选择 v2rayNG。部分厂商将入口命名为「耗电排行」，先确认显示的是最近 24 小时还是自上次充满以来。
-
核对后台活动
记录前台与后台运行时间、实际掉电和测试时的网络。后台时间很长，只能说明服务持续存在；要结合流量与日志判断是否一直在传输或重试。
-
查看流量来源
长按 v2rayNG 图标→「应用信息」→「移动数据和 WLAN」，查看可用的流量统计。名称可能是「流量使用情况」；再对照视频、云备份和消息应用，找出是否有后台下载。
-
保存测试条件
记录 Android 版本、v2rayNG 版本、节点、Wi-Fi 或移动数据，以及当时的电池权限。下一轮只改一个设置，避免同时换节点、换网络、改路由后无法判断原因。
二、用固定时段对照，区分待机与传输耗电
下面的数字是建议测试时长，不是某款手机的实测成绩，也不是耗电达标线。电池老化、信号强度和系统计量精度差异很大，不能用统一的“每小时必须少于多少”判断所有设备。短时间电量不变，也不能证明没有额外开销。
| 测试组 | 保持的条件 | 重点记录 |
|---|---|---|
| 停止代理待机 | 同一 Wi-Fi、锁屏 60 分钟，暂停大文件同步 | 起止电量、设备是否发热，作为系统待机基线 |
| 连接代理待机 | 同一位置与时长，使用固定节点，保持应用使用习惯一致 | 掉电差异、后台流量、是否反复断开 |
| 连接代理传输 | 固定亮度，播放相同清晰度内容 15 分钟 | 流量、温度、卡顿与重连时间点 |
停止代理的基线只适合观察系统自身待机，不保证所有应用仍执行相同任务；某些服务无法连接后，行为会改变。更有价值的后续对照，是保持代理开启，仅替换一个稳定节点，或仅缩小代理应用范围。测试期间不要充电，尽量避开刚充满或即将关机的区间，并保持信号和环境温度接近。
结论：先定位异常场景，再改设置
若只有传输时发热，先查流量与无线信号；若锁屏待机也明显增加掉电，先查后台流量和连接重试。不要仅凭电池榜单位置就关闭后台权限。
三、后台保活与电池优化，按连接需求取舍
VPN 授权、后台运行权限和电池优化是三件事。首次连接时同意系统 VPN 请求，只是允许建立隧道；它不会自动取消厂商的后台限制。前台服务通知表示服务在运行，也不等于 CPU 始终满载。反过来，通知存在也不能证明远端服务器仍然可达。
- 需要持续接收消息：长按图标→「应用信息」→「应用电池用量」，在系统提供此选项时允许后台使用；若锁屏确实会中断，再将电池策略从「优化」调整为「不受限制」。部分系统将该选项称为「无限制」。
- 只在前台临时使用：先保留系统默认电池策略，用完在 v2rayNG 主界面停止连接。不必为了偶尔浏览就同时打开自启动、后台锁定和所有保活选项。
- 厂商额外管理：在系统设置中搜索「自启动」或「后台活动」。只有出现重启后无法恢复、锁屏被结束等明确现象时，再逐项放开，并复测相同锁屏时段。
- 启用系统始终开启 VPN：在系统「设置」→「网络和互联网」→「VPN」→ v2rayNG 的设置入口检查。「始终开启 VPN」与「阻止未使用 VPN 的连接」是系统策略，不是省电开关；后一项会在隧道不可用时限制联网。
允许后台运行的目标是减少服务被结束后再恢复带来的中断，并不是保证一定省电。更宽松的权限也允许服务和相关流量持续运行。若修改后连接变稳定但耗电仍高，应继续检查实际通信，而不是无限叠加保活权限。调整系统 VPN 策略前，也要确认自己能接受隧道停止后的联网行为。
四、降低无效连接：先处理超时，再考虑参数
不稳定的节点、失败的域名解析以及频繁切换网络，都可能让上层应用不断重新发起连接。持续唤醒无线网络的往往不只是代理内核，还包括等待消息、同步或下载的应用。先在 v2rayNG 主界面的菜单中打开「日志」，对照断流时间查看错误；不同版本的入口位置可能有所变化。
下面列出的是日志中可能出现的原文片段。单独一行通常不能确定根因，要结合前后的目标地址、错误频率和网络状态判断。分享日志前应隐藏订阅地址、身份参数、服务器地址以及访问目标等敏感信息。
报错：i/o timeout
原因与解法：某次网络读写未在限定时间完成，可能涉及链路、DNS 或远端响应；先在同一网络换一个已知可用节点，再检查超时发生在解析、建连还是传输阶段。
报错：connection refused
原因与解法：目标连接被主动拒绝，常见于端口没有服务监听或接入配置有误；核对节点服务器端口与服务状态，不要靠连续测速反复重试。
报错：network is unreachable
原因与解法：当前系统没有到目标的可用网络路径，可能发生在断网、切换网络或地址族不可达时；先确认 Wi-Fi 或移动数据已恢复，再重连并观察是否仍出现。
- 减少批量探测：排障时只测试少量候选节点，不要反复对整个订阅列表测速。测速会主动建立连接，本身就会产生流量与处理开销。
- 先固定接入网络：在信号较好的 Wi-Fi 下完成一轮测试，再单独测移动数据。弱信号下无线模块的耗电变化，可能大于代理参数变化。
- 检查解析路径：若日志明确指向 DNS 失败，检查 v2rayNG「设置」中的 DNS 相关项，以及系统「私人 DNS」配置。只改其中一项并保留原值，避免两处同时修改后难以回退。
- 不套用通用保活数值：不要为了省电随意添加 TCP 保活、Mux 或传输层参数。不同节点配置、传输方式与服务端支持不同，缩短保活间隔反而可能增加周期通信。
五、分应用代理与路由，减少不必要的处理
如果只有少数应用需要代理，可以先缩小进入隧道的应用范围。在 v2rayNG「设置」→「分应用代理」中启用功能，再按页面提示选择应用；部分版本把相关开关放在设置页的同名分组中。尤其要读清「绕过」的含义：绕过模式下，勾选的应用通常不进入代理；仅代理模式下，勾选的应用才进入代理。
| 设置方式 | 适用情况 | 需要验证 |
|---|---|---|
| 仅代理选中应用 | 只有浏览器等少数应用需要通过节点连接 | 消息应用是否也需要代理，选中项是否完整 |
| 绕过选中应用 | 希望大多数应用进入隧道，只排除明确无需代理的应用 | 绕过应用将使用自身可用的网络路径 |
| 隧道内路由分流 | 同一应用内需要按域名或目标地址决定出站 | 规则顺序、命中结果以及目标是否符合预期 |
分应用代理决定哪些应用的流量交给 VPN 处理，路由分流则决定进入内核的连接如何出站，两者不能混为一谈。命中直连规则的流量仍可能经过客户端处理；把路由改成直连，不等于应用完全绕过 VPN。减少处理范围可能有帮助，但实际效果仍取决于后台通信量。
若问题是云备份每晚上传、视频应用预加载，直接在对应应用中暂停后台同步或限制下载条件，比堆叠路由规则更容易验证。每次修改后停止并重新启动连接，再分别测试被代理和被绕过的应用。不要为了省电绕过原本需要保护或需要代理才能正常工作的流量。
六、按症状收尾：保留能验证的设置
- 锁屏后断开、亮屏恢复：优先复查应用电池策略和厂商后台限制；记录断开时间，确认不是节点本身掉线。先验证「不受限制」这一项，再决定是否需要额外自启动设置。
- 待机不热，下载时发热：先比较流量规模、信号和下载速度。加密、转发与无线传输都会消耗能量，持续大流量时的温升不能直接归类为后台保活故障。
- 无操作也持续有流量：检查系统更新、云同步、消息应用和日志中的重复连接。缩小分应用代理范围时逐项测试，不要一次排除全部应用。
- 更新后才出现异常：记下更新前后客户端版本、Android 版本和配置变化，备份必要设置后按相同条件复测。不要同时更换节点协议、DNS 与电池策略。
结论：稳定连接与明确范围优先
保留经过两轮对照确有改善的修改，撤回无明显收益的额外开关。若固定节点、固定网络下仍持续发热且没有相应流量，整理版本、测试时长和脱敏日志，再继续定位客户端或系统层问题。
日常可以形成一套简单策略：需要长期在线时，允许必要的后台运行并使用稳定节点；临时使用时，结束后主动停止连接；遇到异常时，先查看电池与流量记录，再逐项改设置。这样既能减少反复试错，也能避免为省下无法确认的电量，换来消息延迟或连接不稳定。