VPN中的“Kill Switch”是如何工作的？

凌晨一点四十分，林舟把电脑合上又掀开，反复了三次。屏幕上那个小小的锁形图标还亮着，但他知道，自己刚才在公共 Wi-Fi 上打开银行页面时，VPN 曾经短暂掉线过两秒。两秒，足够让一个自动化脚本抓走一次会话令牌。他是在事后查看日志时才发现这件事的，而真正让他后背发凉的，是日志里那行不起眼的提示：Tunnel disconnected, traffic blocked by kill switch。

他第一次意识到，自己每天点开的那个“自动保护”开关，并不是一个装饰性的绿点。它是一道闸门，在隧道崩塌的瞬间，替他把整条网络通路掐断。

很多人对 VPN 的理解停留在“加密”和“换 IP”两个词上。加密让数据在隧道里变成乱码，换 IP 让网站认不出你是谁。但很少有人认真想过一个问题：当隧道本身断掉的时候，那些原本该走隧道的流量，会去哪里？

答案取决于你有没有打开 Kill Switch。如果没有，它们会从物理网卡直接溜出去，带着你的真实 IP、真实的 DNS 请求，赤裸裸地暴露在本地网络里。Kill Switch 存在的全部意义，就是在那一瞬间把“溜出去”这个动作变成“出不去”。

一、隧道塌了之后，流量会从哪里跑出去

要理解 Kill Switch 怎么工作，得先理解 VPN 断开时系统里发生了什么。

大多数 VPN 客户端在建立连接时，会做三件事：创建一块虚拟网卡（比如 tun0 或 utun3），修改系统路由表，把默认路由指向这块虚拟网卡，然后由 VPN 进程把虚拟网卡里的数据包加密后，通过物理网卡发往远端服务器。你的浏览器以为自己只是在正常上网，实际上它的每一个包都被路由表“骗”进了隧道。

问题出在“骗”这个字上。路由表是一条规则，不是一堵墙。当 VPN 进程崩溃、服务器无响应、或者 Wi-Fi 切换导致底层链路重置时，VPN 客户端会尝试重连，而在这段重连窗口里，路由表可能已经被恢复成默认状态，或者虚拟网卡已经消失，但浏览器还在往外发包。这时候操作系统会按照剩下的路由规则，把包从物理网卡送出去。

这就是所谓的“泄漏窗口”。它可能只有几百毫秒，也可能长达几十秒，取决于 VPN 客户端重连策略的激进程度。对于普通浏览，几十毫秒的泄漏可能只是让某个广告联盟多记了一次你的真实 IP；但对于 torrent 用户、记者、或者正在传输敏感文件的人来说，一次泄漏就足够致命。

Kill Switch 要做的，就是在这个窗口期里，让物理网卡“无路可走”。

二、三种常见的实现路径

不同操作系统、不同 VPN 协议，Kill Switch 的实现方式差别很大。粗略分，可以归为三类：防火墙规则、路由表锁死、以及网络接口禁用。它们经常组合使用，而不是单独出现。

1. 防火墙规则：把“允许”改成“只允许隧道”

这是最常见也最可靠的做法，尤其在 Windows 和 Linux 上。

传统防火墙的默认策略通常是“允许出站、阻止入站”，Kill Switch 会把这个策略反过来：默认阻止所有出站流量，然后只放行两类包——发往 VPN 服务器 IP 的加密包，以及从虚拟网卡出来的、已经进入隧道的包。其余一切，包括 DNS 查询、HTTP 请求、甚至系统更新，全部被丢弃。

这种做法的好处是它不依赖 VPN 客户端进程是否存活。规则一旦写进内核防火墙，就算 VPN 客户端整个崩掉，规则依然生效。坏处是配置起来容易出错：如果 VPN 服务器的 IP 是动态的，或者客户端在重连时换了端口，旧规则可能把重连包也一起挡掉，导致 VPN 永远连不上，用户只能手动关掉 Kill Switch 才能恢复网络。

所以成熟的客户端会做两件事：一是在连接建立前先放行目标服务器 IP，连接成功后再收紧规则；二是在退出时提供“恢复默认防火墙”的清理逻辑，避免用户被永久锁在网络之外。

2. 路由表锁死：让默认路由指向一个黑洞

路由表方案更轻量，也更“优雅”，但在某些系统上不够彻底。

思路是这样的：VPN 连接建立后，客户端把默认路由指向虚拟网卡，同时额外添加一条“黑洞路由”，把 0.0.0.0/1 和 128.0.0.0/1 指向一个不存在的接口，或者指向 lo（回环）。这样即使虚拟网卡消失，系统也没有一条可用的默认路由能把包送出去，流量只能被丢弃。

这种方案在 macOS 和部分 Linux 发行版上很常见，因为它不需要管理员权限去改防火墙，普通用户态进程就能操作路由表。但它有一个明显短板：它依赖路由表的优先级和系统行为。某些应用会自己绑定物理网卡（比如某些游戏客户端、某些 P2P 软件），绕过默认路由，这时候黑洞路由就拦不住它们。所以纯路由表方案通常只被当作“轻量 Kill Switch”，真正严肃的实现还是会叠加防火墙规则。

