故障排查
预计阅读 13 分钟

Clash DNS 泄漏检测方法与防泄漏配置实操:Fake-IP 与 nameserver 设置

先用检测站点确认 DNS 请求实际出口,再逐项调整 dns 配置:enhanced-mode 选择、fake-ip-filter 例外、默认与备用 nameserver 分工,附验证泄漏是否修复的完整步骤。

先判断什么才算 DNS 泄漏

浏览器访问域名之前，需要先把域名解析成 IP 地址。启用 Clash 后，网页连接可能已经经过代理，但 DNS 查询仍有机会直接发往路由器、运营商 DNS、系统指定的公共 DNS，或者浏览器自行启用的加密 DNS。此时，代理出口与 DNS 请求出口不在同一条路径上。

排查的重点不是简单比较“检测页显示的 DNS 地址是否等于代理节点 IP”。公共 DoH 服务通常由独立服务器响应，Anycast 还可能把查询调度到邻近机房，因此两者本来就可能不同。真正需要确认的是：检测结果中是否出现本地运营商、公司网络、校园网或家庭路由器提供的解析服务，以及这些查询是否绕过了预期的代理与规则路径。

常见的四条 DNS 路径

请求来源 可能走向 排查重点
系统普通 DNS UDP 或 TCP 53 端口 TUN 是否接管 53 端口，系统代理模式能否覆盖该程序
浏览器安全 DNS 浏览器自选 DoH 地址 浏览器设置是否覆盖系统 DNS，检测时是否保持同一策略
Clash 内置 DNS nameserver、fallback 或策略指定服务器 上游地址、代理路径和规则是否正确
应用内置解析 硬编码 DNS、DoH 或 DoT TUN 路由是否覆盖该应用，应用是否绕过系统代理

建立可重复的 DNS 泄漏检测流程

一次检测结果容易受缓存、浏览器连接复用和上游 Anycast 调度影响。可靠的方法是先记录基线，再清理缓存，最后分别在直连和代理状态下重复测试。整个过程应保持同一浏览器、同一网络和同一配置，避免同时改变多个变量。

第一步：记录未启用 Clash 时的基线

  1. 完全退出 Clash 客户端，确认系统代理和 TUN 均已关闭。
  2. 打开 dnsleaktest.com 或 browserleaks.com/dns，执行一次标准检测和一次扩展检测。
  3. 记录检测到的 DNS 服务商、国家或地区、服务器数量。家庭宽带常见结果为 1 至 4 个解析地址。
  4. 再打开操作系统网络详情，记录当前网卡取得的 DNS 地址。常见值可能是路由器地址，例如 192.168.1.1，也可能是网络下发的公网地址。

这组结果用于识别本地解析器。后续启用 Clash 后，如果相同服务商和地址再次出现，就能判断查询是否仍从本地网络发出。

第二步：清理缓存并启用代理

Windows 可先以终端执行 ipconfig /flushdns。macOS 可执行 sudo dscacheutil -flushcache，再执行 sudo killall -HUP mDNSResponder。Linux 的缓存清理方式取决于解析服务；使用 systemd-resolved 时可执行 resolvectl flush-caches。

随后启动客户端，导入目标配置并启用代理。若准备验证所有应用的 DNS，进入「设置」→「网络」→「TUN 模式」开启 TUN；若只测试浏览器系统代理，则保持 TUN 关闭，并明确这次结果只能代表该浏览器的流量路径。

第三步：执行两轮检测

  • 第一轮使用普通窗口，确认日常浏览环境下的实际结果。
  • 第二轮使用新的隐私窗口，减少页面缓存、Service Worker 和旧连接的影响。
  • 每轮至少执行一次扩展检测。扩展检测通常会触发更多随机子域名查询，更容易暴露混合解析路径。
  • 若第一轮显示 2 个指定 DoH 解析器，第二轮突然多出 3 个本地运营商解析器，应按间歇性泄漏处理，而不是只采信较理想的一次结果。

Fake-IP 模式如何接管域名解析

在 mihomo 内核中，enhanced-mode: fake-ip 会为普通域名返回一个保留地址，并在内核中维护“域名—Fake-IP”映射。应用连接这个保留地址时，内核可以还原原始域名，再继续执行域名规则、策略组选择和真实目标解析。默认常见地址池是 198.18.0.1/16，它来自网络基准测试保留范围，不应作为公网目标使用。

Fake-IP 的价值在于把域名信息保留到连接阶段。相比直接向应用返回真实 IP，它更容易让 DOMAIN、DOMAIN-SUFFIX、GeoSite 等规则稳定参与匹配，也能减少应用先自行取得真实地址后再发起连接所造成的规则偏差。

