Clash DNS 泄漏检测与修复：解析链路、防泄漏配置实操

DNS 泄漏与 Clash 解析链路

访问网站时，应用通常先把域名交给 DNS 解析器，再连接返回的 IP 地址。代理规则可以决定后续连接走直连还是代理，但 DNS 查询未必自动沿用同一条路径。如果网页流量已经经过代理，域名查询仍被发送给本地路由器、运营商解析器或其他不符合预期的服务器，就形成了常说的 DNS 泄漏。

这里的“泄漏”需要结合预期判断。国内直连域名由本地 DNS 解析并不一定是错误；真正需要关注的是，本应由代理侧解析的域名是否暴露给本地网络、查询结果是否遭到错误改写，以及不同应用是否绕过了 Clash 的 DNS 模块。合理目标不是让检测页面只显示某个固定地址，而是让解析路径与规则设计一致。

一条常见链路可以拆成四层：应用发起查询，操作系统选择 DNS 服务器，Clash 或 mihomo 接收并处理查询，上游解析器返回结果。启用系统代理只影响遵循 HTTP 或 SOCKS 代理设置的连接，通常不会接管操作系统发送到 UDP 53 端口的 DNS 请求。启用 TUN 后，客户端可以进一步截获系统网络流量，但仍需配置 DNS 劫持，才能把普通 UDP/TCP DNS 查询导入内置解析器。

浏览器还可能启用 DNS over HTTPS，也就是 DoH。它把 DNS 封装进 HTTPS 连接并发送到浏览器指定的服务端。此类流量使用 443 端口，普通的 53 端口劫持无法识别，因此会形成一条独立解析路径。排查时必须同时检查 Clash、操作系统和浏览器，不能只看客户端面板中的 DNS 开关。

分层检测 DNS 出口：浏览器、系统与日志

检测前先记录当前模式，包括是否开启系统代理、是否启用 TUN、Clash DNS 是否启用、浏览器安全 DNS 是否开启。随后分别在完全关闭 Clash、仅开启系统代理、开启 TUN 三种状态下测试。对比结果比单次截图更有价值，因为缓存、网络切换和公共 DNS 调度都会让结果发生变化。

第一步：用浏览器测试实际访问环境

1. 关闭浏览器全部窗口并重新启动，避免旧连接和内存缓存影响结果。
2. 访问可信的 DNS 检测页面，执行基础测试与扩展测试，记录解析器 IP、网络提供方和地区。
3. 切换 Clash 的系统代理或 TUN 状态，再次测试并比较解析器是否变化。
4. 检查浏览器设置中的安全 DNS、使用安全 DNS 或 DNS over HTTPS 选项，确认它是否指定了独立服务商。

检测页面通常通过生成随机子域名来观察哪个解析器请求了权威 DNS。它反映的是该页面触发查询时的出口，不代表所有应用都使用同一解析路径。浏览器扩展、企业策略、系统缓存和网络中的透明代理也会改变结果，所以还要配合系统命令与 Clash 日志确认。

第二步：检查操作系统正在使用的 DNS

Windows 可以在 PowerShell 中查看网卡 DNS，并主动查询一个未缓存域名：

Get-DnsClientServerAddress
Resolve-DnsName example.com

macOS 可查看当前解析器列表与系统解析结果：

scutil --dns
dscacheutil -q host -a name example.com

使用 systemd-resolved 的 Linux 发行版可执行：

resolvectl status
resolvectl query example.com

命令输出中的 DNS 服务器可能是本机回环地址、局域网网关或 TUN 分配的虚拟地址。看到本机地址并不表示查询停在本机，还要确认 Clash 最终选择了哪个上游。相反，如果系统明确把查询直接发送到路由器，而 Clash 日志中没有对应记录，说明该请求很可能没有进入 Clash DNS 模块。

第三步：结合日志定位查询路径

在客户端中临时把日志级别调到可观察 DNS 行为的级别，然后查询一个此前未访问的域名。检查日志是否出现域名解析、规则命中、上游连接或失败重试。测试结束后恢复常用日志级别，避免大量调试信息长期占用存储空间。

