故障排查 预计阅读 12 分钟

Clash DNS 泄漏检测方法与防泄漏配置步骤

用在线检测站与本地抓包两种方式确认 DNS 是否绕过代理直连，再从 dns 段的 nameserver、fallback、fake-ip 三处入手把泄漏堵住。

先判断什么情况才算 DNS 泄漏

浏览器访问域名时，需要先把域名解析成 IP 地址。代理连接已经通过 Clash 转发，不代表 DNS 查询也一定进入代理链路。如果 Windows 仍把 UDP 53 或 TCP 53 查询发送给当前宽带、公司网络或公共 Wi-Fi 下发的解析器，网络提供方仍可看到查询过的域名，这就是排查时最常见的 DNS 泄漏。

检测结果里出现本地运营商并不自动等于配置错误。规则模式可能有意让国内域名使用本地解析器，把国外域名交给另一组解析器；这种分流会在检测页面中同时显示多个 DNS 出口。真正需要关注的是：本应由代理处理的域名是否仍通过物理网卡直连查询，以及切换节点后 DNS 出口是否始终停留在本地网络。

常见泄漏路径

用在线检测站做三轮对照测试

在线 DNS 检测适合快速确认现象，但一次结果不足以下结论。浏览器缓存、系统 DNS 缓存、检测站的节点归属库都会影响显示。建议使用同一个浏览器、同一个检测页面连续做三轮，并记录代理出口 IP、DNS 服务器数量、运营商名称和所在地区。

  1. 完全退出 Clash，等待 30 秒后执行一次标准检测，记录本地网络的 DNS 基线。
  2. 启动 Clash，只开启系统代理，选择一个与本地网络地区不同的节点，再执行一次完整检测。
  3. 保持同一节点，开启 TUN 与 DNS 劫持，清理缓存后第三次检测，对比结果变化。

清理 Windows DNS 与浏览器缓存

以管理员身份打开 PowerShell 或命令提示符，执行以下命令清理 Windows DNS 缓存：

ipconfig /flushdns

Chromium 系浏览器还可能保留自己的主机缓存与连接池。关闭全部浏览器窗口再重新打开通常最直接。测试时不要同时运行其他 VPN、游戏加速器、虚拟机网络或公司安全客户端，否则 DNS 可能被另一层网络组件接管。

测试结果 可能原因 下一步
只显示本地运营商 DNS Clash DNS 未接管，或浏览器仍使用系统解析 检查 TUN、dns-hijack 与系统代理状态
同时显示本地与远程 DNS 规则分流、缓存或多条解析链并存 清缓存后抓取 53 端口流量
节点切换后 DNS 不变 解析器固定直连，或配置有意使用固定 DoH 确认 DNS 请求是否按规则经过代理
检测正常但个别应用仍泄漏 该应用使用独立 DNS 或绕过系统代理 改用 TUN 并启用 DNS 劫持

在 Windows 本地确认 DNS 是否直连

Windows 自带的 pktmon 可以快速检查是否存在明文 53 端口请求。它不需要安装额外工具，适合确认 TUN 开启前后是否还有数据包从物理网卡发出。请先关闭正在运行的抓包任务，再以管理员身份打开 PowerShell。

pktmon stop
pktmon filter remove
pktmon filter add DNS -p 53
pktmon start --etw -m real-time

保持窗口运行，打开几个此前没有访问过的网站，观察目标地址与网络适配器。测试结束后按 Ctrl+C，再执行：

pktmon stop
pktmon filter remove

如果目标是路由器地址，例如 192.168.1.1:53，或宽带下发的公网 DNS，并且数据包来自 Wi-Fi、以太网物理适配器，说明仍有明文查询没有被 Clash 接管。若只在 Clash 启动瞬间看到少量请求，可能是加密 DNS 域名的引导解析；如果浏览网页时持续出现，则应继续调整配置。

检查系统当前使用的解析器

下面的 PowerShell 命令会列出所有网卡的 DNS 地址。重点查看正在联网的 Wi-Fi 或以太网，以及 Clash、Wintun、Mihomo 等虚拟适配器：

Get-DnsClientServerAddress |
  Where-Object {$_.ServerAddresses.Count -gt 0} |
  Format-Table InterfaceAlias, AddressFamily, ServerAddresses -AutoSize

nslookup 更适合确认系统 DNS 基线，不适合单独证明浏览器是否泄漏。它通常直接调用系统配置的解析器，可能不会复现浏览器通过 SOCKS、HTTP 代理或独立 DoH 发出的请求。排查时应把 nslookup 结果与 pktmon、Clash 日志放在一起看。

调整 nameserver、fallback 与 fake-ip

DNS 配置的目标不是简单堆叠服务器地址，而是明确三件事：Clash 用哪个解析器处理普通域名，加密 DNS 地址由谁完成首次解析，返回结果如何交给规则系统。下面是一份适合检查结构的基础示例，使用 YAML 时必须保持缩进一致。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