一份可作为起点的 DNS 配置

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

示例中的监听端口是 1053，避免直接占用系统常用的 53 端口。真正接管系统 DNS 时，通常由 TUN 的 dns-hijack 把 53 端口查询导向内核，而不是要求普通用户进程直接监听特权端口。

default-nameserver 负责启动解析

default-nameserver 主要用于解析 DoH、DoT 等上游服务器自身的域名。例如 nameserver 写成 https://dns.alidns.com/dns-query 时，内核必须先知道 dns.alidns.com 的 IP，才能建立 HTTPS 连接。这里优先填写可直接访问的 IP 地址，避免“解析 DNS 服务器还需要先查询 DNS”的循环依赖。

它不是所有业务域名的主解析列表，也不等于系统网卡中的 DNS 设置。把十几个地址堆进 default-nameserver 不会自动提升可靠性，反而会扩大测试变量。通常保留 2 个路径稳定、可直接到达的地址就足够。

nameserver 处理主要域名查询

nameserver 是常规查询的主要上游。可以使用 UDP DNS，也可以使用 DoH 或 DoT。为了减少本地网络读取明文 53 端口查询的机会，常见做法是选用 DoH 地址，例如 https://1.1.1.1/dns-query。但加密只保护客户端到 DNS 服务之间的传输，不代表所有域名都应交给同一个上游，也不代表请求必然通过代理。

如果配置需要让 DNS 连接遵循规则，可以在支持相应字段的 mihomo 版本中使用 respect-rules: true。此时应同时配置 proxy-server-nameserver，用于解析代理节点服务器的域名，否则节点域名本身可能出现循环解析。

nameserver-policy 做精确分工

需要按域名指定解析器时，可以使用 nameserver-policy。它适合处理内部域名、局域网服务或需要特定解析结果的区域性站点，比把全部请求交给多组并行上游更容易验证。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

最后一项只适合确实存在的内部域名场景。若 192.168.1.1 是家庭路由器，向它查询意味着该部分请求会走本地网络。这属于明确的策略选择，不应与意外泄漏混为一谈。

fake-ip-filter 应该排除哪些域名

并非所有域名都适合返回 Fake-IP。局域网发现、设备投屏、部分 STUN 探测、操作系统连通性检查和少数依赖真实地址的程序可能需要例外。fake-ip-filter 的作用是让匹配项获得真实解析结果，而不是关闭整个 Fake-IP 模式。

从最小例外集开始

  • *.lan、*.local：常用于本地设备与局域网服务。
  • 路由器管理域名：只有实际使用时再加入，不要复制与本机无关的厂商域名。
  • 出现语音、视频或联机异常时，再针对日志中的 STUN 域名增加规则。
  • 某个应用只有加入过滤后才能工作时，应记录具体域名，而不是直接排除整个顶级域。

过滤列表过宽会削弱 Fake-IP 的域名映射能力。例如直接加入 *.com 会让大量站点返回真实 IP，域名规则的命中过程也更难追踪。建议每增加一项都保留故障现象、日志域名和复测结果，便于之后移除已经失效的例外。

TUN 模式与 DNS 劫持的关键设置

系统代理主要影响遵循 HTTP 或 SOCKS 代理设置的程序。许多游戏、命令行工具、后台服务和自带网络栈的应用不会读取系统代理，因此仅开启系统代理无法保证它们的 DNS 进入 Clash。TUN 模式通过虚拟网卡接管 IP 流量，更适合验证整机 DNS 路径。

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

any:53 用于接管常规 53 端口 DNS 查询，补充的 tcp://any:53 覆盖 TCP DNS。auto-route 负责自动加入路由，auto-detect-interface 用于识别默认出口。strict-route 可减少查询绕过 TUN 的机会，但在虚拟机、企业 VPN、局域网共享和多网卡环境中可能影响原有路由，需要逐项验证。

客户端里的检查顺序

  1. 进入「配置」页面，确认当前配置已成功载入，界面没有 YAML 解析错误。
  2. 进入「设置」→「网络」→「TUN 模式」，开启 TUN 并按系统提示授予网络或管理员权限。
  3. 进入「设置」→「参数设置」，确认使用的是目标内核与目标配置，而不是之前缓存的配置副本。
  4. 打开「日志」，把级别临时调整为 Debug，搜索 dns、fake-ip 或测试域名。
  5. 完成测试后将日志级别恢复为 Info，避免长期记录大量调试信息。

