手机与桌面设置里的「Always-on VPN」「VPN on demand」「开机启动」容易和「Kill Switch」混成同一个安全感开关。更精确的读法是：**Always-on / 按需连接回答「隧道何时自动出现」；Kill Switch 回答「隧道不行时，别的路能不能偷偷出去」。**2026 年 9 月排障时，开机后短暂暴露真实 IP、酒店强制门户进不去、飞行模式恢复后假连接，往往落在这三层的缝隙里——而不是协议名本身。建议与 Kill Switch 及 Keepalive 与重连 对照阅读。
三个容易混的概念
一个可独立引用的定义句：Always-on VPN 是操作系统或客户端提供的策略，使指定 VPN 配置在开机后、网络可用时自动连接，并可选地在隧道未就绪时限制其他应用出站；它与「断线时封锁旁路」的 Kill Switch 相关，但不等同。
| 概念 | 主要问题 | 典型失败画像 |
|---|---|---|
| Always-on / 开机守护 | 隧道是否自动拉起、是否默认常驻 | 开机后未连上、用户关掉后被策略拉回 |
| On-demand（按需） | 匹配某域名/规则时才连接或断开 | 规则过宽/过窄，连不该连的网 |
| Kill Switch | 隧道 down 时是否禁旁路 | 断线窗口泄漏，或误杀导致完全断网 |
| Keepalive / 重连 | 空闲与路径变化后如何保活、重握手 | 假连接、长时间假在线 |
这与 VPN 是什么 的模型一致：隧道是通道；Always-on 是生命周期策略；Kill Switch 是出站闸门。
开机竞态：窗口从哪来
设备启动大致会经历：内核与网络接口就绪 → 部分系统服务与 App 可发起连接 → VPN 配置被加载、权限校验、握手完成 → 路由/防火墙规则落到「只走隧道」的稳态。
任一环慢半拍，就可能出现：
| 阶段 | 可能发生的事 | 策略层应对（概念） |
|---|---|---|
| 网络已通、VPN 未起 | 应用直连暴露真实源地址 | Always-on + 「未连接则阻挡」类规则 |
| VPN 握手中 | 半开状态、DNS 仍走系统默认 | 等就绪或显式阻塞 |
| 握手失败 | 永久挡死或回落直连 | 取决于失败时默认是 fail-closed 还是 fail-open |
| 重连间隙 | 与 Kill Switch 窗口重叠 | 见杀开关文 |
「开了 Always-on」若在失败时允许旁路，体感像开了自动重连，却不等于 fail-closed。读系统说明时，核对本机是「锁定直到 VPN 连接」还是「尽量自动连、连不上照样上网」。
测试环境写法示例：2026 年 9 月，同一手机开启 Always-on 后冷启动，用第二台设备或路由器侧日志观察开机后 0～60 秒内是否出现非隧道出站；同时记录系统 VPN 图标何时变为已连接。写下 OS 版本；不要只凭「设置里勾了」断言无窗口。
与 Kill Switch、保活怎么分工
| 场景 | 更先查 Always-on | 更先查 Kill Switch | 更先查 Keepalive |
|---|---|---|---|
| 每次开机都要手动点连接 | 是 | 次要 | 否 |
| 隧道掉了几秒真实 IP 出现 | 可能相关 | 是 | 看是否假连接 |
| 休眠后「显示已连接但打不开网页」 | 次要 | 次要 | 是 |
| 用户关掉 VPN 又被拉起 | 是（策略意图） | 否 | 否 |
实务上三者常叠用：Always-on 负责「尽量在线」，Kill Switch 负责「不行就别漏」，Keepalive 负责「别因为 NAT/空闲误判已死」。改其中一个旋钮后，另外两个的行为可能被连带影响——例如挡光了所有非隧道流量后，保活探测的路径也必须仍被允许。
强制门户（Captive Portal）的概念张力
酒店、机场、校园网常见流程：关联 Wi‑Fi 后，必须先访问本地认证页（或探测 URL）完成登录，再放行一般流量。这与「未进隧道不许出站」存在张力：
| 需求 | 对 Always-on / 闸门的压力 | | --- | --- | --- | | 完成门户登录 | 需要短暂允许特定明文/本地探测 | | 登录后恢复锁定 | 需要及时收回例外，避免长期旁路 | | 防 DNS 泄漏 | 例外过宽时解析可能绕开隧道 | | 用户体验 | 例外过窄则「连不上网」，误以为 VPN 坏了 |
概念层结论：Always-on 与强制门户不是谁消灭谁，而是例外规则的生命周期问题——何时开例外、开给谁、何时收回。具体厂商如何实现连通性检测，以系统文档为准；本文不展开操作步骤，只提醒把「门户进不去」优先当成策略冲突，而不是急着关杀开关后忘记再打开。
与 分流隧道 的关系：分流是长期按目的地/应用选路；门户例外往往是短时、面向本地认证网段或探测主机的特殊放行。两者都扩大「以为走了隧道、其实没有」的面积，改完要重测。
常见误解
误解 1：Always-on = 绝对不会泄漏。
仍取决于失败默认、例外列表、IPv6/分流转发，以及开机竞态是否被真正封闭。
误解 2：Kill Switch 开了就不必 Always-on。
杀开关不保证开机后自动拉起隧道；可能只是「没隧道时断网」，用户体验是裸奔或裸断，取决于实现。
误解 3：按需连接更聪明所以更安全。
On-demand 减少常驻连接，但规则匹配失误时可能该连未连，或在不该进隧道的流量上触发意外路径。
误解 4：协议越新，Always-on 越稳。
WireGuard / IKEv2 等影响握手速度与移动切换；开机守护与闸门是 OS/客户端策略层，见协议对比文时不要串层。
建议怎么纳入核对清单
把 Always-on 写成可执行检查，而不是口号：
- 策略语义：本机 Always-on 在「连不上」时是阻断出站还是允许旁路；与 Kill Switch 文案是否同一层；
- 开机窗口：冷启动后抽样看真实出口与 DNS 是否曾偏离隧道（写日期与 OS 版本）；
- 重连与保活：飞行模式开关、Wi‑Fi/蜂窝切换后是否自动恢复；假连接时对照 keepalive 文；
- 门户与例外：若需使用强制门户，记录例外是否在登录后收回；例外存在期间做一次泄漏抽样；
- 人为关闭：你主动断开后，策略是否强制拉回；这是否符合你在公共网络上的预期。
本站定位为中立科普：不提供规避执法的具体指导，也不对单一系统开关做「必开」命令。把自动拉起、断线闸门与保活分成三层验证，比只勾选一个 Always-on 复选框更接近可复查的基线。