故障排查 约 9 分钟阅读

Clash DNS 泄漏检测方法与 fake-ip 防泄漏配置实操

代理连通不代表 DNS 没泄漏。本文给出在线检测与本地抓包两套验证手段,再逐行讲解 enhanced-mode: fake-ip、nameserver 分组与 fallback-filter 的防泄漏写法。

DNS 泄漏是什么,为什么代理通了也可能漏

能打开网页、能测速、延迟看起来正常,不代表这次访问完全经过了代理。DNS 泄漏指的是域名解析请求绕开了代理隧道,直接发到本机系统配置的 DNS 服务器(通常是运营商 DNS 或路由器分配的 DNS)。结果就是:网页数据走了代理,但"你要访问哪个域名"这条信息暴露给了本地网络的 DNS 服务器,对外部观察者而言,访问记录仍能被拼出大致轮廓。

这个问题在纯规则模式(系统代理 + 应用层分流)下尤其常见。多数客户端把系统代理设置为 HTTP/SOCKS5,但操作系统本身发起的 DNS 查询(UDP 53 端口)默认不会走这条代理链路,而是走网卡自带的 DNS 设置。有些应用还会用自己的 DNS 解析逻辑(比如浏览器的 DoH),更加不受系统代理约束。这就是为什么"连接正常"和"DNS 干净"是两件要分开验证的事。

另一种常见诱因是策略组切换。如果代理规则里域名分流写得不完整,某些域名匹配到 DIRECT(直连)策略,那这些域名对应的 DNS 查询大概率也会走本机默认解析路径,同样构成泄漏,只是范围更窄、更隐蔽,平时很难发现。

两套检测手段:在线检测与本地抓包

验证 DNS 是否泄漏,建议在线工具和本地抓包搭配使用,前者快速给出结论,后者能定位具体是哪条查询漏出去的。

在线检测:看 DNS 服务器归属

打开任意一个支持 DNS 泄漏检测的网站,在开启 Clash 且代理生效的状态下运行检测,页面会列出实际处理你 DNS 查询的服务器 IP 与归属地。正常情况下,这些服务器应该属于代理节点所在的机房或者你在配置里指定的公共 DNS(如 Cloudflare、Google Public DNS 的 IP 段),而不是你所在地区运营商的 DNS 网段。如果检测结果里出现了本地运营商的 DNS,说明泄漏确实存在。

做这类检测时注意两点:一是要在切换节点之后等待几秒钟再测,给策略组和 DNS 缓存一点生效时间;二是多测几次、多换几个检测站点交叉验证,单次结果可能受缓存影响出现假阴性。

本地抓包:定位具体泄漏的域名

在线检测只能告诉你"有没有泄漏",要知道"哪些域名泄漏"就得抓包。Windows 上可以用 Wireshark 抓取本机网卡流量,过滤条件写 udp.port == 53 || tcp.port == 853,分别对应普通 DNS 和 DNS over TLS。正常工作时,几乎不应该看到发往运营商 DNS 或路由器网关地址的 53 端口流量;如果看到了,展开该包查看 Query 字段,就能知道具体是哪个域名走漏了。

macOS 和 Linux 也可以直接用命令行工具:

sudo tcpdump -i any port 53 -n

运行后正常浏览几个网站,观察输出里目的地址是不是全部指向你在 Clash 配置里设定的 DNS(比如 fake-ip 模式下,系统层面看到的应该是内网虚拟 DNS 流量,而不是直连外部 53 端口)。如果抓到大量直连外部 DNS 服务器的包,基本可以确定配置存在漏洞。

注意 检测前确认系统代理或 TUN 模式确实处于开启状态,规则模式下也要确认对应应用没有被单独排除在代理之外,否则得到的"泄漏"结论可能只是配置未生效,而不是防泄漏机制本身有问题。

enhanced-mode: fake-ip 原理与配置写法

Clash(及 Meta 内核 mihomo)提供的 DNS 增强解析是解决泄漏问题最直接的手段,核心配置项是 dns.enhanced-mode,常用取值是 fake-ip。它的工作原理是:客户端接管系统 DNS 请求入口,当应用发起域名解析时,不把真实公网 IP 返回给系统,而是从一段私有地址池里分配一个"假 IP"作为解析结果。应用拿到这个假 IP 后正常发起连接,Clash 内核在流量经过代理链路时,再根据这个假 IP 反查出真实域名,交给对应的策略组和真实服务器地址处理。

