Clash DNS 配置详解:nameserver、fallback 与劫持参数怎么填

先理清 Clash DNS 的处理链路

Clash 的 DNS 模块不是简单地把系统查询转发给某一个公共 DNS。启用后，它会监听本地端口、读取配置中的上游服务器，并根据域名、规则和返回地址决定采用哪一个结果。开启 TUN 与 DNS 劫持后，原本发往路由器或公共 DNS 的 53 端口请求也能被导入这条链路。

一次常见查询可以拆成四步：应用询问某个域名的地址；系统把请求交给 Clash；Clash 向 nameserver、匹配到的策略服务器或 fallback 发起查询；最后根据 fallback-filter 与增强模式返回真实地址或 Fake IP。网页能否打开、域名规则能否命中、代理节点域名能否解析，都可能受这些步骤影响。

一份可读的基础配置

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

这里的 listen 使用 127.0.0.1:1053，表示只在本机回环地址监听 UDP/TCP 1053 端口。1053 是常见的非特权 DNS 监听端口，避免与系统已有的 53 端口服务冲突。若客户端已经自动管理监听地址，不应在订阅文件中重复加入另一套冲突配置。

nameserver、default-nameserver 与 fallback 分别负责什么

nameserver：默认的业务域名解析入口

nameserver 是大多数域名查询的主要上游。它可以填写普通 UDP DNS，也可以在兼容的 mihomo 内核中使用 DoH、DoT 等格式。家庭网络追求低延迟时，可选择距离较近且响应稳定的服务器；需要加密传输时，可以使用 HTTPS DNS 地址。

nameserver:
  - 223.5.5.5
  - 119.29.29.29
  - https://dns.alidns.com/dns-query

同一列表放入多个服务器，不代表每次都严格从第一项开始等待。具体并发和结果选择行为由内核实现决定，因此不宜把四五个响应特征差异很大的服务器堆在一起。实际配置中保留 2 至 3 个稳定上游更容易定位问题。

default-nameserver：先解决 DNS 服务器自己的域名

当 nameserver 使用 https://dns.alidns.com/dns-query 这类带主机名的 DoH 地址时，内核必须先知道 dns.alidns.com 的 IP，才能建立 HTTPS 连接。default-nameserver 主要承担这类引导解析，也称 bootstrap DNS。

default-nameserver:
  - 223.5.5.5
  - 1.1.1.1

为了避免“解析 DNS 服务器还要先访问 DNS 服务器”的循环依赖，这里优先填写直接可访问的 IP 地址。若日志连续出现 lookup dns server failed、context deadline exceeded，应先检查这一组地址是否能在当前网络中访问，而不是直接增加更多 DoH 地址。

fallback：另一组并行候选答案

fallback 常用于提供与主要上游不同的解析视角。启用后，Clash 会结合过滤条件决定采用 nameserver 结果还是 fallback 结果。它并非只在 nameserver 超时后才启动，所以加入过多远距离 DoH 服务可能增加连接和资源开销。

如果网络环境中的主要 DNS 已经稳定，而且使用 Fake IP 模式配合完整规则集，未必一定要配置 fallback。先把简单配置跑通，再根据解析污染、地区结果错误或特定域名异常增加候选链路，通常比复制一大段旧模板更可靠。

fallback-filter 如何选择最终答案

fallback-filter 的作用是判断主要结果是否需要被替换。常见条件包括 GeoIP 国家代码、特定网段和域名列表。不同内核版本对扩展字段的支持可能不同，使用 mihomo 时应以当前内核文档与启动日志为准。

geoip 与 geoip-code

fallback-filter:
  geoip: true
  geoip-code: CN

这组配置会结合 GeoIP 数据判断返回地址的地理归属。典型用途是：主要上游返回符合本地区域预期的地址时采用该结果；返回地址不符合过滤条件时，转而考虑 fallback 的结果。判断质量取决于客户端使用的 GeoIP 数据是否及时更新，不能把国家代码理解成绝对准确的线路测速。

ipcidr：拦截明显异常的地址段

fallback-filter:
  geoip: true
  geoip-code: CN
  ipcidr:
    - 0.0.0.0/32
    - 127.0.0.0/8
    - 240.0.0.0/4

ipcidr 可以标记不希望被普通公网域名返回的地址范围。例如公网网站解析到 127.0.0.1 通常不合理。不过，公司内网、家庭服务器和实验网络可能确实使用私有地址，不能不加区分地屏蔽所有 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。

