关屏就断的 VPN：是哪一层生命周期？

屏幕一暗，传输立刻停止，几秒后角标随之消失。三种不同的原因会造成同一幅画面：客户端进程被限制、路径空闲而丢失映射，或应用丢失了隧道从未察觉的会话。每种原因都有自己的证据，每种修复也属于不同的层。下面的顺序用一次受控测试把它们分开，而不是把所有设置逐个试一遍。

三种看起来一样的故障

受限制的后台进程停止发送 keepalive，对端最终宣布隧道已死。路径上的空闲映射可能在设备睡眠时过期，于是回程流量永远到不了一个明明还活着的客户端。应用可能在隧道仍然在线时丢掉自己的连接，表现为背后挂着健康 VPN 角标的错误弹窗。在用户看来，这三种都像是关屏时 VPN 掉了。

区分它们很重要，因为实际对策彼此矛盾。把客户端排除在电量限制之外能修好第一种，却对已过期的映射毫无作用。延长 keepalive 能修好第二种，却在第三种上白白耗电，而那种情况本来就没有任何网络层面的问题。

在受控条件下比较活跃与空闲

让所有条件保持一致：同一设备、同一网络、同一端点、同一应用。把屏幕锁定一段固定的短时间，记录三项观察：客户端是否报告断开、解锁后新请求是否可用、原有传输是否恢复。然后让 keepalive 或周期请求保持运行，重复一遍并比较两次运行。两次运行之间只改一个变量，胜过一周的道听途说。

时间点要写进记录。九十秒后掉线像是映射或 keepalive 间隔，而锁定瞬间掉线则指向进程被挂起。把触发条件和间隔都记下来，因为下一次尝试需要可比较的基准。

读平台的后台策略

在 Android 上，VPN 服务的生命周期属于平台的一部分，always-on 与 block-without-VPN 是两个独立开关，效果也各自不同。不是 always-on 的客户端，会在系统回收资源时被停止，应用内任何设置都改变不了这一点。iOS 对隧道提供者施加自己的后台限制，官方文档描述的行为与一个一直运行的桌面守护进程并不相同。要读相关组件的平台文档，而不是通用的省电优化指南。

受管设备又多一层。策略可以覆盖个人设置，所以看似生效的改动会在下次策略刷新时回退。如果需求确实存在，就使用组织支持的例外流程，并写明例外为何存在。

唤醒之后设备会做什么

自动重连不等于在空档期间阻断流量。两件事都要查：隧道是否恢复，以及空档期间尝试发送的应用是否在无保护状态下出了网。两秒内重连、却在第一秒漏出 DNS 查询的客户端，对工作设备而言就是错误的故障策略。用无害请求和你自己控制的目的一起测试。

应用恢复是第三个问题。隧道恢复并不能修复已经超时的 SSH 会话，而用户常把这种会话丢失报成 VPN 故障。把触发条件、客户端版本和精确时间写在一起，因为正是这个组合把可预期的关屏生命周期与独立于设备出故障的服务器区分开。