如果日志完全没有查询记录，优先检查系统 DNS、TUN DNS 劫持和浏览器 DoH。如果日志记录了查询，但上游连接走了不符合预期的 DIRECT 或代理策略，则要检查解析器地址本身如何被规则匹配。若只在首次访问出现异常，后续恢复正常，还应考虑系统、浏览器和 Clash 各自的 DNS 缓存。

Clash Meta（mihomo）DNS 配置与 fake-ip

mihomo 的 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
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "+.local"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - tls://1.1.1.1
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

理解 nameserver 与 default-nameserver

nameserver 是常规域名查询使用的主要上游，可以填写普通 DNS、DoT 或 DoH 地址。加密 DNS能降低本地链路直接读取和修改查询内容的机会，但上游服务本身仍能处理查询，因此要选择可用且符合自身信任范围的解析服务。

default-nameserver 主要承担引导解析。例如 DoH 上游写成域名时，内核需要先获得这个 DoH 域名的 IP，才能建立加密连接。这个字段通常使用可直接访问的 IP 地址，避免“解析 DNS 服务自身时还要先使用同一个 DNS 服务”的循环。引导查询可能仍以普通 DNS 形式发生，所以应选取稳定、符合当前网络预期的地址。

proxy-server-nameserver 用于解析代理服务器域名。代理节点如果以域名填写，建立代理连接前必须先得到节点 IP。把这类查询单独配置，可以降低节点域名解析与普通规则相互循环的概率。使用支持 respect-rules 等新字段时，应先确认当前 mihomo 内核版本及客户端实现，旧内核可能忽略字段或报告配置错误。

fake-ip 如何参与规则匹配

在 fake-ip 模式下，Clash 会向应用返回保留地址段中的临时映射地址，同时保存域名与假 IP 的对应关系。应用连接该地址时，内核能够还原原始域名并继续匹配域名规则。这种方式有利于尽早接管请求，也能减少应用自行使用解析结果直连的情况。

198.18.0.0/15 是常用于基准测试的保留网段，示例中的 198.18.0.1/16 位于该范围内。不要把 fake-ip 地址当作网站真实 IP，也不要用 ping 假 IP 的结果判断远端服务器是否正常。客户端的映射只在当前内核和缓存生命周期内有效。

局域网设备发现、打印机、投屏、部分游戏和依赖真实 IP 的程序可能不适合 fake-ip。此时应把必要域名加入 fake-ip-filter，让它们返回真实解析结果。过滤范围不宜无限扩大，否则大量域名会重新走真实 IP 解析，削弱统一接管和域名规则匹配效果。

TUN 模式与 DNS 劫持配置

仅开启 mihomo 的 DNS 服务，并不代表系统会主动把查询交给它。客户端可以通过修改系统 DNS 指向本地监听端口，也可以在 TUN 中劫持传统 DNS 流量。桌面端常见配置如下：

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

dns-hijack 会把经过 TUN 的 53 端口查询导向 mihomo DNS 模块，覆盖应用自行指定普通 DNS 服务器的常见情况。它通常能处理 UDP 53 与 TCP 53，但不能自动识别发往 443 端口的 DoH，也不能保证所有使用自带网络栈、特殊虚拟网卡或内核级旁路的程序都进入 TUN。

Windows 启用 TUN 往往需要管理员权限以及可用的虚拟网卡组件。macOS 会通过系统网络扩展或 VPN 配置建立隧道。Linux 需要 TUN 设备权限、路由表与防火墙规则配合。Android 和 iOS 客户端通常借助系统 VPN 接口接管流量，同一时间一般只能保持一个主要 VPN 配置活动。

如果开启 TUN 后完全无法解析域名，先检查 TUN 路由是否建立，再检查 mihomo DNS 监听端口是否被占用。还要确认防火墙没有阻止内核访问上游 DNS，代理节点域名能否通过 proxy-server-nameserver 解析。节点域名解析失败时，代理隧道无法建立，而配置又要求上游 DoH 通过代理访问，便会形成启动循环。

同时运行企业 VPN、游戏加速器、虚拟机网络、容器网络或其他代理工具时，多个程序可能争用默认路由与 DNS 设置。排查阶段应逐个暂停冲突工具，确认单独运行 Clash 时的结果，再决定路由优先级。频繁切换网络后若 DNS 指向残留，可先退出客户端并恢复系统自动获取 DNS，然后重新启用 TUN。

