Clash DNS 泄漏检测与修复:防泄漏配置实操步骤

DNS 泄漏是什么:代理开着,查询却走了本地

域名解析是上网的第一步:浏览器拿到域名后,要先把域名翻译成 IP 地址,这一步由 DNS 完成。所谓 DNS 泄漏,就是代理已经显示「已连接」,但解析请求仍然从你的真实网络直接发出,落在运营商或路由器的 DNS 服务器上。后果有两层:一是隐私,你访问过哪些域名、什么时间访问,本地网络提供方看得一清二楚;二是可用性,本地 DNS 返回被污染的结果时,浏览器会拿到错误 IP,典型症状就是「Clash 显示已连接,网页却打不开,或打开的是错的内容」。

开了代理为什么还会漏?常见原因有四个:

• 系统代理模式只接管浏览器等应用的网页请求,不改动系统 DNS 设置,网卡上由运营商自动下发的 DNS 照常工作。
• Clash 的内置 DNS 没有启用,或者启用了但监听地址没有覆盖系统实际使用的解析通道。
• 浏览器自带「安全 DNS」(DoH)功能,绕开系统解析器自己直连 DoH 服务器,检测结果也会因此失真。
• IPv6 链路没被接管,AAAA 查询顺着 IPv6 的 DNS 服务器溜走——只改 IPv4 的 DNS 堵不住这条路。

第一步:先检测,确认有没有漏

修复之前先取证。按下面的顺序做一遍,确认泄漏是否存在、漏在哪条链路上。

1. 打开 Clash 客户端,确认代理已连接,记下当前模式(规则、全局或直连)。
2. 暂时关闭浏览器的安全 DNS:Chrome 在「设置 → 隐私和安全 → 安全 → 使用安全 DNS」里关闭;Edge 路径相同;Firefox 在「设置 → 网络设置」里取消「启用基于 HTTPS 的 DNS」。不关的话,检测反映的是浏览器 DoH 的走向,而不是系统链路。
3. 打开任意一个公开的 DNS 泄漏检测页(如 dnsleaktest、ipleak、browserleaks 的 DNS 检测),先跑标准测试,再跑扩展测试。
4. 对照结果判断:列表里出现你所在省份的电信、联通、移动等运营商 DNS 节点,说明存在泄漏;只出现 Cloudflare、Google 等境外公共 DNS 或代理出口机房的解析器,说明没有泄漏。
5. 系统代理模式和 TUN 模式各测一次。两种模式的接管范围不同,结果经常不一样。

一个容易误判的点:如果你的 nameserver 里配置了国内公共 DNS(如阿里 223.5.5.5),检测站可能显示阿里的节点。这代表查询从真实网络直达阿里,严格来说真实 IP 暴露给了这家 DNS 服务商,但不算运营商层面的泄漏。追不追究这一层,取决于你要「常规分流」还是「严格防泄漏」,下文两套写法都会给出。

修复一:把 nameserver 写对

Clash 的 DNS 行为由配置文件里的 dns 段落控制。先逐字段看清楚,再动手改。

• enable:内置 DNS 总开关,防泄漏必须为 true。
• listen:监听地址与端口,写 0.0.0.0:53 表示接管发到本机 53 端口的查询。
• enhanced-mode:fake-ip 或 redir-host。fake-ip 返回 198.18.0.1/16 段的虚拟地址,Clash 接管连接时在内部反查域名,解析全程不出 Clash,是防泄漏最彻底的模式;redir-host 则由客户端先解析出真实 IP 再发起连接。
• nameserver:默认上游,负责直连域名的解析。建议用带 IP 的 DoH 地址,如 https://223.5.5.5/dns-query、https://119.29.29.29/dns-query。
• fallback:命中境外域名时使用的上游,通常填 https://1.1.1.1/dns-query、https://8.8.8.8/dns-query,查询经代理发出。
• default-nameserver:用来解析上面那些 DoH 服务器自身域名的「引导 DNS」,填纯 IP(如 223.5.5.5、119.29.29.29),避免「解析 DNS 服务器的域名本身又需要 DNS」的死循环。
• proxy-server-nameserver(mihomo):解析节点服务器域名专用,填可信的国内 DoH,防止节点域名被污染导致连不上节点。

常规分流的一套完整示例:

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://223.5.5.5/dns-query
    - https://119.29.29.29/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

严格防泄漏的写法是去掉 nameserver 里的国内上游,全部走 fallback 经代理解析,代价是国内站点首次解析略慢。折中方案是用 nameserver-policy 按域名分流:

  nameserver-policy:
    "geosite:cn":
      - https://223.5.5.5/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

修复二:让查询真的走到 Clash(劫持监听)

配置写得再对,系统不把查询发给 Clash 也是白搭。三种接管方式,按省心程度排序。

方式一:TUN 模式(推荐)

mihomo(Clash Meta)内核的 TUN 模式会建一张虚拟网卡,接管整机全部流量,包括 UDP 53 的 DNS 查询;dns-hijack 会把发往任意地址 53 端口的查询劫持进内置 DNS。Clash Verge Rev、Clash Nyanpasu、FlClash 等客户端在设置里可一键开启,开启后系统 DNS 填什么都不再重要。

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true

方式二:手动改系统 DNS

把网卡的 IPv4 DNS 改为 127.0.0.1,IPv6 DNS 改为 ::1(或干脆停用 IPv6),配合 dns.listen 监听 53 端口。注意 Windows 的 Internet 连接共享、部分虚拟机的网卡服务会占用 53 端口,导致 Clash 启动报错。这时要么找出占用方并停掉,要么直接改用 TUN 模式——不要硬改监听端口,Windows 的网卡 DNS 设置不支持指定 53 以外的端口。

方式三:只靠系统代理 + redir-host

这是接管最弱的一种:只有走代理的应用流量被接管,系统里其他进程的 DNS 查询仍走原路。如果暂时不能开 TUN,至少确认浏览器 DoH 已关闭,并接受「只管住浏览器」的边界。

修复三:规则兜底与复检清单

最后一层是规则。DNS 配置决定「怎么解析」,规则决定「漏网的查询流量往哪走」。

• 确认规则末尾的 MATCH 指向代理策略组而不是 DIRECT,未命中任何规则的流量(包括应用自带的 DoH 请求)才不会直连出去。
• 不要给 53 端口加 DIRECT 规则;TUN 模式下 dns-hijack 已经接管,多余规则只会添乱。
• 应用内置 DoH 是最常见的漏网通道,可以把 dns.google、cloudflare-dns.com、mozilla.cloudflare-dns.com 等公共 DoH 域名指向 REJECT,逼应用回退到系统解析,交给 Clash 统一处理。

全部改完后,按这份清单复检:

1. 重新跑一遍泄漏检测,确认结果里只剩境外解析器。
2. 换一个网络环境(比如从家宽切到手机热点)再测一次,排除单链路的偶然性。
3. 手动更新一次订阅,确认 dns 覆写仍然生效,然后再测一遍。
4. 接下来几天留意有没有网站打不开:个别服务与 fake-ip 不兼容,把对应域名加进 fake-ip-filter 即可,不必为此退回 redir-host。

DNS 泄漏不是一次性问题:换客户端、换网络、订阅更新都可能把配置打回原形。把「改完就测、更新后再测」变成习惯,防泄漏才算真正完成。