domain：对指定域名优先考虑 fallback

fallback-filter:
  geoip: true
  geoip-code: CN
  domain:
    - '+.example.net'
    - '+.example.org'

域名列表适合处理少量、可复现的异常站点。+.example.net 这类写法表示匹配该域名及其子域，实际语法需与所用内核版本兼容。列表不应无限增长；如果数百个域名都需要手工指定，通常说明主要上游、规则集或网络出口的选择需要重新检查。

fake-ip 与 redir-host 应该选哪一个

enhanced-mode 决定 Clash 把什么答案交给应用。常见值是 fake-ip 与 redir-host。两者都能配合代理转发，但域名保留方式、兼容性与诊断方法不同。

fake-ip：先返回保留地址，再在内核中映射域名

enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16

Fake IP 模式会从保留地址池返回一个临时地址，例如 198.18.0.23。应用随后连接这个地址，Clash 根据内部映射找回原始域名，再执行域名规则和代理策略。它减少了等待真实 DNS 结果后再建立连接的步骤，也让只看到目标 IP 的流量更容易还原为域名。

198.18.0.0/15 是基准测试用途的保留网段，常被代理内核用作 Fake IP 地址池。若局域网、企业 VPN 或实验环境已经使用相同网段，应改用内核允许且不冲突的范围。看到 ping 返回 198.18 开头的地址并不代表域名解析错误，关键要看请求是否由 Clash 接管。

fake-ip-filter：让特殊域名返回真实地址

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

局域网设备发现、打印机、部分游戏联机、STUN、时间同步和需要读取真实地址的应用，可能不适合 Fake IP。此时可加入 fake-ip-filter。过滤项应从实际故障出发逐条添加，并在修改后清理系统 DNS 缓存；直接复制过长列表会让大量域名绕开 Fake IP，削弱域名映射效果。

redir-host：返回真实 IP，兼容性更直观

enhanced-mode: redir-host

redir-host 会向应用返回真实解析地址。它适合与 Fake IP 冲突且难以逐项过滤的旧软件或特殊局域网环境，但域名规则是否能稳定命中更依赖嗅探、连接元数据与具体接管方式。排查时可以临时从 fake-ip 切换到 redir-host：若问题立即消失，重点检查 Fake IP 地址池冲突和过滤列表。

TUN 模式下为什么还需要 DNS 劫持

只把系统 DNS 设置成 127.0.0.1:1053，并不能保证所有程序都照做。有些应用会直接向 8.8.8.8:53 发送 UDP 请求，有些设备使用路由器下发的 DNS。TUN 模式负责接管 IP 流量，而 DNS 劫持进一步把匹配的 53 端口请求交给 Clash DNS 模块处理。

mihomo 配置中常见的 TUN 片段如下。字段支持情况会随内核与客户端封装方式变化，图形客户端自动生成 TUN 配置时，应优先在界面开关中操作，避免界面配置和订阅 YAML 相互覆盖。

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

• enable 开启 TUN 接管。
• stack: mixed 使用内核支持的混合网络栈实现。
• auto-route 自动写入所需路由。
• auto-detect-interface 尝试识别当前出口网卡。
• any:53 匹配被接管流量中的常规 53 端口 DNS 请求。

DNS 劫持主要覆盖传统 UDP/TCP 53 端口。应用内置的 DoH 使用 HTTPS 443 端口，从网络层看与普通 HTTPS 类似，不能仅依靠 dns-hijack 一概改写。若浏览器启用了“安全 DNS”，排查时可暂时关闭该功能，确认请求究竟由浏览器还是 Clash 解析。

一套适合日常使用的 mihomo 配置思路

日常桌面和手机环境可以从“本地上游负责常见解析、加密候选负责异常结果、Fake IP 负责域名映射、TUN 劫持传统 DNS”这条路线开始。下面的示例强调结构关系，不代表所有网络都应使用相同服务器。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  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://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8
      - 240.0.0.0/4
  fake-ip-filter:
    - '*.lan'
    - localhost
    - '+.stun.*.*'
    - '+.stun.*.*.*'

如果本地网络没有 IPv6 出口，将 ipv6 设为 false 可避免应用拿到 AAAA 记录后尝试一条不可达路径。若网络具备稳定的原生 IPv6，并且代理节点与规则也正确处理 IPv6，则可以启用；不能只看运营商是否分配了 IPv6 地址，还要测试默认路由、DNS 返回和代理出口是否完整。

