Clash Verge Rev DNS 泄漏检测与修复方法
代理连上了，网页也能开，但访问记录仍然被运营商看得一清二楚。问题不在节点，在 DNS 查询的路径上。Clash Verge Rev 的 Mihomo 内核本身有能力接管 DNS，但默认配置和实际运行环境之间往往存在缝隙：系统代理模式只拦 HTTP/HTTPS 流量，DNS 查询走的是独立通道；Fake-IP 看似开启，但某个环节的旁路让查询溜了出去。Clash Verge Rev DNS 泄漏的排查，核心是确认“DNS 查询到底从哪条路出去的”，然后把那条路堵上。
01. 先用两个工具确认是不是真的泄漏
判断 Clash Verge Rev DNS 泄漏不需要抓包，两个在线工具足够。
ipleak.net 给出的是单次查询的快照。连上代理后打开页面，看 DNS Addresses 部分。如果列表里出现 114.114.114.114、223.5.5.5 这类公共 DNS，或者 IP 归属地指向你所在城市的电信/联通/移动，就是泄漏。正常的代理环境应该只显示代理节点的出口 IP，或者客户端虚拟地址段（198.18.x.x）。
dnsleaktest.com 的 Extended Test 更严格。它向你的 DNS 服务器发起 50 次随机子域名解析，结果中只要有一个 DNS 服务器不属于代理节点出口网络，就算泄漏。单次查询干净但 Extended Test 暴露问题的情况并不少见，建议两个都跑一遍。
还有一个容易漏掉的检查项：ipleak.net 页面上的 WebRTC 部分。浏览器通过 WebRTC 可能直接暴露本地局域网 IP 或真实公网 IP，这和 DNS 是两条独立的泄漏路径。Chrome 和 Firefox 默认开启 WebRTC，需要单独关闭或安装防护扩展。
| 检测结果 | 含义 | 下一步 |
|---|---|---|
| 只显示代理节点 IP 或 198.18.x.x | 无泄漏 | 无需处理 |
| 出现国内公共 DNS 或 ISP 归属地 | 存在泄漏 | 进入第 02 节 |
| DNS 干净但 WebRTC 显示本地 IP | 非 DNS 泄漏 | 关闭浏览器 WebRTC |
| Extended Test 才出现泄漏 | 部分查询旁路 | 检查 IPv6 与系统代理 |
02. 系统代理模式是最大的旁路来源
如果你只开了“系统代理”而没有开 TUN，DNS 泄漏几乎是默认状态。
系统代理的工作方式是修改操作系统的 HTTP/HTTPS 代理设置，浏览器访问网页时流量走代理，但域名解析发生在流量进入代理之前。浏览器先向系统 DNS 发起查询，拿到 IP 后再向代理发起连接。系统 DNS 指向的是路由器或运营商下发的地址，这条查询路径完全绕过了 Mihomo。系统代理模式是 Clash Verge Rev DNS 泄漏里覆盖面最广的一类来源，因为它不报错、不提示，界面看起来一切正常。
验证方法很简单：关掉 TUN，只留系统代理，跑一次 ipleak.net。如果 DNS 列表出现 ISP 地址，而打开 TUN 后消失，就确认是这个问题。
修复不需要改配置，开启 TUN 模式即可。TUN 通过虚拟网卡在系统层接管包括 UDP 53 端口在内的全部流量，DNS 查询会被强制送入 Mihomo 的处理链路。Clash Verge Rev 的 TUN 开关在“设置”页面，开启后需要确认 dns-hijack 生效。如果 TUN 开启后 DNS 仍然泄漏，继续往下看。
03. Fake-IP 没生效的三种可能
Fake-IP 是 Mihomo 拦截 DNS 查询的核心机制：对匹配的域名返回 198.18.x.x 的虚拟地址，把真实解析推迟到代理连接建立之后。如果 Fake-IP 没有实际生效，查询就会走真实的上游 DNS，泄漏随之发生。
第一种：enhanced-mode 没有设为 fake-ip。 检查当前配置的 dns 段。如果写的是 redir-host 或者根本没写 enhanced-mode，Fake-IP 不会启用。通过 Merge 覆写追加：
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16第二种：fake-ip-filter 范围过宽。 过滤列表中的域名会跳过 Fake-IP，走真实解析。如果列表里塞了大量公网域名，这些域名的查询路径不受 Fake-IP 保护。只保留内网域名和确实需要真实 IP 的特殊场景即可。
第三种：浏览器自己的 DoH 绕过了系统 DNS。 Chrome、Edge、Firefox 的“安全 DNS”功能开启后，浏览器直接连接 DoH 解析器，不经过系统 DNS，Mihomo 的劫持对它无效。在浏览器设置中关闭安全 DNS，或者在排除列表中加入需要走代理的域名。排查阶段先关掉确认泄漏是否消失。
04. nameserver 配置里的泄漏点
即使 Fake-IP 正常工作，需要真实解析的域名（比如代理服务器本身的域名、直连规则命中的域名）仍然会向 nameserver 发起查询。这里配错了，泄漏就从另一条路出去。
proxy-server-nameserver 不要用国内 DNS。 这个字段专门用于解析代理服务器的地址。如果填的是 223.5.5.5 或 114.114.114.114，代理服务器的域名解析请求会发给国内 DNS，直接暴露你正在连接哪个代理。正确做法是使用 DoH/DoT 加密上游，或者指向一个走代理的解析路径：
dns:
proxy-server-nameserver:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-querynameserver 优先用加密协议。 明文 UDP 53 的查询内容在传输过程中可被观测。Mihomo 支持 DoH 和 DoT，在 nameserver 中使用 https:// 或 tls:// 前缀。fallback 字段配合 fallback-filter 可以在检测到污染时切换到加密上游，但配置复杂度较高，先把 nameserver 本身换成加密协议是更直接的改善。
所有修改通过 Merge 或全局扩展覆写进行，不要直接编辑订阅正文，否则更新订阅时会被覆盖。具体的覆写写法可以参考 Merge 与 Script 指南。
05. IPv6 与局域网共享的残余泄漏
IPv6 是 Clash Verge Rev DNS 泄漏里最容易被忽略的旁路。 如果系统启用了 IPv6，而 Mihomo 的 TUN 或 DNS 配置只处理了 IPv4，AAAA 查询可能走独立的 IPv6 通道直接发出。在 DNS 配置中设置 ipv6: false 可以丢弃 AAAA 记录，或者在系统网络设置中禁用 IPv6 协议。配置层面关闭 IPv6 不影响代理使用 IPv4 的正常访问。
局域网共享代理时 DNS 路径不一致。 手机或其他设备通过局域网共享使用 Clash Verge Rev 的代理时，如果手机的 DNS 设置仍指向路由器而非代理主机，查询会走路由器转发，泄漏发生在手机侧而非主机侧。确保共享设备的 DNS 指向运行 Clash Verge Rev 的主机 IP，或者在路由器层面统一 DNS 设置。
修复完成后重新跑 ipleak.net 和 dnsleaktest Extended Test。如果结果干净，但部分国内网站变慢或无法访问，说明 DNS 策略过于激进，需要在 nameserver-policy 中为 geosite:cn 指定国内直连 DNS，平衡防泄漏与国内解析速度。更多 TUN 与 DNS 的联动配置可以参考 TUN 模式完全指南，或者到 FAQ 页面 搜索 dns-hijack、fake-ip-filter 等关键词。