default-nameserver：只负责引导解析

default-nameserver 通常填写可直接访问的 IP 地址，用来解析 DoH 服务器自身的域名。例如系统需要先知道 dns.alidns.com 的 IP，才能建立 HTTPS 连接。这里不宜填写域名形式，也不应塞入大量地址。两个稳定的 IP 解析器已经足够提供容错。

nameserver 与 fallback：明确分流目的

nameserver 是主要解析器，fallback 是经典 Clash 配置中的备用解析器。配合 fallback-filter 后，内核会根据 GeoIP、返回地址范围等条件决定采用哪一组结果。不同 Clash Meta 或 mihomo 版本对 DNS 策略的扩展能力不同，使用订阅覆盖配置时还要确认客户端是否保留了本地 DNS 段。

DoH 只负责加密 DNS 内容，不自动保证连接经过代理。如果希望远程解析器按代理规则建立连接，应使用支持 respect-rules、proxy-server-nameserver 与 nameserver-policy 的较新 mihomo 内核，并先为代理服务器域名准备独立解析器，避免“解析代理服务器必须先连接代理”的循环依赖。

fake-ip：让域名先进入规则系统

fake-ip 模式会先向应用返回 198.18.0.0/16 范围内的映射地址，等应用建立连接时再恢复原始域名并匹配规则。它能减少应用自行解析后只提交目标 IP 的情况，对规则分流与 DNS 接管更稳定。这个地址段用于基准测试网络，不应与家庭或公司实际网段冲突。

局域网设备发现、打印机、游戏平台联机、STUN 和部分登录域名可能不适合 fake-ip，应加入 fake-ip-filter。过滤列表不应直接复制数百条未经确认的规则；每增加一项，都意味着该域名改用真实 IP 解析。出现局域网设备找不到或应用登录循环时，再根据日志补充具体域名更容易维护。

用 TUN 与 DNS 劫持覆盖非代理应用

系统代理只影响遵守 Windows 代理设置的程序。命令行工具、游戏、商店应用和部分启动器可能直接建立连接，因此仅靠 System Proxy 很难完整接管 DNS。TUN 模式会创建虚拟网卡，在 IP 层处理流量，再配合 dns-hijack 捕获应用发出的 53 端口查询。

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

在 Clash for Windows 0.20.39 中，可先进入「General」→「Service Mode」安装服务模式，再打开「General」→「TUN Mode」。配置文件本身可在「Profiles」中找到当前配置，通过右键菜单的「Edit」检查 DNS 段。不同的 mihomo 图形客户端菜单名称会有差异，但需要同时确认内核权限、TUN 开关和 DNS 劫持三项。

strict-route: true 在 Windows 上有助于限制多宿主 DNS 等旁路路径，但公司 VPN、Hyper-V、WSL、虚拟机桥接和局域网共享可能因此改变路由。启用后如果无法访问打印机或 NAS，先查看路由表和 Clash 日志，不要直接把所有私有地址加入代理规则。

IPv6 也要纳入同一套判断

配置中的 dns.ipv6: false 表示 Clash DNS 不返回 AAAA 结果，适合代理节点或当前网络没有稳定 IPv6 的情况。如果本地网络支持 IPv6、代理节点也具备 IPv6 出口，可以改为 true，但必须同时确认 TUN、路由和规则能够处理 IPv6。仅关闭 DNS 的 AAAA 返回，不等于系统层面的 IPv6 已关闭。

按固定顺序复测并定位残留问题

完成修改后，不要一次切换多个节点、模式和浏览器。固定一个节点，先重新载入配置，再用统一顺序复测，才能判断是哪一步产生变化。

  1. 在客户端日志中确认 YAML 已成功载入，没有缩进、字段或解析器地址错误。
  2. 确认当前配置的 dns.enable 为 true，监听端口 1053 没有被其他程序占用。
  3. 开启 TUN 与 dns-hijack，执行 ipconfig /flushdns。
  4. 关闭并重新打开浏览器，访问此前没有打开过的三个域名。
  5. 运行在线完整检测，记录 DNS 数量、地区与服务商。
  6. 同时用 pktmon 检查物理网卡是否仍向外发送 UDP 53 或 TCP 53。
  7. 分别切换规则模式与全局模式再测一次；如果只有规则模式出现本地 DNS，应检查 DNS 策略和直连规则。

检测结果仍显示本地 DNS

网页打不开但泄漏消失

这通常不是检测成功后的正常现象，而是 DNS 已被劫持，但 Clash 自身无法完成上游解析。先检查 default-nameserver 是否为纯 IP 地址，再确认 DoH 地址可达。若代理服务器使用域名，还要为它准备可直连的引导解析路径。恢复网络后再逐步加入 fallback、策略解析与过滤项，不要同时启用全部高级字段。

查看客户端下载