不同客户端版本的菜单文字可能略有差异，但检查目标相同：当前配置、内核 DNS、TUN 开关、路由接管和日志记录必须对应同一运行实例。如果系统托盘中还留有另一个 Clash 客户端，两个进程可能同时修改代理、端口和路由。

常见泄漏原因与对应修复

只开了系统代理，没有启用 TUN

浏览器网页连接可能走代理，但系统解析仍发送到网卡 DNS。修复方式是启用 TUN 与 DNS 劫持，或明确把系统 DNS 指向客户端监听地址。对于整机接管场景，前者通常更容易统一管理。

浏览器自行启用了 DoH

浏览器可能直接连接其选定的 DoH 服务，从而绕过 Clash 的域名分流。先关闭浏览器安全 DNS做对照；若关闭后检测结果恢复正常，再决定是让浏览器跟随系统，还是通过规则明确接管该 DoH 连接。不要只根据一个浏览器的结果推断所有应用。

nameserver 使用明文 UDP 且直连

若 nameserver 只填写 8.8.8.8、1.1.1.1 之类 IP，查询通常通过 UDP 53 发出。它可能仍由 TUN 路由处理，但传输本身不是加密 DNS。希望减少本地网络观察时，可改用对应的 DoH 地址，并在日志中确认 HTTPS 连接实际采用的策略。

节点域名出现解析循环

代理节点地址如果是域名，内核必须先解析节点才能建立代理；但若该解析又被规则要求通过尚未建立的代理，就会形成循环。表现通常是配置载入成功、节点却全部超时。为节点域名单独设置 proxy-server-nameserver，并确保这些解析器在代理建立前可到达。

IPv6 查询或连接走了另一条路径

配置中写了 ipv6: false 只会影响内核 DNS 是否返回 AAAA 结果，不一定关闭操作系统全部 IPv6 流量。如果本地网络提供 IPv6，而 TUN 路由只覆盖 IPv4，应用可能改走 IPv6。测试时应同时检查 IPv4、IPv6 地址与 DNS 结果；暂时关闭系统网卡 IPv6 可用于对照，但最终应修正 TUN 和路由覆盖范围。

旧缓存造成假象

系统、浏览器、应用和 mihomo 内核都可能缓存解析结果。修改配置后立即刷新原页面，可能不会触发新查询。应清理系统缓存、重启浏览器，并使用随机子域名或检测站点的扩展模式重新触发解析。

修复后的完整验证清单

验证阶段不要只看网页是否能打开。连接成功只能说明至少有一条路径可用，不能证明所有 DNS 都按预期流动。建议按下面的顺序执行，并把每一步结果记录下来。

  1. 检查配置载入：日志中没有 yaml、parse、dns config 相关错误。
  2. 检查监听端口：确认示例中的 1053 或实际配置端口由当前内核监听，没有被另一进程占用。
  3. 检查 Fake-IP：查询普通域名时应能观察到 198.18.0.0/16 范围内的返回值；过滤列表中的域名则应返回真实地址。
  4. 检查规则命中：在连接或日志页面查看测试域名使用的规则与策略组，确认没有意外落入 DIRECT。
  5. 运行扩展检测：连续执行两次，结果中不再出现基线阶段记录的本地运营商解析器。
  6. 切换浏览器设置复测：分别在安全 DNS 开启与跟随系统两种状态下测试，明确差异来自哪里。
  7. 测试非浏览器应用：使用命令行工具或另一款应用发起连接，确认 TUN 接管不是只对浏览器有效。
  8. 重启后复测：重新启动客户端和系统，确认 TUN、DNS 与配置选择可以按预期恢复。
nslookup example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

命令中的地址和端口要按实际监听值调整。若客户端只监听 127.0.0.1:1053，就不能省略 -p 1053。在 Fake-IP 模式下，A 记录返回 198.18.x.x 通常是正常现象；这不是目标网站的真实公网地址。

一套更稳妥的调整顺序

实际排查时，推荐按照“确认基线—统一接管—缩小例外—验证日志”的顺序操作。先保留 2 个明确的 nameserver，启用 Fake-IP 和 TUN DNS 劫持，确保基本路径稳定；随后再添加 nameserver-policy、局域网解析和应用兼容条目。

不要一次复制体量很大的 DNS 配置。字段越多，解析路径越难解释。对多数个人设备而言，能够说明每个上游的用途、每条例外的来源，以及每条查询是否经过代理，比堆叠大量解析器更重要。完成修改后，用相同检测站点、相同浏览器状态和相同网络重复测试，才可以判断泄漏是否真正修复。

前往客户端下载 Windows、macOS、Android、iOS、Linux