Kill Switch（断线保护）要解决的是：VPN 或代理隧道突然不可用时，本机流量是否会短暂甚至持续地改走普通网络，从而暴露真实 IP。2026 年多数客户端都提供同名开关，但可靠性取决于实现方式，而不是按钮上的字。验证的核心是制造断线，再观察流量是否被挡住。
Kill Switch 到底在防什么
VPN 是什么 里说过：加密通道一旦建立，外界通常只看到你连着一台服务器。通道断开后，如果系统立刻恢复默认路由，后续请求就会带着真实出口出去。
这类回落常见于：
- 节点短暂不可达、握手失败或被中间网络重置；
- 笔记本休眠唤醒、Wi-Fi 与蜂窝网切换；
- 客户端崩溃、权限被系统收回、虚拟网卡被删除；
- 用户手动断开后，仍希望「未连上就不该上网」。
一个可独立引用的定义句：Kill Switch 是隧道失效时的出站闸门，不是让连接永远不断开的加速功能。
它与「能不能连上某网站」无关，只回答：断了之后，流量还准不准离开本机。
它和 TUN、DNS 各管哪一层
TUN 全局代理 负责把 IP 包导向虚拟网卡；DNS 泄漏检查 负责让名字解析与隧道路径一致。现代 VPN 技术架构 则把 Kill Switch 单独标成一层：默认禁止物理接口出站，只留连接节点和控制面的例外。
| 机制 | 主要问题 | 失效时的典型后果 |
|---|---|---|
| TUN / 默认路由 | 流量进不进隧道 | 应用直连或半接管 |
| 隧道 DNS | 解析问谁 | 域名查询仍走运营商 |
| Kill Switch | 隧道没了还能不能出网 | 真实 IP 短暂或持续暴露 |
三者都开齐，才接近用户口中的「全局且断线不漏」。只开 TUN、不开断线保护，等于默认允许回落。
常见实现：路由型 vs 防火墙型
客户端宣传的 Kill Switch，底层多半落在两类做法上。
路由型
断线后删除指向虚拟网卡的默认路由，或把默认路由指到黑洞地址。优点是改动面小；缺点是规则切换有时间窗，休眠、多网卡和 IPv6 下更容易出现「一瞬间已经发出去了」。
防火墙 / 过滤框架型
用系统防火墙或网络过滤能力默认拒绝物理接口出站，仅允许：
- 连接 VPN 控制服务和数据节点所需的地址与端口；
- 隧道接口本身的流量；
- 本地回环等明确例外。
这类实现更接近「默认拒绝」。断线时规则仍在，只是隧道接口不再收包，因此普通网页和应用通常直接失败，而不是悄悄直连。代价是权限更高，配置错误时整机可能完全上不了网，排查成本也更高。
| 维度 | 路由型 | 防火墙型 |
|---|---|---|
| 典型行为 | 改默认路由 / 指黑洞 | 默认拒绝物理出站 |
| 断线窗口 | 更易出现短暂泄漏 | 通常更严 |
| 权限要求 | 中等 | 通常更高 |
| 误配后果 | 流量回落 | 整机断网 |
| 跨平台一致性 | 看起来像，细节差大 | 同样依赖各系统 API |
同一品牌在 Windows、macOS、Android、iOS 上的同名开关，往往不是同一套代码路径。移动端系统 VPN API 会代管部分规则，桌面端则更多由客户端自己装驱动和防火墙策略。
它防不住什么
把 Kill Switch 当成「隐私总开关」会高估它：
- 未纳入保护范围的流量：分流规则、应用排除列表、虚拟机桥接、部分系统更新通道；
- IPv6 半开：只挡了 IPv4，双栈应用仍可能走 v6 直连；
- DNS 与 WebRTC：名字解析或浏览器实时通信候选地址，不一定走你以为的那条 IP 路径；
- 已经建立的连接：部分实现只影响新连接，已存在的 TCP/QUIC 会话行为因系统而异；
- 你主动允许的例外：为了让客户端连上节点，必须保留直连；例外写得过宽，等于开了一扇门。
因此，Kill Switch 降低的是「隧道掉了还继续裸奔」的概率，并不消灭所有元数据暴露面。
怎么验证它是否真的生效
不要只看设置页勾选状态。用可复现步骤制造断线，再观察结果。
测试环境写法示例：2026 年 8 月，家庭宽带，Windows 11 + 某客户端。记下日期、系统和客户端版本即可。
建议流程：
- 连通基线：开启 VPN 与 Kill Switch，确认能访问一个会显示出口 IP 的检测页，并记下隧道出口；
- 制造断线：在客户端外断开到节点的路径（例如临时屏蔽节点 IP、拔掉会迫使重连的网络、或让客户端进入明确的「已断开但开关仍开」状态）。不要只点「暂停」却同时关掉保护规则的那种模式；
- 立刻复测：刷新检测页或换一个未缓存的检测地址。期望结果是打不开 / 超时 / 明确失败，而不是显示家庭宽带真实 IP；
- 覆盖双栈与 DNS：若系统启用 IPv6，确认 v6 检测同样失败；再看 DNS 检测是否仍冒出运营商解析器；
- 唤醒与切换：睡眠唤醒、Wi-Fi 切换一次，重复第 3 步。许多泄漏发生在重连窗口，而不是稳态。
结果怎么读
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 断线后网页全失败，无真实 IP | 出站闸门大致生效 | 再测 IPv6 与唤醒场景 |
| 断线后马上看到真实 IP | 回落成功，保护未生效或未覆盖该应用 | 检查实现类型、权限与排除列表 |
| 浏览器失败，命令行仍通 | 只拦了部分应用或代理设置 | 查 TUN/防火墙是否系统级 |
| 仅 IPv6 仍通 | v6 规则缺失 | 为 ::/0 与 v6 出站补齐策略 |
| 重连数秒内出现真实 IP | 规则更新非原子 | 优先考虑防火墙型或更换客户端实现 |
无法确认检测页归属时，写「据检测页显示」，不要断言具体运营商名称。
配置时的务实取舍
更值得开启的情况：
- 你关心真实 IP 是否在断线窗口暴露（公共 Wi-Fi、对出口一致性要求高的账号场景）；
- 客户端明确提供系统级 / 防火墙级保护，且你愿意接受「断了就上不了网」；
- 设备以 TUN 全局为主，而不是只给浏览器设系统代理。
可以放宽或改用「仅提示」的情况：
- 你需要隧道挂了仍能立刻用本地网络处理紧急事务；
- 企业软件、网银或校内网对虚拟网卡 / 防火墙策略敏感；
- 当前实现一开保护就误伤局域网打印机、远程桌面或下载器，而你暂时只能靠排除列表凑合。
若排除列表越写越长，保护面会同步变薄。与其堆例外，不如先分清：哪些应用必须进隧道，哪些根本不该依赖这台设备的「全局」假设。
建议怎么纳入日常检查
把 Kill Switch 验证和 DNS 泄漏检查放在同一清单里：换客户端、改分流、系统大版本更新之后各测一次。先确认断线时出站真的被挡住，再比较节点快慢；否则你优化的是「连得上」的半段，另一半风险仍在真实出口上。
对原理层的完整链路，可继续读现代 VPN 技术架构；若还在建立基础概念，从VPN 是什么 开始即可。