安卓 Always-On 与无 VPN 拦截：选对组合

Always-On 与无 VPN 的拦截是两个不同设置，开启前者并不会开启后者。合适的组合取决于三件事：设备归谁所有、隧道覆盖哪些应用，以及解锁之前会发生什么。

两个承诺不同的开关

Always-On 承诺持续：服务掉线后会被重新拉起。拦截承诺封闭：隧道不可用时，被覆盖的流量没有对外通路；服务器宕机、无人能回答的密码提示，或崩溃的客户端，都会让开启拦截的设备刻意保持离线。

第三个因素是客户端按应用划分的范围，它属于客户端或管理策略，而不属于这两个系统开关。没有决定范围就拦截，得到的策略会比需求更宽或更窄。

决定一：受管设备还是用户设置

受管设备上，策略掌控 Always-On 与锁定，本地开关可能缺失、变灰或在下次策略刷新时被重置。这是策略在起作用，不是需要绕开的缺陷。要改需求就改策略，而不是改终端。

个人设备上由用户决定，诚实的问法是：隧道不可用时能否接受离线。拦截是可用性的交换，应当这样描述。开关缺失也不是 root 或拆掉设备管理的理由。

范围按配置文件划分，而不是按设备：安卓每个用户配置文件只允许一个活动 VPN。

工作配置文件里的拦截说明不了个人一侧，测试一个环境也不能验证另一个。

决定二：全部拦截还是排除部分应用

拦截模式下的按应用排除常被理解反了。按安卓文档，被排除的应用在拦截模式下可能失去连接，而不是悄悄走普通网络。所以排除不是上网许可。

有意识地选择：拦截全部覆盖流量，接受被排除应用一起变暗；或者关掉拦截，接受存在备用路径。如果某个应用必须始终在线，拦截对这个设备就是错误的工具。

决定三：解锁之前与门户页面

多数客户端在用户解锁设备之前不会拉起隧道，所以开机后的最初几秒是空隙，不是故障；请对你部署的客户端确认这一点。

强制门户是另一端：酒店或机场网络需要未认证的浏览器会话，硬拦截会让登录变得不可能。可支持的答案是经过批准的恢复流程，写清触发条件、最长时长、谁可以批准，以及事后强制会自动恢复的验证。

安卓 VPN 客户端文档覆盖 Always-On、拦截、按应用排除以及每个配置文件一个 VPN 的规则。在设计之前先读它，不要只凭旧版本的记忆。

先测离线状态，再写验收条款

用无害流量和客户端支持的故障测试，检查普通连接、隧道丢失、恢复以及解锁前重启，并记录被覆盖的应用是连通、按预期被拦截，还是意外走了别的路径；每一种情况都要单独记下来。

要验证资源与解析器，而不是状态图标。VPN 接口存在，可用的路径仍可能不通。带热点共享的设备也要单独测：手机上的策略不会为热点客户端建立转发。

验收条款要具体且可测：目标配置文件中的目标应用能到达获批隧道，在不能到达时保持要求的拦截状态。签字之前确认：

• 在平台支持的地方，Always-On 与拦截都已配置，且每个设置归谁管理是清楚的。
• 应用范围是有意决定的，并已确认拦截模式下被排除应用的实际表现。
• 解锁前的空隙与强制门户流程是决定过的，而不是现场发现的。
• 故障测试是在你真正部署的设备类别上做的。