Kill Switch 是什么？断网保护的两种实现与验证方法
Yalgorup 编辑部 · 更新于 2026年8月1日
核心要点
- 它防的是「隧道断了但你没发现」这几秒钟 —— 而这几秒足够后台应用暴露真实 IP。
- 系统级实现直接在防火墙里只放行隧道接口，进程被强杀也依然有效。
- 应用级实现依赖客户端自身运行，客户端崩溃时保护往往一起失效。
- 验证方法只有一个：强制结束客户端进程，再看网络是否还通。
它解决的是哪几秒钟
VPN 连接不会永远稳定。服务器重启、Wi-Fi 切换、系统休眠唤醒、线路抖动 —— 隧道随时可能断开几秒。
在这几秒里，操作系统会做一件很自然的事：把流量退回原来的默认路由。于是正在同步的网盘、正在下载的客户端、正在轮询的应用，全部用真实 IP 继续跑，而屏幕上可能什么提示都没有。
Kill Switch 的作用就是：宁可断网，也不放行。
两种实现方式
系统级（防火墙规则）
客户端在连接时向系统防火墙写入规则：只允许流量从隧道接口出去，其他接口一律拒绝。Linux 上用 nftables/iptables，Windows 上用 WFP 过滤平台，macOS 用 pf。
优点是它不依赖客户端继续运行。哪怕进程被强制结束、甚至崩溃，规则依然留在系统里，网络仍然是封死的。
应用级（进程监控）
客户端监控隧道状态，一旦发现断开，就关闭用户指定的应用程序或暂停其网络访问。
这种实现有个结构性弱点：保护逻辑本身跑在客户端里。客户端崩溃时，监控随之消失，流量照常放行。
常见的失效场景
| 场景 | 为什么会漏 |
|---|---|
| 客户端进程被强制结束 | 应用级实现失去执行主体 |
| 系统从休眠唤醒 | 网络恢复早于 VPN 重连，中间有窗口 |
| IPv6 流量 | 防火墙规则只写了 IPv4 |
| 开机到连上 VPN 之间 | 若未启用「开机即阻断」，这段时间是裸的 |
| 局域网白名单过宽 | 放行范围写得太大，等于开了口子 |
第二和第四条尤其值得注意 —— 它们发生在你还没开始用电脑的时候。
怎么验证它真的有效
不要相信设置页面上的开关状态，动手测一次：
- 连上 VPN，确认出口 IP 已改变。
- 打开一个持续产生流量的东西，例如在线视频。
- 在任务管理器里直接结束 VPN 客户端进程（不要点「断开」按钮）。
- 观察视频是否立刻中断、浏览器是否无法访问。
如果网络自动恢复了直连，说明这个 Kill Switch 只覆盖了正常断开的路径 —— 在最需要它的崩溃场景里并不生效。
再补一项：重启电脑，在客户端自动连接完成之前尝试打开网页。若能打开，说明开机阶段没有保护。
移动端的情况
Android 提供系统级支持：在「VPN」设置里开启「始终开启的 VPN」和「屏蔽没有 VPN 的连接」，由系统而非应用来保证，可靠性高。
iOS 的 Always-On VPN 主要面向受管理的设备，需要配置描述文件，个人用户通常只能依赖客户端自身的实现。
该不该一直开着
如果使用 VPN 的目的包含隐藏真实 IP，就应该开着 —— 否则那几秒的窗口足以让一次暴露发生，而且你不会知道。
如果只是偶尔换个出口访问某个服务，开着反而会在断线时打断所有网络活动。按用途决定，而不是默认全开。
常见问题
开着 Kill Switch 会影响正常上网吗？+
会。VPN 断开时整台设备（或指定应用）会失去网络连接，这正是它的设计意图。部分客户端提供白名单，允许局域网访问。
应用级和系统级怎么分辨？+
看设置里是「阻止所有流量」还是「关闭指定应用」。前者通常是防火墙级，后者只是在检测到断开后杀掉列表里的程序。
手机上有 Kill Switch 吗？+
有。Android 的系统设置里有「始终开启 VPN」和「阻止没有 VPN 的连接」；iOS 上通过 Always-On VPN 配置描述文件实现，个人用户可用的选项较少。
为什么开了 Kill Switch 还是泄露了？+
常见原因是它只覆盖 IPv4，或者只在正常断开时触发。IPv6 与进程崩溃是两个典型漏网场景。