浏览器 DoH与应用自带解析器

Chrome、Edge、Firefox 等浏览器可以独立启用加密 DNS。有些浏览器会尝试把系统 DNS 自动升级为对应服务商的 DoH，有些则允许用户手动指定解析器。若指定服务与 Clash 配置不同，浏览器测试会显示另一组 DNS 出口，这不一定意味着 TUN 失效，而是浏览器主动建立了独立 HTTPS 查询连接。

需要让浏览器统一使用 Clash DNS 时，可以关闭浏览器中的自定义安全 DNS，让查询回到操作系统，再由系统 DNS或 TUN 劫持交给 mihomo。另一种方案是保留浏览器 DoH，并通过 Clash 规则控制 DoH 服务连接走代理还是直连，但此时域名查询发生在远端 DoH 服务中，mihomo 无法直接获得每次查询内容，基于域名的分流行为也可能依赖浏览器后续连接携带的域名信息。

部分应用会内置固定 DNS、DoH 或 DoT，杀毒软件和家长控制程序也可能部署本地过滤解析器。发现只有某个应用的结果异常时，应检查该应用的网络设置、启动参数和系统策略，而不是反复更换 Clash 上游。Android 的“私人 DNS”通常使用 DoT；如果它与 VPN 客户端同时工作异常，可以临时设为自动或关闭进行对照测试。测试完成后再根据实际需求决定最终设置。

常见 DNS 泄漏与解析故障排查顺序

检测结果仍显示本地运营商 DNS

先确认浏览器安全 DNS是否关闭，再查看系统 DNS 是否已指向客户端接管地址。若只开启系统代理而未开启 TUN，系统级 UDP DNS 继续发往路由器是常见现象。需要统一接管时，启用兼容的 TUN 与 DNS 劫持，并确认查询能在客户端日志中出现。

开启 fake-ip 后局域网设备无法访问

把局域网域名后缀加入 fake-ip-filter，并确认局域网网段规则位于兜底代理规则之前。访问 NAS、路由器或打印机时，优先使用其局域网地址验证基础连通性。若 IP 可以访问而域名不行，重点检查本地域名是否由路由器 DNS、mDNS 或内部 DNS 提供。

DoH 上游连接超时

检查 DoH 域名能否通过 default-nameserver 完成引导解析，再检查其 IP 是否被错误分流。某些网络会限制特定公共解析服务，盲目增加多个不可达上游只会延长重试时间。保留少量经过验证的上游，并根据直连与代理链路分别设置，比堆叠大量地址更容易定位问题。

代理节点显示可用，但网页提示域名无法解析

节点连通性测试可能使用已有 IP 或缓存结果，不能证明 DNS 链路正常。检查节点地址是 IP 还是域名；如果是域名，确认 proxy-server-nameserver 可用。随后查询普通域名并观察日志，区分“节点域名无法解析”“上游 DNS 无法连接”和“返回结果被规则拒绝”三类问题。

测试结果出现多个解析器

多个解析器可能来自上游服务的集群、浏览器并发查询、回退解析或系统与浏览器两条链路同时工作。先不要按数量直接判断异常。重复测试随机域名，并分别关闭浏览器 DoH、fallback 与其他网络工具，观察是哪项配置引入了额外出口。若所有解析器都属于预期上游，且本地网络解析器未处理代理域名，则结果可能符合设计。

配置更新后问题再次出现

订阅更新可能覆盖客户端的 DNS 段落，也可能改变规则组名称，使原有 nameserver-policy 或上游分流失效。检查客户端采用的是订阅原始配置、覆写配置还是合并配置。需要长期保留的 DNS 设置应放在客户端支持的覆写机制中，并在每次更新后确认最终生效配置，而不是只检查订阅源文件。

完整排查应形成闭环：先明确哪些域名应本地解析、哪些查询应经代理侧处理；再用浏览器测试发现现象，用系统命令确认 DNS 指向，用日志验证查询是否进入 mihomo；最后调整 fake-ip、上游解析器、TUN 劫持和浏览器 DoH。每次只修改一个变量并重新测试，才能判断修复来自哪一项配置。