为什么「已连接节点」仍可能和 DNS 泄漏有关？

很多用户第一次排查网络问题时，会把「代理已连上」等同于「所有流量都走节点」。实际上，域名解析与 TCP/UDP 传输可以是两条路径：浏览器或系统可能把 DNS 查询发给本地网卡、路由器或运营商，而 HTTP 流量却走了 Clash 的本地端口。这样一来，你看到的「能翻墙」与「解析是否泄露」并不是同一回事。

在 Clash Meta（Mihomo）体系里，DNS 段负责把「谁来解析域名」写清楚；enhanced-mode（常见为 fake-ip 或 redir-host）决定内核以何种方式把域名映射到后续规则。两者若与订阅里的规则、TUN 模式或系统代理状态不一致，就会表现为：部分站点打不开、CDN 命中异常、或测速网站仍显示本地运营商 DNS。下面先把概念对齐，再落到可操作的检查步骤。

Fake-IP 与 redir-host：到底差在哪里？

Fake-IP 模式下，内核会为域名分配一段虚拟 IP（通常来自 198.18.0.0/15 一类保留地址），应用程序先拿到「假地址」，再在实际连接时由 Clash 完成真实解析与路由。优点是规则匹配更前置，与域名类规则配合更顺畅；代价是你要理解「假 IP」不是真实地理含义，排查时要以日志与嗅探（sniffer）为准，而不是 ping 通不通。

redir-host（或部分文档中的 mapping 相关描述）更偏向「把解析结果映射到连接上」，行为上更接近传统「先解析再按 IP 路由」的直觉。若你在意某些应用对 DNS 缓存极其敏感，或需要与旧版配置兼容，可能会选择 redir-host；但具体字段名与默认值请以你所用的 Mihomo 版本文档为准。

ℹ️
实践建议：社区订阅与 GUI 模板多数以 fake-ip 为主流；若你从未改过 DNS 段，优先在「同一套 enhanced-mode」下把 DNS 服务器与 fallback 配稳，再考虑切换模式，避免同时改动过多变量。

DNS 段：nameserver、fallback 与 fallback-filter

在 Mihomo 配置中，dns 段通常包含 enable: true、enhanced-mode、nameserver 与 fallback 等字段。nameserver 可以理解为「首选 DNS 列表」；当查询命中污染、或需要更可信的解析时，内核会按策略转向 fallback。两者并不是「谁覆盖谁」的简单关系，而是分层协作：前者负责日常吞吐，后者在触发条件时兜底。

fallback-filter 用于定义何时不信任 nameserver 的结果（例如 GeoIP 判定、响应异常等）。若你发现自己「所有域名都走了 fallback」，要检查过滤条件是否过宽；若「永远走不到 fallback」，则要确认上游 DNS 是否被劫持、或客户端是否根本没把 DNS 交给 Clash。

下面是一段仅用于理解结构的示例，请按你的内核版本与订阅要求调整，勿直接复制到生产环境：

# Example only — align with your Mihomo version and provider rules
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query
  fallback:
    - https://dns.trusted.example/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

与 TUN 模式、系统代理的关系

若你仅开启系统代理，部分应用仍可能使用系统或自定义 DNS，Clash 侧看不到完整查询链。开启 TUN 后，常见做法会配合 dns-hijack 把 53 端口流量导入内核，使「解析与转发」更一致。若你正在做 TUN 相关配置，可对照《Clash TUN 模式详解》中的 DNS 小节，确认虚拟网卡与 DNS 劫持是否同时生效。

另一方面，规则分流与 DNS 是一体两面：域名规则依赖「域名如何被解析、映射到哪条策略」。若你尚未建立国内外分流的基础，可先阅读《Clash 规则分流配置详解》，再回头微调 DNS，会更容易判断「是解析问题还是规则顺序问题」。

可复现的自检步骤（建议按顺序做）

下列步骤用于在不依赖玄学点击的前提下，把问题缩小到「系统 DNS / Clash DNS / 规则」三类之一：

  1. 确认 Clash 已接管 DNS：在客户端内开启「显示详细日志」或等价选项，访问一个纯域名站点，观察是否出现对应该域名的 DNS 查询或解析记录。若完全没有 DNS 相关日志，说明流量仍绕开了内核 DNS 路径。
  2. 用浏览器测 DNS 泄漏：在开启代理的状态下，使用公开的 DNS leak 测试工具（注意选择 HTTPS 页面），记录显示的解析服务器归属。若仍大量出现本地运营商，优先检查系统网卡 DNS、路由器 DHCP 是否强制覆盖，以及 TUN 是否未启用。
  3. 对照 Fake-IP 预期现象：在 fake-ip 下，用系统自带工具对常见域名执行解析，可能看到保留段地址，这本身不等于泄漏；关键仍是「连接建立时是否按规则走了正确出口」，以 Clash 连接日志为准。
  4. 收窄变量：一次只改一项：例如先固定 nameserver 与 fallback，再切换 enhanced-mode；或先关 TUN 验证系统代理场景，再开 TUN 对比。
⚠️
关于 WebRTC 与浏览器插件：部分「泄漏」来自浏览器或插件的独立通道，与 Clash DNS 段无关。若测速站显示异常，可换用干净浏览器配置或暂时禁用扩展交叉验证。

常见误区与排错顺序

很多用户一看到测速网站显示「本机 DNS」，就立刻把订阅里所有 DNS 改成境外公共 DNS，结果反而触发更高延迟或触发服务商的速率限制。更稳妥的做法是：先确认 Clash 是否真正接管查询，再调整上游列表与 fallback 条件。

另一个常见误区是把「Fake-IP 返回的假地址」当成「节点 IP」，从而误判规则未生效。若你使用域名规则或 Sniffer，请以 Clash 内核日志中的连接与策略命中为准，而不是简单 traceroute 到假地址。

若你希望从安装到订阅、再到文档化流程一步步走通，也可先跟随全平台安装与配置教程建立基线，再回头做 DNS 专项微调，排错成本会低很多。

写在最后

把 DNS 配稳，本质是让「解析—匹配规则—出站」形成闭环，而不是单纯堆境外 DNS。Fake-IP、nameserver 与 fallback 的协作，正是 Clash Meta（Mihomo）在处理污染与分流时的核心杠杆之一。当你能按日志复现问题、按步骤逐项验证时，所谓 DNS 泄漏也会从「玄学」变成可定位的工程问题。

若你还没有安装适配系统的客户端，建议先到客户端下载页获取当前维护良好的发行版，再结合订阅与本文步骤完成配置。相比零散搜索过时片段，使用一体化工具链能显著减少无效尝试。→ 立即免费下载 Clash，开启流畅上网新体验。