网络配置 精选 标签： DNS nameserver Clash

Clash DNS 仍解析慢或污染？nameserver 与 fallback 分步设置

许多用户已经打开 Clash，规则与节点看似正常，却仍会感到网页首包慢、个别域名解析到奇怪地址，或同一站点在国内外地网络下解析结果不一致。这类问题往往不在「换一个节点」本身，而在 DNS 段：主上游 nameserver、回退 fallback、过滤条件 fallback-filter，以及走直连与走代理时的解析出口是否一致。下文按可操作的 YAML 顺序分层修改，并说明如何与 fake-ip、分规则协同，最后用简单方法自测。

约 22 分钟阅读
Clash 编辑部
文章目录

一、先分清：慢、污染与「走错线路」

解析慢常见原因是：主上游 RTT 高、DoH 握手多、IPv6 探测超时、或本机到 DNS 的路径被 QoS。表现是整站普遍「等 DNS」而不是只有几个域异常。

DNS 污染在用户体验上往往是：知名国际站解析到明显不属于该服务的网段、或反复变化；有时是运营商或中间设备对 UDP/53、特定 DoH 主机名做劫持与伪造应答。此时单靠换浏览器无效，需要换可信任的上游或让 Clash 的 fallback 在判定「应答可疑」时换一条路径再问。

国内外解析「走错线路」更多与分域 DNS有关：把境内后缀无条件丢到境外 DoH，可能拿到对大陆用户次优的 CDN；反过来，只用国内递归解析境外站，又可能碰到污染或陈旧缓存。典型的修法是 nameserver-policy：境内域名优先走境内友好上游，其余再走你信任的「国际」加密 DNS。

若你同时遇到「浏览器泄漏真实 IP」与「解析异常」混在一起，可先浏览 WebRTC 与 DNS 泄露排查，把「泄漏」与「错误解析」分成两条线，避免改 DNS 时误判规则没生效。

二、Clash（Mihomo）里几条 DNS 链路分别干什么

在 Mihomo / Clash Meta 系配置中，dns: 下常见字段可以这样理解（具体键名以你使用的内核版本文档为准，合并订阅时不要重复整个 dns: 块）：

  • default-nameserver：用来解析其它 DNS 服务器自己的域名（例如 DoH 的 URL 主机名）。若这一步失败，后面的加密上游都连不上，表现为「偶发全员解析失败」。
  • nameserver：主解析池。大多数查询先来这里；应选在你当前网络下稳定、延迟可接受的条目。
  • fallback：回退池。当主池结果被 fallback-filter 判为可疑（例如疑似污染、不符 GeoIP 期望）时，再向这里请求，用来「纠偏」。
  • nameserver-policy：按域名模式指定专用上游，是做「境内/境外分流解析」的核心工具。
  • proxy-server-nameserver（或你所用内核中的等价项）：当某次查询被设计为经由代理出口完成时，使用哪一套 DNS。缺省或与直连混用，容易出现「规则上说走代理，解析却在本地运营商侧完成」的错位。
小贴士：改 DNS 时一次只动一层：先保证 default-nameserver 与主 nameserver 可用，再开 fallback-filter，最后加 nameserver-policy，否则日志里很难看出是哪一段在失败。

三、分步一：default-nameserver 与上游可达

第一步不是抄一份「全网最佳 DNS 列表」，而是确认 bootstrap 能工作。选一两个不被加密封装依赖的稳定地址放进 default-nameserver（常见写法是运营商或公共的 UDP/TCP 53，视环境而定），用来解析你配置里 DoH/DoT 的域名。

若你在公司网、校园网或「仅 IPv4」环境，留意 DoH 的 TLS 是否被中间人干扰；可把一组 UDP 上游留在 default-nameserver 作为兜底。修完这一层后，再观察间歇性「整网解析超时」是否消失。

四、分步二：主 nameserver 怎么摆

nameserver 建议遵循少而稳：两条高质量上游往往比十条互相引用更清晰。对大陆用户常见策略是：主池里保留本地可达、延迟低的递归或知名公共解析；若你主要访问境外站，可再增加一条 DoH，但注意不要把延迟极高或握手很重的选项放在第一位，否则所有域都会被首包拖慢。

若你启用了 IPv6 而家中光猫或路由对双栈支持不佳，偶尔需要在 DNS 或内核侧限制 AAAA 行为或关闭不必要的双栈探测，以免「等 AAAA 超时」拉低体验。可与 IPv6 相关排障文章对照（本站已有境内站变慢与接口绑定类选题）。

dns:
  enable: true
  ipv6: false
  # Prefer kernel docs for exact keys (listen, enhanced-mode, etc.)
  default-nameserver:
    - system
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
    - tls://dns.pub:853

上表仅为结构示意；请按你的网络实测替换为可达、合规的上游，并与订阅合并策略协调，避免重复 dns.enable 冲突。

五、分步三：fallback 与 fallback-filter

fallback 不是「第二个 nameserver 并列解析」那么简单；它服务的场景是：主池给出的结果可能不可信。典型配置会选用境外或加密路径更「干净」的 DoH/TLS，与主池地理属性区分开，便于过滤逻辑触发二次查询。

