Clash DNS 泄漏怎么检测:fake-ip 模式与防泄漏配置实操

▶DNS 泄漏是什么,为什么会发生

代理软件的核心工作分成两部分:先把域名解析成 IP,再把连接这个 IP 的流量送进隧道。规则分流(比如按域名匹配国内直连、境外走代理)依赖的前提是 Clash 自己完成解析并按结果路由。如果 DNS 查询没有经过 Clash,而是直接从系统网卡发往本地运营商 DNS 或某个未经代理的解析器,监听方就能拿到完整的域名访问记录——这就是 DNS 泄漏。它不影响网页能不能打开,所以很容易被忽略,但对隐私和分流准确性都是硬伤。

常见的泄漏成因并不神秘,基本集中在下面几类:

• 浏览器开启了内置的安全 DNS(DoH),绕开系统解析器直连指定的加密 DNS 服务商,完全脱离 Clash 的接管范围。
• 虚拟机、容器或某些沙盒环境使用独立的网络栈和 resolv.conf,不走主机的代理配置。
• TUN 模式开启但 DNS 劫持没配置到位,53 端口的 UDP 请求绕过虚拟网卡直接出网。
• 系统同时保留了 IPv6 网络出口,而 Clash 的 dns 段只处理了 IPv4 查询,IPv6 解析走了原生通道。
• 规则集里给某些域名打了 no-resolve,本意是跳过解析只匹配 IP 段,但配置顺序不对导致该域名的解析请求提前从系统发出。

▶检测 DNS 泄漏的可复现步骤

检测不需要额外软件,分成四步,任何平台都能照做:

1. 先记录一次“干净”结果。 完全关闭代理和 VPN,用命令行工具解析一个域名,记下返回的解析服务器地址,这是你的运营商原生 DNS 出口。
2. 开启 Clash 后重复同一次查询。 命令行下用 nslookup 或 dig 解析同一个域名,如果第二次返回的解析服务器地址和第一步完全一致,说明这次查询压根没经过 Clash,直接走了系统原生路径。
3. 用抓包工具确认端口去向。 用 tcpdump 或 Wireshark 抓 53 端口(以及 853 端口,DoT 走这个口)的流量,观察这些包是从哪个网卡发出去的。走 TUN 网卡或本地环回口(Clash 监听地址)才算安全,走物理网卡直连外部 DNS IP 就是泄漏。
4. 查看 Clash 自身的 DNS 日志。 把日志级别调到 debug 或直接看控制面板的连接记录,确认目标域名的解析请求确实出现在 Clash 的日志里。没出现,就说明这条查询没被接管。

浏览器层面还有一个更直观的验证方法:打开一个支持多节点检测的在线 DNS 泄漏测试页面,对比开启代理前后返回的解析节点归属地。如果开启代理后归属地仍显示为你的本地运营商所在城市,基本可以确认存在泄漏。

▶fake-ip 与 redir-host:两种增强模式的本质差别

Clash 的 dns 段里,enhanced-mode 决定了域名解析结果如何配合规则路由,这是防泄漏配置里最关键的一个字段。

fake-ip 模式

Clash 收到应用程序的域名解析请求后,不去做真实的公网查询,而是从一个预留的虚拟地址池(通常是 198.18.0.0/16 这类不会在真实网络里出现的段)里分配一个“假 IP”返回给应用。应用拿着这个假 IP 发起连接时,Clash 在建立隧道的瞬间才根据假 IP 反查出对应域名,再按规则决定走直连还是走代理节点,并且这时才做真实解析。整个过程里,系统层面能观察到的解析结果永远是虚拟地址,不会暴露真实的目标域名对应的公网 IP,也不需要依赖系统 DNS 出口,天然贴合 TUN 模式的透明代理场景。

redir-host 模式

Clash 直接向上游 DNS 服务器发起真实解析,拿到真实 IP 后返回给应用,同时把这次查询记录下来,后续这个 IP 对应的连接按规则表转发。这种模式的问题在于两点:一是真实解析结果一旦被应用缓存或被系统层面的其他进程截获,理论上仍有信息暴露的可能;二是遇到大量使用 CDN、一个域名对应多个动态 IP 的网站时,规则按 IP 段匹配容易判断错误,分流不准。redir-host 更适合老版本客户端或者不支持虚拟网卡的部署场景,新配置一般不建议作为首选。

结论很直接:能用 TUN 模式的场景,统一选 fake-ip,防泄漏和分流准确性都更有保障;只有明确需要兼容旧规则集或者调试解析结果时,才临时切到 redir-host。

▶dns 段配置逐项调整,把泄漏路径堵上

确认了模式选择之后,下面这份 dns 段是一份可以直接对照检查的清单,每一项都对应一个具体的泄漏风险点:

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"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  ipv6: false

• enable / listen——先确认 DNS 服务确实被开启并监听在指定端口,如果客户端图形界面里没手动打开这一开关,配置文件写了也不会生效。
• enhanced-mode: fake-ip——按上一节的结论固定选择,配合 fake-ip-range 使用一个不会与真实公网地址冲突的私有段。
• fake-ip-filter——局域网设备、内网服务这类域名要排除在假 IP 分配之外,否则局域网内直连会失败,这里的排除不会造成泄漏,因为本身就是内网访问。
• default-nameserver——专门用来解析下面 nameserver 和 fallback 里那些 DoH/DoT 域名本身,必须填写裸 IP,否则会出现“解析加密 DNS 域名却又需要 DNS”的死锁。
• nameserver——上游解析用加密协议(DoH 或 DoT),避免这一跳本身在网络中间被明文记录,同时这些查询默认会经过 Clash 处理而不是直接走系统网络。
• nameserver-policy——针对特定域名分组指定专用上游,常见做法是国内域名走本地解析加速,境外域名走加密上游,兼顾速度与隐私。
• fallback / fallback-filter——当默认上游返回的结果被判定为污染或不可信时,自动切换到备用解析器,geoip-code: CN 用来判断返回结果是否落在预期地区。
• ipv6——如果系统或路由器仍保留 IPv6 出口,而这里没有对应处理,IPv6 域名解析会绕过 fake-ip 直接走原生通道,是最容易被忽略的泄漏点。没有针对性配置 IPv6 规则前,建议直接关闭。

▶系统层与浏览器层的补充检查

配置文件调好之后,还有几个不在 dns 段内、但同样会导致泄漏的系统级设置值得逐一确认:

1. 浏览器安全 DNS 开关统一设为“跟随系统”,不要单独指定固定的 DoH 服务商,否则浏览器流量会绕过 Clash 的 DNS 接管逻辑。
2. 操作系统的网络适配器 DNS 设置尽量清空或保持自动,不要手工填入运营商 DNS 地址作为“备用”,备用地址在某些系统策略下会被优先采用。
3. 路由器或家庭网关如果开启了 DNS 劫持功能,可能会在设备发出加密 DNS 请求前就被拦截替换,这种情况需要在客户端侧确认加密协议(DoH/DoT)确实建立成功而不是被降级成明文查询。
4. 多用户或多网络配置文件切换时,重新走一遍第二节的检测步骤,不要假设一份配置在所有网络环境下表现一致——公共 Wi-Fi、企业网络、移动数据网络的 DNS 劫持策略可能完全不同。

把以上检查项走完一遍,基本可以确认 DNS 请求的完整链路都被收进了代理隧道。防泄漏配置不是一次性工作,换设备、换网络、升级客户端版本之后都值得用第二节的四个步骤复测一次,成本很低,能提前发现规则分流“看起来生效但实际漏风”的情况。