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

Clash DNS 实际处理了什么

访问网站时，应用通常先把域名交给系统 DNS，再使用返回的 IP 建立连接。若系统提前完成解析，Clash 可能只看到目标 IP，域名规则、GeoSite 规则和需要嗅探才能恢复的域名信息就可能失去作用。启用 Clash 内置 DNS 后，解析请求可以由同一套代理内核处理，域名、规则匹配和出站选择之间的关系更清楚。

DNS 配置不是简单地填写一个公共服务器。一次查询可能涉及启动解析器、常规解析器、代理节点域名解析器、备用解析器、域名策略以及 TUN 劫持。不同字段负责不同阶段，重复填写并不会自动提高可靠性，反而可能造成循环解析或结果不一致。

一次查询的主要路径

浏览器或应用请求解析域名，例如 www.example.com。
系统 DNS、TUN 劫持或手动指定的本地端口把查询交给 Clash。
内核先检查缓存、hosts、fake-ip-filter 与 nameserver-policy。
未命中特定策略时，查询交给 nameserver；启用 fallback 时还会结合 fallback-filter 判断结果。
内核返回真实 IP，或在 Fake-IP 模式下返回 198.18.0.0/16 范围内的映射地址。
应用发起连接，Clash 再按域名规则、IP 规则和代理组决定出站。

nameserver、default-nameserver 与 proxy-server-nameserver

nameserver:常规域名解析入口

dns.nameserver 是默认解析器列表。没有命中 nameserver-policy，且不需要 fallback 接管时，普通域名会交给这里的服务器。它可以使用传统 UDP DNS，也可以使用 DoH、DoT 等加密协议。UDP DNS 写法通常是 IP 地址，默认端口为 53；DoH 使用完整 HTTPS 地址；DoT 通常使用 tls://主机名:853。

dns:
  enable: true
  listen: 127.0.0.1:1053
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

同一列表中可以放多个服务器，但“多个”不等于严格按顺序故障转移。不同内核版本可能并发查询并采用先返回或符合条件的结果。若希望国内域名和其他域名固定走不同解析器，应使用 nameserver-policy，而不是依赖列表顺序。

default-nameserver:解析 DNS 服务器自己的域名

当 nameserver 写成 https://dns.alidns.com/dns-query 时，内核必须先知道 dns.alidns.com 的 IP，才能建立 HTTPS 连接。default-nameserver 就负责这个启动阶段，也常被称为 bootstrap DNS。这里优先填写可直接访问的 IP 形式解析器，避免“先解析解析器域名”的循环依赖。

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

default-nameserver 不是所有网站的强制解析出口。正常启动后，业务域名仍由 nameserver、fallback 或 nameserver-policy 处理。它产生的查询次数通常很少，但网络切换、缓存到期或解析器连接重建时会再次使用。

proxy-server-nameserver:专门解析节点域名

代理节点地址可能不是固定 IP，而是 node.example.net 这类域名。若解析节点域名也依赖尚未连接成功的代理，就会形成循环：连接代理前需要解析节点，解析节点又要求先连接代理。mihomo 提供 proxy-server-nameserver，用于把节点服务器域名交给可直连访问的 DNS。

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

节点域名解析失败时，日志里常见 lookup、no such host、i/o timeout 等信息。此时即使普通网页域名能够解析，代理节点仍可能全部显示超时。排查时应分别检查 nameserver 和 proxy-server-nameserver，不能只用浏览器能否打开网页来判断。

fallback 与 fallback-filter 怎么配

fallback 是备用解析器组，常见用途是把不同网络路径上的 DNS 结果进行筛选。它不是“nameserver 超时后才查询”的简单后备列表。经典 Clash 方案经常并行查询 nameserver 与 fallback，再由 fallback-filter 判断是否采用备用结果。mihomo 保留了兼容写法，但更精确的域名分流通常适合改用 nameserver-policy。

fallback-filter 的四类条件

geoip：启用基于 IP 地理数据库的结果判断。
geoip-code：指定参考地区代码，例如 CN。这一逻辑依赖本地 GeoIP 数据是否及时更新。
ipcidr：当主解析结果落入指定网段时，按过滤逻辑选择 fallback 结果，常用于排除明显异常地址段。
domain：指定域名直接使用 fallback 侧结果，支持域名后缀写法。

dns:
  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
    domain:
      - +.google.com
      - +.githubusercontent.com

这类配置更适合需要区分本地解析与另一组解析结果的网络环境。它并不适用于所有地区。若设备不在中国大陆网络，仍把 geoip-code 固定为 CN，筛选逻辑可能与实际接入位置不一致。对于长期移动、跨地区使用的设备，按域名明确指定解析器通常更容易维护。

nameserver-policy 精确指定域名解析器