mihomo 还提供 nameserver-policy、proxy-server-nameserver、direct-nameserver 等扩展字段，可分别为特定域名、代理节点域名和直连请求指定解析器。这些字段适合已经明确区分解析路径的配置。基础配置尚未跑通时一次加入全部高级字段，容易形成循环解析或让节点域名走错出口。

代理节点是域名时要额外留意

订阅中的服务器地址可能是 node.example.com，内核必须先解析它，代理连接才能建立。如果解析该域名的 DNS 又被配置为必须通过尚未建立的代理访问，就会形成“需要代理才能解析节点、需要节点才能建立代理”的循环。mihomo 可通过 proxy-server-nameserver 为节点域名单独指定可直连的解析器。

proxy-server-nameserver:
  - 223.5.5.5
  - https://dns.alidns.com/dns-query

DNS 异常的逐步排查方法

第一步：确认配置已经被内核加载

1. 保存 YAML 后执行客户端的“重新加载配置”，不要只关闭编辑器。
2. 打开内核日志，搜索 DNS、listen、timeout 与 parse。
3. 若出现 YAML 缩进错误，检查 dns: 下是否统一使用空格缩进，列表项前是否保留连字符。
4. 确认当前选中的订阅没有在自动更新后覆盖本地修改。

YAML 对缩进敏感。下面这种把 fallback 意外缩进到 nameserver 列表中的写法无法表达预期结构。建议每级使用 2 个空格，不使用 Tab。

第二步：直接查询 Clash 的监听端口

Windows 可在 PowerShell 或命令提示符中使用 nslookup，macOS 与 Linux 可使用 dig。把查询目标指向监听地址，可以区分“Clash DNS 本身失败”与“系统没有把请求交给 Clash”两类问题。

nslookup example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

nslookup 通常默认访问 53 端口，若 Clash 只监听 1053，应使用支持指定端口的工具，或由客户端把系统 53 端口请求转交到 1053。Fake IP 模式下得到 198.18.x.x 属于预期现象；若持续超时，则检查端口占用、防火墙和上游可达性。

第三步：测量上游响应，不只看是否能解析

一次成功回复不代表链路稳定。可连续查询 20 次，观察是否出现间歇性超时。局域网内普通 DNS 常见响应约为 5 至 30 毫秒；跨区域 DoH 可能达到 80 至 250 毫秒。具体数值受接入网络影响，重点是超时率和波动，而不是追求单次最低值。

• 只有 DoH 超时：检查系统时间、TLS 连接和 DoH 域名的引导解析。
• 普通 UDP DNS 与 DoH 都超时：检查当前网络、默认路由和防火墙。
• 查询成功但网页打不开：继续检查代理规则、节点连接和 TUN 路由。
• 切换 redir-host 后恢复：检查 Fake IP 网段冲突与过滤项。
• 仅局域网域名失败：为内网域名设置专用解析策略，或加入必要的 Fake IP 过滤。

第四步：清理旧缓存再复测

修改上游或增强模式后，系统、浏览器和 Clash 都可能保留旧答案。Windows 可执行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches；浏览器还可能维护独立的主机缓存。完成清理后重新加载配置，再用同一个域名复测，避免把旧记录误认为新配置结果。

填写这些字段时的最终检查清单

• enable 已开启，监听端口没有与本机其他 DNS 服务冲突。
• default-nameserver 能在代理尚未建立时直接访问。
• nameserver 保留 2 至 3 个稳定上游，不堆叠大量重复服务。
• fallback 用于提供不同解析视角，而不是机械充当超时后的备用项。
• fallback-filter 的 GeoIP、网段和域名条件符合当前网络环境。
• fake-ip-range 不与企业 VPN、家庭局域网或实验网段冲突。
• fake-ip-filter 只添加确实需要真实地址的域名。
• TUN 模式已启用时，确认 dns-hijack 与客户端自动配置没有重复冲突。
• 代理节点使用域名时，检查节点域名的引导解析不会依赖尚未建立的代理。
• 每次修改只调整一组字段，并记录修改前后的查询结果与日志。

Clash DNS 配置的重点不是寻找一段适用于所有网络的固定模板，而是把解析入口、候选结果、过滤条件、增强模式和流量接管连接成可验证的链路。先用最少字段确认查询可达，再逐步加入 Fake IP、fallback 与 TUN 劫持，出现问题时就能准确定位到具体环节。