这样一来,系统和应用层面完全看不到真实的域名解析请求发往了外部 DNS 服务器,DNS 查询这一步被完整地收进了 Clash 自身的处理链路,从根源上避免了走漏。一段典型配置如下:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - +.market.xiaomi.com

逐项说明:enable 打开内置 DNS 服务器;listen 指定内置 DNS 监听的本机端口,系统或 TUN 网卡会把解析请求转发到这里;enhanced-mode 选 fake-ip 即启用假地址映射;fake-ip-range 指定假地址池的网段,通常用保留地址段避免和真实局域网冲突;fake-ip-filter 是白名单,列在里面的域名(常见于局域网设备发现、部分银行 App 的证书绑定检测)会返回真实 IP 而不走假地址,避免功能异常。

需要强调的是,fake-ip 只有在系统实际把 DNS 查询交给 Clash 内置服务器时才生效。TUN 模式下网卡层面接管全部流量,DNS 请求自然会被劫持进来,防泄漏效果最彻底;纯系统代理模式下则依赖客户端把系统 DNS 设置指向自身监听端口,如果这一步没有正确写入系统网络设置,fake-ip 配置再对也不会起作用,这也是很多人配置正确但依然测出泄漏的常见原因。

nameserver 分组与 fallback-filter 的防泄漏细节

假地址解决的是"应用侧看到什么",真正把域名解析成真实 IP 的工作,还是要靠 nameserver 配置项指定的上游 DNS 服务器完成,这一步同样有泄漏风险:如果上游 DNS 本身是不可信的运营商服务器,或者查询过程没有加密,依然可能被中间网络设备记录。建议按国内外分流的思路配置两组 DNS,并用 fallback-filter 做兜底判断:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.facebook.com

nameserver 是默认优先使用的解析服务器,通常填写国内公共 DNS,保证国内站点解析速度;fallback 是备用服务器,建议使用支持 DNS over TLS 的地址(如示例中 tls:// 前缀写法),让解析请求本身也走加密通道,防止被链路中间节点窥探或篡改;fallback-filter 则决定什么时候启用 fallback——geoip-code: CN 表示如果 nameserver 解析出的结果落在中国大陆 IP 段内就采信,否则认为结果可能被污染,转而采用 fallback 里的加密 DNS 重新解析,domain 列表里的域名则强制直接走 fallback,不再信任国内解析结果。

这套双组配置本质上是"就近解析 + 污染兜底",既保证国内站点不必绕远路查询境外 DNS 拖慢速度,又保证需要走代理的域名不会被国内解析结果污染导向错误(甚至是被监控的)地址。配置完成后可以用前文提到的抓包方法验证:境外域名对应的解析流量应该走向 fallback 里配置的加密 DNS,而不是明文的 53 端口。

常见排查清单

  • 检查客户端是否真的启用了增强 DNS,部分客户端把 DNS 模块设为默认关闭,需要在设置里手动打开。
  • TUN 模式下确认虚拟网卡已成功接管路由,系统网络设置里的 DNS 条目应该指向 Clash 内置监听地址或已被虚拟网卡覆盖。
  • 浏览器若单独启用了 DoH(DNS over HTTPS)硬编码解析服务器,可能绕开系统 DNS 设置,需要在浏览器设置里关闭该功能或改用系统 DNS。
  • 路由器或某些安全软件强制指定 DNS 服务器时,可能覆盖 Clash 的 DNS 劫持,需要在系统或路由器层面放行 Clash 监听端口的转发。
  • 规则集里存在遗漏,导致部分域名走了 DIRECT 策略,建议定期检查分流规则,配合日志确认命中的策略组是否符合预期。
建议 优先使用 TUN 模式并开启 fake-ip,再配合双组 nameserver + fallback-filter,基本可以覆盖绝大多数场景下的 DNS 泄漏问题;配置改动后务必重新做一次在线检测加抓包复核。
下载Clash