为什么要把 dns 段写在前排，而不是只看日志

代理软件里，域名解析往往比「选哪个节点」更早决定命运：解析走了运营商、或拿到了「只能直连」的地址，后面规则再漂亮也可能白搭。Clash Meta 把解析逻辑集中在顶层的 dns: 配置块里，和 rules、proxy-groups 并列，本意就是让你主动设计解析路径，而不是永远被动等连接失败再翻日志。

本文默认你使用 Clash Meta / mihomo 系内核（社区常混称二者）。字段名以你当前内核版本文档为准；下列示例侧重结构正确与意图清晰，便于你在订阅模板之上增量修改。需要规则与 Rule Provider 的配合方式时，可对照 规则分流最佳实践。

第一步：dns.enable 与监听地址

打开 DNS 模块的开关是 dns.enable: true。若此处为 false，后面所有 nameserver、fallback 都不会参与，系统仍会按操作系统默认解析器去问上游，你看到的「DNS 相关异常」往往会变得难以归因。

listen 决定内核是否在本地提供 DNS 服务（常见如 '0.0.0.0:1053' 或仅本机端口）。是否要把系统或路由器的 DNS 指过来，取决于客户端是否已帮你做了「重定向 / 劫持」；在 TUN 场景下，更常见的是配合 tun.dns-hijack 把 53 端口的查询拉进内核。TUN 栈与劫持细节可参考 TUN 模式深入解析。

YAML — minimal dns skeleton 
dns:
  enable: true
  ipv6: false
  listen: '0.0.0.0:1053'
  use-hosts: true
ℹ ipv6: 若你的网络或节点对 IPv6 支持不完整，可先显式 false，避免解析与路由在双栈上「一半成功一半超时」。稳定后再按需打开。

default-nameserver 与 nameserver 的分工

这是新手最容易混淆的一对字段。default-nameserver 用来解析「那些写在 nameserver 里、本身是域名形式的 DoH / DoT 服务器主机名」。例如你把 https://dns.google/dns-query 写进 nameserver，内核要先知道 dns.google 解析成什么 IP，这一步就会走 default-nameserver——通常填延迟低、可达性好的明文 UDP/TCP DNS（如运营商或国内公共 DNS），避免「用 DoH 解析 DoH 域名」的鸡生蛋问题。

nameserver 则是日常查询的主解析器列表：对绝大多数域名，内核会按策略从中选取或并行尝试（具体行为随版本略有差异，以文档为准）。常见写法是国内外分流：国内域名走国内 DoH，其余走加密 DNS；也可以先全走一组，再用 fallback 补救失败场景。

YAML — default-nameserver + nameserver 
dns:
  enable: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 'https://doh.pub/dns-query'
    - 'https://dns.alidns.com/dns-query'

DNS fallback 链与 fallback-filter

fallback 不是策略组里的主备切换，而是解析失败或结果被判定不可信时的备用 DNS 列表。典型用途是：主 nameserver 对海外域名返回污染结果、超时或被劫持时，换一组更「干净」的解析路径再试。

fallback-filter 决定「什么时候该认为主解析结果不够好、应尝试 fallback」。常见条件包括 geoip（例如命中指定国家/地区代码）、ipcidr（命中保留地址段）、以及部分版本支持的域名类条件等。把它理解成对解析结果的验收规则，比死记字段名更有效。

YAML — fallback with geoip filter (illustrative) 
dns:
  nameserver:
    - 'https://doh.pub/dns-query'
  fallback:
    - 'tls://8.8.8.8:853'
    - 'tls://1.1.1.1:853'
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
⚠ 与 proxy-groups 的 type: fallback 区分：后者管的是代理出口谁先谁后；DNS fallback 管的是解析服务器。改其中一个不会自动修复另一个层面的问题。更完整的对比见 策略组 url-test 与 fallback。

enhanced-mode：Fake-IP 与 redir-host 怎么选

enhanced-mode: fake-ip 时，内核常对匹配规则的域名先返回一段虚拟地址（由 fake-ip-range 指定），等真正发起连接时再解析真实 IP。优点是规则匹配更顺滑、减少重复解析；代价是你必须理解 Fake-IP 与直连局域网、部分国产应用之间的摩擦点。

enhanced-mode: redir-host（或类似模式名，视版本而定）更偏向「尽快拿到真实 IP」，调试直观，但在复杂规则集下可能增加解析次数与日志噪音。选型没有绝对正确：追求透明代理与游戏 UDP 体验的用户可能更常开 TUN；仅系统代理时也要看应用是否尊重系统 DNS。