mihomo 的 nameserver-policy 可以根据域名匹配结果指定 DNS。它比“主解析器加地理位置过滤”的方式更直接：命中规则的域名交给指定服务器，未命中的域名回到 nameserver。配置中可以写完整域名、域名后缀，也可以在支持 GeoSite 数据的内核中使用 geosite: 匹配。

dns:
  enable: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
      - https://doh.pub/dns-query
    "+.example.cn":
      - https://dns.alidns.com/dns-query
    "intranet.example.net":
      - 192.168.1.1

最后一项展示了内网场景：公司或家庭内部域名只能由局域网 DNS 解析，就应为该域名单独指定 192.168.1.1，而不是把局域网 DNS 放进所有域名共用的 nameserver。这样既保留内部服务解析，又不会让全部公网域名都经过路由器。

如果配置引用 geosite:cn，需要确保 GeoSite 数据存在且格式与内核兼容。启动日志出现规则集载入失败、数据库缺失或 matcher 错误时，应先更新内核数据文件。为了减少外部数据依赖，也可以只使用 +.example.com 这样的域名后缀规则。

域名策略与代理规则不是同一件事

nameserver-policy 决定“向哪台 DNS 查询”，代理规则决定“连接通过哪个出站”。某个域名使用本地 DoH 解析，并不表示连接一定 DIRECT；某个域名通过远端 DNS 获得结果，也不表示连接一定走代理。两套规则应分别检查，避免把 DNS 选择误当成代理组选择。

Fake-IP、redir-host 与过滤列表

enhanced-mode 常见值为 fake-ip 和 redir-host。Fake-IP 模式不急于把真实地址返回给应用，而是先返回一个映射地址。应用连接该地址后，Clash 能把连接准确还原到原始域名，再执行域名规则。默认映射网段通常使用 198.18.0.1/16，该网段保留用于基准测试，不属于普通公网地址。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.com"

局域网设备发现、打印机、投屏、NTP 校时以及部分依赖真实 IP 的应用可能不适合 Fake-IP。把相应域名放进 fake-ip-filter 后，这些域名返回真实解析结果。过滤范围不应直接扩大到所有常见顶级域名，否则 Fake-IP 对域名识别和分流的帮助会明显下降。

redir-host 直接向应用返回真实 IP，兼容路径较直观，但连接进入内核后可能只保留 IP 信息。此时域名规则是否生效，还取决于连接元数据、DNS 映射缓存和域名嗅探。桌面系统使用 TUN 且规则以域名为主时，可先测试 Fake-IP；局域网服务异常较多时，再逐项补充过滤，而不是立刻关闭整个模式。

TUN 模式中的 DNS 劫持

只启用 dns.enable 不代表所有程序都会主动使用 Clash DNS。浏览器可能启用自己的安全 DNS，系统仍可能把 UDP 53 查询发给路由器，部分应用还会绕过系统代理。TUN 模式下的 dns-hijack 用于截获指定端口的 DNS 流量，并交给内核处理。

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

any:53 覆盖常规 UDP 53 查询，tcp://any:53 覆盖使用 TCP 53 的查询。它们不会自动截获应用直接发出的 DoH 请求，因为 DoH 运行在 HTTPS 上，通常使用 443 端口。若浏览器自行指定 DoH，解析请求可能不进入 Clash DNS；排查时可暂时把浏览器安全 DNS改为“使用系统设置”，再比较日志。

TUN 开启后仍需系统权限。Windows 通常需要内核创建虚拟网卡和路由，macOS 会请求网络扩展或 VPN 配置权限，Linux 需要访问 TUN 设备并修改路由。日志出现 permission denied、无法创建接口或路由添加失败时，应先处理权限，不要反复修改 nameserver。

listen 端口怎么选

listen: 127.0.0.1:1053 适合本机测试，不会直接向局域网其他设备开放。若必须让其他设备使用这台电脑作为 DNS，可监听局域网接口，但还要配置系统防火墙和固定地址。端口 53 可能被系统解析服务、虚拟机软件或其他 DNS 程序占用，1053、5353 等高位端口更适合排错；需要注意，5353 也可能与 mDNS 服务冲突。

mihomo 推荐配置示例

下面是一份适合桌面端起步的 mihomo 配置。它使用 Fake-IP、两台 DoH 解析器、独立节点域名解析器和 TUN DNS 劫持。具体 DNS 应按所在网络的可达性调整，不需要为了“完整”而保留无法稳定连接的地址。

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
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

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

  nameserver-policy:
    "+.local":
      - 192.168.1.1
    "+.lan":
      - 192.168.1.1

  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.com"

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

这份示例把 ipv6 设为 false，适用于本地 IPv6 路由不稳定或代理节点不支持 IPv6 的情况。如果宽带、局域网和节点都能正确处理 IPv6，可以改为 true，并同时检查规则是否包含 IPv6 地址段。只打开 DNS 的 IPv6 返回、却没有可用 IPv6 出站，常见结果是应用优先尝试 AAAA 地址后等待超时。