3. 接口禁用：直接把物理网卡按下去

最粗暴也最直接的方式，是在隧道断开的瞬间，把物理网卡（Wi-Fi 或以太网）禁用掉，等隧道恢复后再重新启用。

这种做法在移动端比较常见，因为 iOS 和 Android 对后台进程的限制很严，VPN 客户端很难长期维持复杂的防火墙规则，而“关网卡”这个动作系统本身支持得很好。代价是用户体验很差：每次重连都要经历一次“网络断开—重连—再断开—再重连”的抖动，如果 VPN 服务器不稳定，用户会感觉自己的网一直在跳。

所以现在更多客户端采用折中方案：断开时不禁用网卡，而是把网卡标记为“仅允许 VPN 进程使用”，其他进程的包一律丢弃。这本质上还是防火墙思路，只是实现层级更低。

三、一次真实的断线，Kill Switch 到底做了什么

回到林舟那个凌晨。我们可以把那次断线拆成几个时间片，看看 Kill Switch 在每一刻做了什么。

T+0ms：VPN 客户端检测到隧道心跳超时，判定连接失效。此时虚拟网卡还在，路由表还指向隧道，但隧道另一端已经没有响应。

T+50ms：客户端开始重连流程。它首先做的是“收紧”——把防火墙出站策略从“允许”切到“仅允许 VPN 服务器 IP 和虚拟网卡”。这一步通常在几毫秒内完成，因为规则是预先编译好的，只需要一次系统调用。

T+120ms：浏览器发起了一次 DNS 查询，因为用户恰好点了一个链接。这个查询包试图从物理网卡出去，被防火墙规则匹配到“非隧道流量”，直接丢弃。浏览器收到超时，显示“正在解析主机”，用户感知到的只是“网有点慢”。

T+800ms：客户端第一次重连失败，服务器无响应。它继续重试，同时保持防火墙规则不变。这期间所有出站流量都被挡住，包括系统的时间同步、推送通知、后台更新。

T+2100ms：客户端切换到备用服务器，重连成功。虚拟网卡重新配置，路由表恢复，防火墙规则被替换成“放行隧道流量”。浏览器的那次 DNS 查询早已超时，但用户刷新一下页面，一切恢复正常。

整个过程里，用户感知到的只是“断了两秒”，但 Kill Switch 在这两秒里拦下了至少十几个出站包，其中包括一次 DNS 查询、一次 OCSP 证书校验请求、以及浏览器后台的一次 telemetry 上报。如果没有 Kill Switch，这些包会带着真实 IP 和真实 DNS 服务器信息出去，其中 DNS 查询尤其危险——它等于直接告诉本地网络“这个人正在访问某银行域名”。

四、Kill Switch 不是万能的

有必要说清楚一件事：Kill Switch 防的是“隧道断开后的泄漏”，不是“隧道被攻破后的泄漏”。

如果 VPN 服务器本身被入侵，或者加密协议存在漏洞，Kill Switch 不会起任何作用，因为流量确实还在隧道里，只是隧道另一头的人不可信。它也不防“应用层泄漏”：某些应用会自己走独立的网络栈，绕过系统路由表和防火墙规则，比如某些虚拟化软件、某些带自己网络栈的浏览器扩展。Kill Switch 只能管住操作系统层面的出站流量，管不住应用自己开的“后门”。

另一个常被忽略的点是 IPv6。很多 Kill Switch 实现只处理 IPv4 规则，而现代操作系统默认同时启用 IPv6。如果 VPN 只建了 IPv4 隧道，IPv6 流量可能直接从物理网卡出去，完全绕过 Kill Switch。所以成熟的客户端会在连接期间直接禁用 IPv6，或者把 IPv6 默认路由也指向黑洞。

还有 DNS。Kill Switch 通常会和“DNS 泄漏保护”绑定在一起，但两者其实是独立机制。防火墙规则能挡住发往外部 DNS 服务器的明文查询，但如果系统配置里还留着本地 ISP 的 DNS 地址，而某个应用用了 DoH（DNS over HTTPS）直连，Kill Switch 未必拦得住。所以很多客户端会强制把 DNS 请求重定向到隧道内的解析器，或者在断开时直接把 DNS 服务停掉。

五、为什么它值得被认真对待

林舟后来把 Kill Switch 的设置从“自动”改成了“始终开启”，并且额外勾选了“断线时阻止所有非隧道流量”。他跟我说，以前他觉得这个开关是个心理安慰，直到看见那行日志才明白，它其实是整个 VPN 里最像“保险丝”的部件。

保险丝平时不显眼，只有在电流异常的时候才熔断。Kill Switch 也一样：它不参与加密，不参与换 IP，不参与任何你花钱买 VPN 时看中的那些功能。它只在你最不希望出问题的那一瞬间，替你做一次“宁可断网，也不泄漏”的选择。

而那次选择，往往决定了你是“网断了两秒”，还是“身份暴露了两秒”。