fallback-filter 中常见的判断维度包括 GeoIP 国家、IP 类型、域名列表等。模板上若复制了过于激进的 geoip 与 ipcidr 规则，会导致_fallback 频繁误触发或不触发：要么解析变慢，要么污染仍在。建议先使用官方示例级别的配置理解每一行语义，再按本地实测收紧或放宽。

  fallback:
    - https://cloudflare-dns.com/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
注意：fallback-filter 配错可能比不配更糟：会出现只对少数域生效、其它域仍然吃污染。每次改动后用下文验证段对照一两个敏感测试域。

六、分步四：nameserver-policy 分域

当你明确希望「+.cn 与国内常用后缀走境内递归、境外站走加密国际上游」时，应使用 nameserver-policy 显式声明，而不是只靠全局 nameserver。这能缓解「淘宝、网银慢却 YouTube 正常」或相反的情况——本质是解析路径与规则期望的地理不一致。

写法上可使用域名后缀、规则集引用（若你的内核版本支持）、或通配。合并多份订阅时，注意后加载文件是否覆盖了你手工维护的 nameserver-policy；必要时把稳定策略放到不被覆盖的 include 文件中。

  nameserver-policy:
    "+.cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-cn":
      - tls://dns.pub:853

若你使用 GeoIP 中国大陆与 DIRECT 分流 将大量流量标成直连，与之匹配的是：直连目标的 DNS 也应拿到对该目标合理的地址，否则会出现握手到「看起来很近」的 IP 却仍绕远路的错觉。

七、直连与代理 DNS：proxy-server-nameserver

规则将流量交给节点后，部分实现仍会先在本机完成一次 DNS；若这次解析走了本地运营商，而连接却从境外出口发出，CDN 可能把边节点选在错误地理区域，表现为流媒体卡顿、跨境 API 延迟异常。为避免这类解析与出口脱节，应配置「走代理时使用的 DNS」字段（常见键名为 proxy-server-nameserver，请以文档为准）。

实践中可以简记：直连域名尽量用 nameserver-policy 落在可信直连上游；明确要走代理的域名，让解析行为与代理隧道语义一致。这与「系统网卡 DNS 仍指向路由器」并不矛盾——Clash 接管 DNS 后，关键是内核收到了哪一套应答、与规则选路是否一致。

WSL、Docker 或子网内的解析转发若与宿主机 Clash 不一致，可结合 WSL2 与 Windows Clash 的 DNS 排查 一步理顺，避免「宿主机浏览器正常、子系统总解析到旧地址」。

八、与 fake-ip、系统 DNS 叠加时的检查点

fake-ip 模式会改变「应用第一次看到的解析结果」，许多问题看起来像 DNS 污染，实际是 fake-ip-filter 漏项或与嗅探、TLS 叠加。请先阅读 fake-ip 与 fake-ip-filter 排障，再回头调整本章 nameserver / fallback，否则容易在两个方向上来回改配置却不见效。

在 fake-ip 开启时，仍要关注：谁负责最终真实解析（连接建立阶段）、直连域名是否拿到了真实地址（filter 与 policy 是否覆盖），以及 TUN / 系统代理 是否让应用绕过了 Clash DNS。若仅关闭 fake-ip 后污染立即消失，多半是上游与 filter/policy 的组合问题，而不是节点本身。

九、验证：日志、命令与对照表

改完 YAML 后按顺序做：重载配置 → 清 DNS 缓存（系统及浏览器）→ 在客户端连接日志中观察域名解析阶段。对照实验应固定同一节点与同一规则集，只改 DNS 段。

在终端可用 dig 或 nslookup 指向 Clash 监听的 DNS 地址（若你显式配置了 listen），对比直连运营商与经 Clash 的结果差异。若只有经 Clash 才异常，则问题锁定在 Clash DNS 配置；若两者一致都异常，则先查网络环境或上游。

现象 优先核对
全局首屏慢 nameserver 顺序、DoH 可达性、IPv6 与双栈超时
仅境外名站 IP 怪异 fallback 是否触发、fallback-filter 是否过严或过松
境内站慢、境外正常 nameserver-policy 是否缺 +.cn 等；是否与 GeoIP 直连规则打架
规则走代理却 CDN 很差 proxy-server-nameserver（或等价项）是否与出口地理一致

需要核对 YAML 字段含义与合并冲突时，可先打开 本站配置文档，再对照内核发行说明；生产环境务必在改动的每步保留可回滚备份。

十、小结

Clash 开着的用户若仍被 DNS 解析慢、污染与分域错乱困扰，优先不要在节点列表上盲目试错，而应把 default-nameserver、nameserver、fallback / fallback-filter、nameserver-policy 与代理侧 DNS按顺序理顺：先保证上游可达，再让回退池承担「纠偏」，最后用策略把境内外解析路径分开，并核对 fake-ip 与系统接管的边界。

相比零散搜索片段，把每一次异常域名记入表格（现象、期望线路、实际解析、当日 DNS 改动）会大幅提升排障效率；与 fake-ip、WSL、WebRTC 等专题文交叉阅读，也能避免把多种问题混成一条线。

相比其他同类工具，Clash 系列在 DNS 与规则协同上可配置项丰富，掌握 nameserver 与 fallback 的分工后，日常浏览与开发工具的稳定性通常会明显提升。

→ 立即免费下载 Clash，开启流畅上网新体验