导入前先复制当前可用配置。常见桌面客户端可以从「配置」进入当前订阅或本地配置的编辑入口；订阅配置在更新时可能覆盖手工修改，因此更稳妥的方式是使用客户端提供的覆写、扩展配置或 Mixin 功能。保存后查看内核启动日志，确认没有 YAML 缩进错误、未知字段或端口占用。

验证 DNS 是否按预期工作

第一步:检查内核日志

保存配置并重启内核后，先观察 30 秒日志。应重点搜索 DNS、lookup、timeout、connection refused、address already in use 和 failed to parse。如果 127.0.0.1:1053 已被占用，可先关闭占用程序，或把 listen 改为未占用端口。

第二步:直接查询本地监听端口

安装了 dig 的系统可以绕过浏览器缓存，直接测试 Clash DNS。下面的命令明确指定本机地址和 1053 端口：

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

Fake-IP 模式下，A 记录可能返回 198.18.0.0/16 内的地址，这是预期行为。加入 fake-ip-filter 的域名应返回真实地址。若两类域名结果完全相同，应检查 enhanced-mode 是否生效、配置是否被订阅覆盖，以及当前运行的是否为刚编辑的配置。

第三步:比较规则与连接日志

打开一个用于测试的域名，确认连接记录中能看到域名而不是只有目标 IP。然后检查命中的规则与代理组。DNS 查询成功但连接失败，问题通常已进入节点、路由或规则阶段；DNS 日志直接超时，则应继续检查解析器可达性、代理节点域名和防火墙。

第四步:测试切换网络

分别在家庭宽带、手机热点或其他可用网络测试，每次切换后等待 10 至 30 秒，让接口、路由与 DNS 缓存完成更新。仅在某一网络失败，通常表示该网络拦截了特定 DNS 协议、IPv6 路由异常，或 DoH 服务器不可达。此时可临时保留一台 UDP DNS 与一台 DoH 进行对照，而不是一次替换全部参数。

常见错误与处理顺序

错误一:节点全部超时，但网页域名能解析

优先检查 proxy-server-nameserver。节点地址如果使用域名，普通 nameserver 正常不代表节点域名一定走了可用路径。还要确认节点域名没有被 nameserver-policy 指向只在代理建立后才能访问的 DNS。

错误二:开启 TUN 后局域网设备打不开

把路由器、NAS、打印机与投屏服务使用的域名加入 fake-ip-filter，并为内部域名设置 nameserver-policy。局域网常见后缀包括 .lan 和 .local，但实际名称应以路由器 DHCP 或内部 DNS 配置为准。不要只添加设备当前 IP，因为 DHCP 续租后地址可能变化。

错误三:浏览器可以打开，命令行程序失败

浏览器可能使用自己的 DoH，而命令行依赖系统 DNS；也可能浏览器走系统代理，命令行只走 TUN。先关闭浏览器独立安全 DNS进行对照，再用 dig 查询 Clash 监听端口。若本地查询正常，继续检查系统代理、TUN 路由和该命令行程序是否固定指定了解析器。

错误四:规则偶尔匹配 IP 而不是域名

确认 DNS 查询确实经过 Clash，并检查 enhanced-mode。若使用 redir-host，可开启内核支持的域名嗅探功能，但嗅探不是所有协议都能恢复域名。对域名规则依赖较强的桌面环境，Fake-IP 配合合理过滤列表通常更稳定。

错误五:配置更新后手工修改消失

订阅更新通常会重新写入配置文件。DNS 自定义项应放在客户端的覆写、扩展脚本或 Mixin 中，或者维护独立本地配置。编辑前记录「设置」→「内核」中显示的实际内核，并在「日志」中确认载入文件路径，避免改到未被当前配置使用的副本。

配置取舍总结

常规域名解析放在 nameserver，启动 DoH 所需的基础解析放在 default-nameserver。
代理节点使用域名时，配置可直连访问的 proxy-server-nameserver，避免循环依赖。
固定域名分流优先使用 nameserver-policy；fallback-filter 更适合兼容传统的双解析器筛选方案。
TUN 环境使用 dns-hijack 接管 UDP 53 和 TCP 53，但它不会自动接管应用自行发出的 DoH。
Fake-IP 有助于保留域名信息；局域网、校时和设备发现异常时，逐项增加 fake-ip-filter。
每次只修改一组参数，重启内核后查看日志并用本地端口查询验证，避免同时更换 DNS、规则和节点。

一份可维护的 Clash DNS 配置不需要堆叠大量服务器。先明确普通域名、节点域名、内网域名分别由谁解析，再决定是否需要 fallback、Fake-IP 与 TUN 劫持。路径清楚后，解析失败、规则误判和局域网冲突都能从对应字段开始定位。