指南

Kill Switch与泄漏：DNS、WebRTC、IPv6

Kill Switch（断网保护）会在 VPN 隧道断开的一瞬间掐断所有联网流量，不让应用悄悄退回你的普通连接。没有它，哪怕两秒钟的掉线也会暴露你的真实 IP。而即使隧道正常，DNS 请求、浏览器里的 WebRTC 和 IPv6 流量也可能从旁边漏出去。每种泄漏都有简单的检测法和修法。

🛡️

隧道一断，系统默认放行

VPN 连接断掉后，操作系统会不声不响地把流量转回普通网卡。应用照常工作，没有任何警告。Kill Switch 把“断开即放行”改成“断开即封闭”：没有隧道，就没有流量。

🌍

隧道好好的也会漏

DNS 查询可能绕过隧道直奔运营商的解析服务器，WebRTC 可能把你的地址拱手交给网站，IPv6 可能绕开只走 IPv4 的隧道——而 VPN 图标一直显示着“已连接”。

🔑

每种泄漏都能测出来

你不必信任设置界面。泄漏测试能显示网站实际看到的地址和解析服务器，故意掐断隧道则能验证 Kill Switch 是不是真的顶得住。

隧道断开的那一刻发生了什么

连接的失效方式是“放行”。VPN 通过添加路由，把流量引进一块虚拟网卡。当隧道进程崩溃或超时，这些路由随之消失，而经 Wi-Fi 或以太网的默认路由还在——于是系统继续投递数据包，只不过现在直接走你的运营商。应用几秒内就重连各自的套接字，用你的真实 IP 发流量，任何地方都不会弹出一条报错。

掉线是家常便饭。从 Wi-Fi 切到移动数据、笔记本从睡眠中醒来、酒店网络抽风、VPN 服务器重启，都会让隧道断上片刻。这片刻的代价有多大，取决于隧道断着的时候，设备上是否还有东西被允许出门。

Kill Switch到底做了什么

Kill Switch 是一组防火墙规则，不是魔法。严格版只放行两种出站流量：进入隧道网卡的数据包，以及 VPN 客户端自己发往服务器的加密包。隧道一断，应用的流量就无处可去，直到隧道回来。

它改变的是失效的方式，而不是杜绝失效。有 Kill Switch，掉线变成一次你能察觉的“连接暂停”；没有它，掉线变成一段你毫无察觉的、顶着真实地址的流量。网络不可能完美，隧道照样会断——“断开即封闭”让那些瞬间变得无害。

系统级Kill Switch与应用内开关

差别在于应用自己挂掉时会怎样。应用内的 Kill Switch 是 VPN 客户端里的一段代码，盯着隧道、断了就拦流量。它只在客户端运行时有效：客户端崩溃了，或被省电机制杀掉了，它的保护也随之消失——恰恰就在隧道消失的那一刻。

系统级 Kill Switch 把规则装进操作系统自己的防火墙，不管哪些应用在跑，每个出站包都要过它的眼。Android 内置了这一套：开启“始终开启的 VPN”加“阻止未使用 VPN 的连接”，操作系统本身就会拒绝隧道之外的流量，甚至在重启后应用还没启动时就已生效。分辨两者的粗暴办法：一边浏览网页一边强制杀掉 VPN 应用——如果页面还能加载，说明开关只活在应用里。

DNS泄漏：绕开隧道的查询

DNS 泄漏指的是：你的域名查询发给了本地网络分配的解析服务器——通常是运营商的——尽管流量本身走的是隧道。网站看到的是 VPN 地址，但解析服务器收到了你打开的每一个网站的名字，这等于一份浏览日志。Windows 是经典惯犯：多块网卡同时活跃时，它可能并行向所有网卡发起查询，谁先回答用谁。

修法分两步，好的客户端两步都做：把系统指向隧道内的解析服务器，并封锁其他所有网卡上的 DNS，让走散的查询无路可走。然后验证：跑一次泄漏测试，检查它列出的解析服务器——只要有一台属于你的运营商，查询就在漏。

WebRTC泄漏：浏览器把地址交了出去

WebRTC 是浏览器里支撑视频通话的技术，任何网站用几行 JavaScript 就能调用它。为了建立直连，它会收集所有可能通到你机器的地址：本地地址，以及——通过询问 STUN 服务器——你的公网地址。网页无需你的任何参与就能读到这些候选地址。

