VPN 断线还能上网？Kill Switch 的触发条件与例外

VPN 断线后仍能上网，不一定代表 Kill Switch（断网保护）失效。先确认是意外掉线还是主动点击“断开”，再核对是否启用了持续阻断、测试应用是否被分流排除。判断的关键是：在客户端承诺阻止直连的状态下，受保护应用有没有发出隧道外的新请求。

本文以 Windows 桌面客户端为例，解释检查方法，不把某一产品的行为套用到所有系统，也不将系统代理、TUN 开关视为断网保护的保证。

手动断开和意外掉线，可能执行不同策略

有些客户端把普通保护与持续阻断分开。以 Proton VPN 的官方说明为例：标准模式针对意外掉线；高级模式还会在手动断开后阻止联网，并在系统重启后持续生效。因此，“点断开后网页能打开”不能单独证明标准保护失效。

Mullvad 桌面指南也区分了内置 Kill Switch 与 Lockdown mode，后者额外覆盖主动断开或退出后的阻断。两家的命名只是具体例子，自己的客户端应查对应平台文档。

核对设置时，把下面四个问题分开：

自动重连解决的是恢复连接；断网保护解决的是未恢复期间允许什么流量。两者不能相互代替。“开机启动”也不足以单独证明启动过程没有直连窗口。

先列出必须经过隧道的应用，再列出允许直连的应用。不要拿一个明确被排除的程序，去证明受保护程序的策略失败。

例如，Mullvad 的上述指南明确写到，分流排除的应用在 Lockdown mode 开启时仍可联网。Proton 的上述文档则说明，其 Windows 客户端可将分流与断网保护结合，讨论的保护对象是受保护应用。这些说明不能推导出其他平台具有相同行为。

如果使用的是机场代理客户端，先核实是否真的提供相应功能，以及“严格路由”等设置的具体边界。接管流量与断线后的阻断是两个检查项，可先读本站规则、全局与 TUN 的区别，不要只凭“全局”二字判断覆盖范围。

记录 Windows、客户端版本、节点、保护模式与分流列表。在 VPN 正常连接时，让待检查的应用发起一次新的、非敏感的外部请求，记录时间与实际出口。

使用出口检测页时确认它已重新请求；旧页面里的地址、缓存视频和已经下载的内容都不能代表当前连接。不要在检查时保留重要上传、会议或远程维护任务，以免一次断开打断工作。

保持应用和配置不变，通过客户端正常点击断开，再发起新请求。

若请求仍成功，也不要立即认定走了本地直连：设备上可能还有另一套 VPN、应用代理或其他出口，需要结合连接记录确认。

按客户端文档，用正常换节点操作观察重新连接期间的表现，并将新请求时间与客户端连接日志对齐。这一项检查的是换节点过程，不能代替所有意外掉线场景。

Mullvad 的项目安全文档将连接中、错误和主动断开等状态分别处理，并说明其阻断依赖防火墙策略。由此可见，只比较“连接前”和“恢复后”的两个截图，会漏掉中间状态。

切换太快、请求没有覆盖到间隔时，应记为“未观察到”，不能写“零泄漏”。不要为了制造故障强制结束系统服务或删除路由；需要验证特定掉线问题时，优先按官方支持给出的复现方法记录。

浏览器的一次结果不能代表其他应用、IPv6、DNS 或开机阶段都通过。只有实际覆盖并能核对路径的项目，才写入结论。双栈连接的检查边界可参照本站 IPv6 代理验证指南。

拔掉网线后页面打不开，不足以证明保护生效。 此时基础连接本身已经中断。关键是基础网络恢复而隧道仍未建立的阶段，受保护请求是否被阻止。

路由器上还有数据包，不等于业务流量已泄漏。 需要分清目的地和用途。Mullvad 的安全文档列有 DHCP、隧道建立及部分服务 API 等必要通信例外；不能期待保护状态下物理网卡完全没有数据，也不能把未识别的外部流量一概解释成必要通信。

关闭窗口，不等于停止所有后台组件。 仍以该项目文档为例，其桌面连接由系统服务处理。实际状态应看客户端说明和日志，不能只依据桌面上是否还显示窗口。

所有请求都失败，也不自动等于保护正常。 DNS 故障、残留代理、目标站异常同样可能导致失败。只有设置、日志和对照结果相互吻合，才有依据将失败归因于保护策略。

先查看客户端是否明确提示正在阻断。若仍希望只经 VPN 联网，优先恢复隧道；若希望恢复直连，再按该软件官方流程修改保护设置。不要一开始就清空防火墙或重置系统网络。

计划启用长期阻断前，先阅读离线登录与恢复说明。Proton 的上述文档特别提醒，某些需要联网重新登录 Windows 的场景可能受高级保护影响。睡眠唤醒后的故障则可继续按本站唤醒与重连排查检查。

资料核对日期：2026-11-03。本文依据官方文档提供检查方法，未进行具体服务的断线泄漏实测。