很多人以为「开了代理就万事大吉」，但实测下来，相当比例的客户端配置都存在泄漏：浏览器里查一下真实 IP，出口还是自己家的宽带；DNS 解析记录里，本地运营商的服务器赫然在列。泄漏意味着什么？轻则代理白开——该走代理的流量还在直连；重则真实网络身份暴露，账号被风控、跨境业务被关联、甚至被针对性封锁。这篇文章把 DNS 泄漏、WebRTC 泄漏、IPv6 泄漏、分流失效四条泄漏路径逐一讲透，给出 ipleak.net 等工具的检测方法，以及 Clash Verge Rev、v2rayN、Sing-Box、Shadowrocket 全平台的封堵配置，最后附一份可以直接照抄的自检清单。先说明一个前提：本文所有配置都以「机场订阅 + 客户端」的常见组合为例，自建节点场景的原理完全相同，只是出口换成了你自己的 VPS。
一、代理客户端的四种泄漏路径
要防泄漏，先搞清楚流量在客户端内部是怎么走的。数据包从输入网址到页面加载的完整旅程，在数据包科普文里拆得很细，这里只聚焦「泄漏」发生的三个节点：DNS 解析、连接建立、分流决策。
1. DNS 泄漏（最常见）。系统代理模式下，浏览器/系统把 TCP 连接交给代理，但 DNS 解析往往还在本地完成。如果你的系统 DNS 是运营商的 114.114.114.114 或路由器下发的地址，那么访问 google.com 时，这条 DNS 查询会直接发给本地解析器——运营商看到你在解析被墙域名，这就是 DNS 泄漏。更麻烦的是，本地解析器对墙内域名返回的是污染后的假 IP，代理客户端拿到假 IP 再去连，自然连不通。
2. WebRTC 泄漏（浏览器场景高发）。网页里的视频通话、在线会议、部分直播站点用 WebRTC 技术，它会主动向 STUN 服务器查询自己的公网 IP。这个查询是 UDP 直发，不走 HTTP 代理，于是你的真实 IP 被网页拿到了。哪怕开了系统代理，只要浏览器 WebRTC 还开着，网站就能绕过代理看到你的真实出口。
3. IPv6 泄漏（最容易忽略）。绝大多数代理隧道只处理 IPv4 流量。如果你的设备有原生 IPv6 或者运营商已经普及 IPv6，访问只有 AAAA 记录的网站时，流量会直接走 IPv6 出口，完全绕过代理。现在的宽带普遍默认下发 IPv6 地址，这个坑比想象中普遍。
4. 分流失效（规则写错的泄漏）。「绕过大陆」这类分流规则依赖域名/GeoIP 判断。规则集没更新、新域名不在列表里、或者 DNS 返回了污染 IP 导致 GeoIP 误判，本该走代理的流量就被放行直连了。这种泄漏最难排查，因为表面上看客户端一切正常。
二、泄漏检测三步法：先测再配
配置防泄漏之前，先做一次完整的泄漏体检，记住改完配置再复测一次。检测工具用这三个就够：ipleak.net（DNS + IPv6 + WebRTC 三合一）、dnsleaktest.com（专门测 DNS 泄漏）、test-ipv6.com（测 IPv6 连通性）。
第一步：测出口 IP。打开 ipleak.net，看页面显示的 IP 是不是你代理节点的 IP。如果显示的是家里宽带的 IP，说明代理根本没生效，后面都不用测了。测的时候建议用线路稳的节点做基线——我习惯用自由猫的 IEPL 专线节点，晚高峰也不掉速，测出来的结果才有参考价值，不然节点本身抖动会把泄漏误判成网络问题。
第二步：测 DNS。ipleak.net 页面往下拉有 DNS 测试区，dnsleaktest.com 更直接：点 Extended Test，等它跑完，看返回的解析服务器列表。如果出现中国大陆的 ISP 服务器（电信/联通/移动的 DNS），就是 DNS 泄漏实锤。命令行也可以验证：nslookup google.com，看 Server 那一行是谁——如果不是你期望的境外解析器，就有问题。
第三步：测 WebRTC 和 IPv6。ipleak.net 的 WebRTC 区块会列出浏览器探测到的所有公网 IP，只要出现非代理 IP 就算泄漏；test-ipv6.com 会直接告诉你当前网络有没有 IPv6 流量，以及它是否走代理。三条都过了，才说明配置基本干净。
三、Clash 系客户端防泄漏配置：TUN + fake-ip 与 DNS 配置
Clash Verge Rev、Clash Meta for Android 这类 Clash 内核客户端，防泄漏的核心就两件事：开 TUN，配好 DNS 块。TUN 模式会创建一个虚拟网卡，把系统所有流量（包括 UDP 的 DNS 查询、WebRTC 的 STUN 流量）都收进隧道，这是根治 DNS 泄漏和 WebRTC 泄漏的手段。Clash Verge Rev 的完整订阅、策略组配置在入门教程里写过，这里只讲防泄漏相关的三个配置项。
1. 开启 TUN 模式。Clash Verge Rev 的设置里打开「TUN 模式」开关即可，内核会自动创建虚拟网卡并配置路由。开了 TUN 之后，系统代理开关其实可以关掉，因为所有流量都进隧道了。
2. 配置 DNS 块（关键）。订阅自带的 DNS 配置不一定适合你的网络，建议在全局扩展配置里加一段标准配置：
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://doh.pub/dns-query
- https://dns.alidns.com/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
fallback-filter:
geoip: true
geoip-code: CNfake-ip 的原理值得理解一下：开启后，客户端对域名解析直接返回一个 198.18.x.x 的假 IP，真实的 DNS 查询由客户端自己通过 nameserver/fallback 分组发出：国内域名走阿里/腾讯 DoH（速度快），国外域名走 1.1.1.1/8.8.8.8（不污染），并且 fallback-filter 用 GeoIP 兜底。这样一来，浏览器拿到的永远是个假 IP，真实解析发生在隧道内部，DNS 泄漏从根上被堵死。注意 fake-ip 模式下如果某些应用检测到 IP 是保留段会报错，遇到这种情况可以把该应用加进直连名单。
3. 分流规则用规则集。别手写几百条规则，直接用订阅作者维护的规则集（Rule Provider），比如 Loyalsoldier 的 geosite/geoip 规则集，自动更新，新域名基本不会漏。
四、v2rayN 与 Windows 客户端的防泄漏配置
Windows 上 v2rayN 和 Nekoray 的用户量很大，这两个客户端的防泄漏配置思路和 Clash 略有不同。v2rayN 新版默认用 sing-box 内核，配置入口在「路由设置」和「DNS 设置」两处。
1. 路由设置。v2rayN 的「路由设置」里选「绕过大陆」方案，它会自动生成一套 domain + GeoIP 规则：国内域名直连，国外域名走代理。注意这里的 DNS 解析仍然可能泄漏，所以还要配合下面的 DNS 设置。
2. DNS 设置。v2rayN 参数设置里可以指定 DNS 服务器。最省事的做法是填一个 DoH 地址：https://1.1.1.1/dns-query 或 https://8.8.8.8/dns-query。填了 DoH 之后，客户端的 DNS 查询走 HTTPS 加密通道，本地运营商看不到也改不了。如果你用的是 v2rayN 的 sing-box 内核，也可以在「DNS 设置」里启用 fake-ip 模式，效果和 Clash 的 fake-ip 一样。
3. 系统代理 vs TUN。v2rayN 默认用系统代理模式，DNS 走本地解析，容易泄漏。一劳永逸的办法是开启内置的 TUN 模式（需要 sing-box 内核支持），开启后所有流量包括 DNS 都进隧道。Nekoray 同理，它的「设置 → 路由」里也有绕过大陆选项，配合 DoH DNS 使用即可。这几款客户端的网络栈差异在Windows 客户端横评里有更细的对比，这里不展开。
4. Windows 特有的 IPv6 坑。Windows 默认开启 IPv6，如果宽带支持原生 IPv6，很容易出现 IPv6 泄漏。两个选择：要么在网卡属性里关掉 IPv6（省事），要么在客户端路由规则里把 IPv6 流量也收进代理（复杂，sing-box 内核可以做到）。普通用户直接关 IPv6 最稳。
五、Sing-Box 与移动端防泄漏要点（iOS/Android）
Sing-Box 是现在跨平台统一配置的主流选择，它把 DNS 和路由规则写在一个 JSON 里，配置能力强但上手门槛高。它的完整配置指南在站内单独写过，这里只给防泄漏相关的核心片段：
"dns": {
"servers": [
{ "tag": "remote", "address": "https://1.1.1.1/dns-query", "detour": "proxy-out" },
{ "tag": "local", "address": "223.5.5.5", "detour": "direct-out" }
],
"rules": [
{ "rule_set": ["geosite-cn"], "server": "local" },
{ "rule_set": ["geosite-geolocation-!cn"], "server": "remote" }
],
"fakeip": { "enabled": true, "inet4_range": "198.18.0.0/15" }
}这个配置的核心是「按域名分流 DNS」：国内域名的解析走本地 223.5.5.5，国外域名的解析走代理出口的 1.1.1.1，再配合 fakeip 兜底，DNS 泄漏基本堵死。注意 remote 服务器要带 detour 走代理出口，否则 DoH 查询本身也是直连，一样会暴露。
移动端的情况分系统说：
iOS（Shadowrocket / Quantumult X / Stash / Loon）。iOS 的 VPN 配置天生走系统级隧道（Network Extension），所以只要客户端在跑，所有流量默认都进隧道，DNS 泄漏天然比桌面端少。Shadowrocket 里注意两点：一是「设置 → DNS」可以选 DoH/DoT，建议填 1.1.1.1 或 8.8.8.8；二是「设置 → IPv6」默认开启，如果运营商有 IPv6 而你的节点不支持，建议关掉。Quantumult X 在配置文件 [dns] 段里写 server=1.1.1.1 即可。iOS 四个客户端的完整配置流程可以参考iOS 客户端配置完全指南。
Android（v2rayNG / Clash Meta for Android）。Android 的坑在「分应用代理」：v2rayNG 默认只代理 VPN 列表里的应用，其他应用直连，DNS 也是本地解析。建议在 v2rayNG 设置里选「绕过局域网及大陆地址」，并把 DNS 设为 DoH；Clash Meta for Android 则直接开 TUN 模式 + 内置 DNS，配置思路和桌面 Clash 一致。跨境多账号场景要格外注意 IP 纯净度——做跨境电商、海外社媒多账号运营的朋友，节点 IP 不干净比泄漏本身更致命，住宅 IP 节点能显著降低账号关联风险，这类需求一般直接选仙路湾这类原生/住宅 IP 机场，具体防关联架构可以参考跨境电商多账号网络方案那篇。
六、分流失效与「假泄漏」：三个真实案例排查
配置都对了还泄漏，大概率是分流规则的问题。分享三个实测中遇到的真实案例，都是表面正常、实际泄漏的典型：
案例一：规则集没更新，新域名被放行。某次 ChatGPT 更新后新上线了一批域名，规则集还是旧版，这些域名没匹配到代理规则，落到最后的「直连」兜底，网页能开但 IP 全暴露。排查方法：在 ipleak.net 反复刷新看出口 IP，偶尔变成国内 IP 就是规则漏了。解决办法是把规则集换成自动更新的 Rule Provider，并在客户端设置里开启规则集自动更新。
案例二：fake-ip 与 redir-host 切换引发的「半泄漏」。从 redir-host 模式切到 fake-ip 模式后，如果配置里还残留旧的 nameserver 直连项，部分域名会走本地解析。现象是 DNS 检测偶尔出现本地服务器。排查方法：检查 DNS 块里有没有多余的 nameserver 项，把国内外的解析路径理顺。
案例三：DNS 污染导致的「假泄漏」误判。fallback 解析超时后客户端回落到本地解析器，dnsleaktest 会显示一堆国内服务器。这其实是配置容错，不是真泄漏，但说明 fallback 链路不稳。解决办法是给 fallback 加 detour 走代理，或者换更稳定的 DoH 服务商。这类问题在软路由上更常见，故障排查指南里有一整套定位思路。
案例四：订阅转换把 DNS 配置「转丢了」。用订阅转换工具把机场订阅转成 Clash/Sing-Box 格式时，如果转换模板里没有 DNS 块，生成出来的配置就只有代理节点和基础规则——DNS 解析退回系统默认，泄漏悄无声息。这个坑在机场订阅互转场景里非常常见，转换工具的模板差异、规则集引用方式都在订阅转换与 Sub-Store 指南里讲过。排查方法：转换后打开配置文件搜「dns:」或「\"dns\"」，没有就手动补上本文第三节的 DNS 块。
四个案例看下来，规律很清晰：泄漏从来不是「客户端坏了」，而是「某一层配置缺失或过时」。检测 → 补配置 → 复测，这个循环走两遍，绝大多数泄漏都能根治。
七、防泄漏自检清单（照抄版）
把上面所有内容压缩成一张可以直接对照的清单，改完配置后逐项打勾：
| 检查项 | 操作 | 通过标准 |
|---|---|---|
| 出口 IP | ipleak.net 首页 | 显示节点 IP，非本地宽带 IP |
| DNS 泄漏 | dnsleaktest.com Extended Test | 无中国大陆 ISP 解析器 |
| WebRTC | ipleak.net WebRTC 区块 | 无真实出口 IP 暴露 |
| IPv6 | test-ipv6.com | 无直连 IPv6 流量 |
| TUN 模式 | 客户端设置 | 已开启（桌面端推荐） |
| DNS 配置 | 客户端 DNS 块 | 国外解析走 DoH/代理，非本地 |
| 规则集 | Rule Provider | 自动更新已开启 |
| 订阅转换 | 转换后检查配置 | DNS 块和规则集没有被丢弃 |
这张表每周跑一次即可，不用天天测。重点观察「DNS 泄漏」和「出口 IP」两行，这两项出问题的影响最大。如果你是换了新客户端或者刚做完系统重装，建议全套测一遍，配置迁移最容易在某个角落里漏掉一项。
八、常见问题 FAQ
Q1：系统代理模式下一定会 DNS 泄漏吗？不一定，取决于客户端的 DNS 处理方式。如果客户端把 DNS 查询也转发到代理端（远程解析），就不会泄漏；如果 DNS 留在本地解析，就会泄漏。不确定的话直接跑一次 dnsleaktest 就知道。v2rayN 这类默认本地解析的客户端，建议手动把 DNS 改成 DoH。
Q2：开了 TUN 就一定不泄漏吗？TUN 解决的是「流量进不进隧道」的问题，DNS 配置决定「解析走哪」。TUN + 错误的 DNS 配置（比如 nameserver 全填本地）依然可能泄漏，只是概率低很多。最稳的组合是 TUN + fake-ip + DoH fallback。另外 TUN 只覆盖本机，全家多设备场景还是要靠软路由或路由器端代理，出口选万达云这类中转、IEPL、IPLC 多线路覆盖的机场，不同设备按需分流，稳定性更有保障。
Q3：WebRTC 泄漏是浏览器问题，为什么要客户端管？浏览器层面可以用插件禁用 WebRTC，但插件只保护浏览器，其他应用（比如某些带 WebRTC 的桌面软件）照样泄漏。客户端的 TUN 模式把 WebRTC 的 STUN 流量也收进隧道，是所有应用一起防护，这才是根治。浏览器插件可以作为补充，但不能替代。
Q4：IPv6 是不是直接关掉最省事？对大多数用户是的。IPv6 目前在国内的代理支持还不成熟，关掉 IPv6 能避免绝大多数泄漏问题，代价是访问纯 IPv6 站点会失败——这类站点占比很低。如果你需要 IPv6，选择支持 IPv6 入站/出站的节点，并确认客户端路由把 IPv6 流量也纳入了代理。
Q5：机场订阅自带的 DNS 配置要不要改？先测再说。多数正规机场的订阅 DNS 配置是调好的，直接测 dnsleaktest 如果通过就不用动；测出泄漏再按本文第三节的配置覆盖。改配置前记得备份原订阅配置，避免覆盖后连不上。
Q6：免费节点测出来泄漏正常吗？付费机场是不是都不会泄漏？泄漏和机场无关，和客户端配置有关——同一个机场订阅，配置错了一样泄漏。免费节点更常见的风险是节点本身可疑（记录流量、注入广告），这在免费与付费机场横评里分析过，安全性上付费机场整体更可控，但「防泄漏」这件事，终究要客户端配置正确才能兜住。
Q7：换了新客户端，防泄漏配置要重新配吗？要。不同客户端的 DNS 实现和路由规则格式不通用：Clash 的 YAML 配置、Sing-Box 的 JSON 配置、Shadowrocket 的图形设置，各自独立。换客户端后第一时间跑一遍检测，再按本文对应章节补配置。这也是为什么很多人喜欢用订阅转换工具统一模板——模板里预置好 DNS 块和规则集，换客户端不丢配置。
Q8：防泄漏配置会影响速度吗？影响很小，甚至可能是正收益。fake-ip 模式省去了本地解析的等待，DoH 解析比明文 UDP 略慢几毫秒，但相对跨境链路的几十到上百毫秒延迟可以忽略。真正影响速度的是节点质量和线路拥堵，跟防泄漏配置无关。如果开了 TUN 后感觉变慢，先查 MTU 和分流规则，别急着关 TUN——关掉等于把泄漏问题放回来。
推荐阅读
防泄漏是客户端安全的一环，把这几篇配套看完，网络配置会更完整：
- DNS解析原理与优化指南 — 递归查询、污染对抗、DoH/DoT 的原理级讲解，看懂这篇再调 DNS 配置事半功倍
- IPv6科学上网完全指南 — 想保留 IPv6 而不是一刀切关闭的话，这篇讲清了 IPv6 代理的完整方案
- 多机场订阅管理与策略组高级配置 — 多个机场订阅怎么管理、策略组怎么做负载均衡和故障转移，进阶玩家的下一站