fake-ip-range 与 fake-ip-filter 实配要点

fake-ip-range 默认常用 198.18.0.1/16 一段私有语义地址，避免与局域网网段冲突；若与你本地虚拟网段撞车，应改成不重叠的区间。

fake-ip-filter 列出不要走 Fake-IP、应返回真实解析结果的域名或后缀。典型必写项包括：*.lan、路由器管理域名、内网主机名、部分依赖真实 IP 做就近调度的国内服务。漏写时常见现象是：NAS、打印机、局域网发现协议异常，或某些登录域在 Fake-IP 下反复失败。更贴近局域网与路由器场景的排障思路，可延伸阅读 Fake-IP 与局域网 / 路由器。

YAML — fake-ip + filter excerpt 
dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'

列表可随你本地设备与服务逐步扩充；原则是「需要真实 IP 才能工作的名字」进过滤，「交给代理做域名嗅探与规则即可的名字」可不必写。

TUN 模式：dns-hijack 与系统解析路径

仅有 dns: 段并不能自动让所有进程使用内核解析；系统里仍可能有应用绕过本地 DNS、直接把查询发给路由器或运营商。开启 TUN 并在 tun 块中配置 dns-hijack（例如劫持 any:53）的目的，是把 UDP/TCP 的 53 查询拉进 Clash，由 dns 模块统一处理，从路径上压缩 DNS 泄漏窗口。

实际部署时还要对照：操作系统「加密 DNS / 私人 DNS」开关、浏览器 DoH 独立设置、以及是否与其他 VPN 类软件争用虚拟网卡。任何一层把查询送出代理隧道外，都可能形成「你以为走了 Clash，其实解析仍在外面」的错觉。

DNS 泄漏自检清单（含规则侧配合）

  1. 确认 dns.enable 为 true，且客户端未加载一份空 dns 的运行时覆盖。
  2. TUN 用户核对 dns-hijack 是否覆盖你关心的查询路径；必要时关闭系统或浏览器自带 DoH 做对照实验。
  3. 规则是否把应代理的域名送进正确策略组；解析正确但规则走错，仍会表现为「像 DNS 坏了」。可复习 规则分流最佳实践。
  4. 使用公开泄漏检测站点做 A/B：仅开系统代理、仅开 TUN、以及二者切换时对比结果；记录差异比单次截图更有价值。
  5. 核对 fake-ip-filter 是否遗漏局域网与登录相关域名，避免把「应用特性」误判为「节点挂了」。

一份可直接改写的完整 dns: 示例

下面将前文字段串成一整段，便于你复制后按本地网络替换 DoH 地址与过滤列表。若订阅模板自带 dns，建议合并而非重复键：YAML 中重复顶层键后者覆盖前者，极易产生「我明明写了却不生效」的错觉。

YAML — full dns block template for Clash Meta 
dns:
  enable: true
  ipv6: false
  listen: '0.0.0.0:1053'
  use-hosts: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 'https://doh.pub/dns-query'
    - 'https://dns.alidns.com/dns-query'
  fallback:
    - 'tls://8.8.8.8:853'
    - 'tls://1.1.1.1:853'
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

与之配套的 TUN 片段（示意）常见写法如下，具体键名请以你所用的 Meta 版本文档为准：

YAML — tun dns-hijack excerpt 
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - 'any:53'

常见坑与排障顺序

建议排障顺序：先看 dns.enable 与是否只有一段 dns: → 再看 default-nameserver 与主 nameserver 是否可达 → 然后检查 fallback 与 fallback-filter 是否匹配你的网络环境 → 最后处理 Fake-IP 过滤与 TUN 劫持。握手与超时类日志解读可结合 连接日志与 TLS 排障。

结语

Clash Meta DNS 配置的本质，是把「谁负责解析、何时换备用解析、Fake-IP 下哪些名字必须求真、TUN 是否劫持 53」四件事写清楚。把它们一次性配对比反复改节点更能稳定体验；与 Mihomo dns 文档对照时，重点核对版本差异即可。

相比只在故障时翻日志，主动维护一小段 dns 与合理的 fake-ip-filter，能同时减少 DNS 泄漏与「莫名其妙连不上」的玄学时间。更多通用问题见 常见问题；客户端选型可参考 如何选择适合自己的 Clash 客户端。

图形界面若能把 dns、TUN 与规则编辑放在同一视线里，长期维护成本会更低；相比零散复制片段，理解上述链条后你可以自行判断该改解析还是改规则。

→ 立即免费下载 Clash，开启流畅上网新体验，在客户端中对照本文逐项核对 DNS 与 TUN 设置。