Clash DNS 泄漏检测:确认是否泄漏与防泄漏配置实操

什么是 DNS 泄漏

代理已经开启、网页也能正常访问,但本机仍然通过系统 DNS 直接向运营商服务器查询域名——查询不经过代理通道,访问过的每个域名都以明文形式留在运营商或网关的日志里,这就是 DNS 泄漏。

泄漏带来两类后果。第一是隐私:谁负责解析,谁就掌握你的完整访问清单,代理建立的加密通道掩盖不了这一环节。第二是可用性:明文的 53 端口查询容易被中间设备劫持,返回被污染或错误的地址,典型表现是节点状态正常,目标网站却打不开,或被带到无关页面。

一个常见误解是「打开系统代理就万事大吉」。系统代理只修改应用的 HTTP 代理设置,并不接管 DNS 查询;不少应用绕过系统代理自行解析,浏览器也可能启用内置的加密 DNS 单独出网。DNS 查询本身就是流量,必须和网页流量一样被完整接管,才算真正堵住泄漏。

检测步骤:先确认是否泄漏

检测之前先关闭其他代理与 VPN 工具,让 Clash 保持开启并处于需要验证的代理模式,避免多个工具叠加干扰判断。

1. 打开任意 IP 查询页面,确认当前出口地址已经是节点地址,先证明代理通道本身工作正常。
2. 打开一个 DNS 泄漏检测页面并运行完整测试,记录结果里列出的 DNS 服务器地址、归属运营商与所在地区。
3. 打开终端执行 nslookup example.com,记下返回信息中的服务器地址;macOS 与 Linux 可以再用 dig example.com 对照。
4. 在 Clash 中把日志级别调整为 debug,再执行一次 nslookup,观察日志中是否出现这条 DNS 查询记录。
5. 查看系统当前生效的 DNS:Windows 执行 ipconfig /all,macOS 执行 scutil --dns,Linux 执行 resolvectl status 或直接查看 /etc/resolv.conf。

把以上几项结果放在一起对照,判定标准如下:

泄漏源头:五个高频原因

确认泄漏之后,按出现频率从高到低排查以下五个源头。

1. 只开系统代理模式——系统代理只接管遵循系统代理设置的应用,UDP 53 上的 DNS 查询不在接管范围内,大量桌面应用仍然直连系统 DNS。
2. 浏览器开启了「安全 DNS」——浏览器内置的 DoH 会绕过系统代理解析,把域名直接送往浏览器指定的 DoH 服务器,系统层面完全看不到这条查询。
3. IPv6 未被接管——只接管了 IPv4 时,AAAA 查询和 IPv6 流量会从本地直连漏出,双栈网络环境下尤其常见。
4. 规则放行了 DNS——配置中存在 DST-PORT,53 直连之类的规则,或把需要代理的域名错误地划进 DIRECT 策略。
5. 运营商或网关劫持 53 端口——即使手动指定了公共 DNS,明文查询也可能被中途改道,最终表现与泄漏完全一致。

防泄漏配置:让解析全部经过 Clash

防泄漏的核心原则只有一条:让所有 DNS 查询先进入 Clash 的 DNS 模块,再由 Clash 决定本地解析还是随代理出网。落地分两步:开启 TUN 接管整机流量,然后正确配置 dns 段。

第一步:开启 TUN 模式

TUN 通过虚拟网卡接管整机流量,包括 UDP 53,任何应用的 DNS 查询都会先落到 Clash,这是堵泄漏最彻底的方式。Windows 需要安装服务模式并以管理员权限运行,macOS 需要授权安装帮助程序,Linux 需要 root 或相应 capabilities。mihomo 内核的配置示例:

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

其中 dns-hijack 的 any:53 表示把发往任意目标的 53 端口查询劫持进 Clash 的 DNS 模块,这是防泄漏的关键一行。

第二步:配置 dns 段

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

• enable 与 listen:Clash 在 53 端口提供 DNS 服务,配合 TUN 的 dns-hijack 接管全部查询。
• enhanced-mode 设为 fake-ip:对需要代理的域名直接返回 198.18.0.0/16 段的假地址,应用拿着假地址发起连接,Clash 按域名还原后交给代理,目标域名全程不在本地解析,这是防泄漏强度最高的一档;redir-host 会先在本地做一次真实解析,存在明文查询窗口。
• ipv6 设为 false:不响应 AAAA 查询,避免 IPv6 旁路;确实需要 IPv6 时,必须同时确认 TUN 已接管 IPv6 流量。
• default-nameserver:引导 DNS,只用于解析 nameserver 中 DoH/DoT 服务器自身的地址,必须填写纯 IP。
• nameserver:常规解析上游,建议使用 DoH 或 DoT 加密形式,让查询经加密通道出网,本地网络只能看到一条到 DoH 服务器的加密连接。
• proxy-server-nameserver:专门用于解析节点域名,避免节点地址解析落到不可信的本地 DNS 上。

如果暂时不能开启 TUN,退而求其次的做法是:保持系统代理开启,把系统 DNS 指向 127.0.0.1,让 Clash 的 dns 模块监听 53 端口接管系统解析。这种方式能覆盖遵循系统 DNS 的应用,但管不住自行指定 DNS 的应用,防护强度明显低于 TUN 方案。

验证生效:改完再测一轮

配置修改后重启 Clash 或重载配置,然后按前面的检测步骤完整重跑一遍,逐项核对:

• 执行 nslookup example.com,服务器地址应显示为 127.0.0.1 或本机地址,证明查询已被 Clash 接管。
• 对一个走代理的域名执行 nslookup,返回 198.18.x.x 段的地址,证明 fake-ip 生效。
• debug 日志中能看到刚才的查询记录,并标注了命中的上游与策略。
• 重跑 DNS 泄漏检测页,结果中不再出现本地运营商或网关的 DNS,只剩代理出口地区的解析记录。
• 连续访问几个国内外站点,确认直连站点解析正常、代理站点打开正常,没有因配置改动引入新的故障。

常见问题