在全设备隧道下，STUN 请求走在隧道里，发现的是 VPN 的地址。危险的是那些“半吊子”配置：只给浏览器挂的代理，或把浏览器留在外面的分流规则——那种情况下 WebRTC 的 UDP 数据包直接出门，暴露你的真实 IP。

别推理，去测试：我们的免费检测工具 /webrtc-leak-test/ 会当场显示你的浏览器正在泄露哪些地址。要是真实地址出现了，就改用全设备隧道，或者在浏览器设置里禁用 WebRTC。

IPv6泄漏：隧道只罩住了IPv4

很多 VPN 配置只承载 IPv4。如果你的运营商同时提供 IPv6——移动网络大多如此——系统就在隧道之外留着一条能用的 IPv6 路由，而现代系统在网站两者都支持时会优先选 IPv6。结果是选择性暴露：没有 IPv6 的网站看到 VPN 地址，有 IPv6 的网站看到你的真实地址，而只测 IPv4 的检测报告一切正常。

干净的修法有两种。更好的一种是选一家把 IPv6 处理妥当的 VPN——要么与 IPv4 一并装进隧道，要么装一条阻断路由，让 IPv6 数据包被丢弃而不是直接发出。粗暴的兜底方案是在设备或路由器上关掉 IPv6。无论哪种，都要验证：泄漏测试里不应出现任何不属于 VPN 的 IPv6 地址。

怎样正确地测试你的配置

在你实际使用的环境里逐一检测——家里的 Wi-Fi、开着移动数据的手机、咖啡馆的网络——因为泄漏取决于每个网络各自的 DNS 配置和 IPv6 可用性。整套流程大约五分钟：

关闭 VPN 记下真实 IP，连上后确认可见的 IPv4 和 IPv6 地址都变了——我们的 /data-leak-checker/ 一次显示 IP、DNS 解析服务器和 WebRTC
核对解析服务器列表：显示的每一台 DNS 都应属于 VPN，没有一台属于你的运营商
故意掐断隧道——开关一下 Wi-Fi 或强杀应用——观察重连之前网页还能不能加载
系统或 VPN 应用更新后再测一遍，两者都可能悄悄重置网络设置

常见问题

我的网络很稳定，还需要Kill Switch吗？

需要——真正要命的是你预料不到的那些掉线：唤醒笔记本、在 Wi-Fi 和移动数据之间切换、服务器端重启。稳定降低的是隧道断开的频率，改变不了断开时会发生什么。隧道正常时这个开关零成本，它只在失效的瞬间出手。

泄漏测试显示的是VPN的IP，DNS却是运营商的，怎么回事？

这是典型的 DNS 泄漏：流量走隧道，域名查询却仍发给本地网络分配的解析服务器。要么是客户端没能覆盖系统解析设置，要么是操作系统在并行查询多块网卡。开启客户端的 DNS 保护，重连，再测一次。

VPN连着的时候WebRTC还能泄漏我的地址吗？

在全设备隧道下一般不会——WebRTC 的探测流量走在隧道里，发现的是 VPN 地址。泄漏出现在不完整的配置里：浏览器代理、扩展，或把浏览器留在隧道外的分流。跑一次 WebRTC 测试，几秒钟就有定论。

干脆把IPv6整个关掉行不行？

作为粗暴的修法确实管用；在你的 VPN 管不好 IPv6 的网络上，这是务实的选择——几乎所有服务走 IPv4 照样能访问。更干净的答案是选一家自己就能隧道化或阻断 IPv6 的 VPN，保护到位，还不用逐台设备去改。

我主动断开VPN时，Kill Switch会把我的网也掐了吗？

做工扎实的客户端会在你按下断开时撤掉拦截规则，普通流量立刻恢复；拦截是为意外掉线准备的。有些客户端还提供更严格的模式：隧道不在，任何流量都不许走——适合那种永远不该绕开隧道的设备。

泄漏测试应该多久做一次？

凡是动过网络的事之后都测一次：系统升级、VPN 应用更新、换了新浏览器、连上陌生网络、改了路由器设置。每一样都可能重置 DNS 行为或把 IPv6 重新打开。完整测一遍只要五分钟，所以按“每到新网络、每次更新后”来测，比定时打卡更有意义。