Clash DNS 怎么配:nameserver、fallback 与 DNS 劫持参数逐项说明

先确定内核与 DNS 请求入口

结论是：先让查询进入 Clash DNS，再讨论用哪个上游解析。仅修改 nameserver，不会自动接管系统、浏览器和局域网设备的全部 DNS。网页能打开，也不能证明查询已经经过这段配置；系统缓存、浏览器安全 DNS 或应用自带解析都可能绕过它。

“Clash 客户端”是界面程序，真正解释 YAML 的是内核。原版 Clash、历史 Premium 内核与 Clash Meta（现名 mihomo）支持的字段并不完全相同。本文的可复制示例以 mihomo 内核为目标；旧内核不要直接套用 proxy-server-nameserver 或 TUN 参数。先在客户端的“关于”或启动日志中确认内核名称与版本，再用对应内核检查配置。

1. 备份当前配置，记录原来的 dns、tun 和客户端 DNS 覆写设置。
2. 在“配置”中确认实际启用的配置文件；有订阅覆写功能时，应修改持久化覆写，而不是会被下一次订阅更新替换的临时文件。
3. 查看运行配置或导出的合并配置，确认界面的 DNS 设置没有覆盖 YAML。
4. 每次只改一组参数，重新加载后查看启动错误和解析日志，再继续下一步。

dns 字段：监听地址与解析模式怎么选

fake-ip 返回虚拟地址，不等于解析故障

fake-ip 会为域名分配虚拟地址，并保存域名与地址的映射。应用连接这个地址时，内核可以恢复域名并匹配规则。查询返回 198.18.x.x 通常是预期结果，不要拿它和公共 DNS 的真实地址直接比较，更不要因为 ping 不通就判断配置失败。

redir-host 则以真实解析结果为主，某些依赖真实 IP 的程序更容易兼容，但需要更留意解析污染和域名信息的保留。两种模式都不决定流量一定走代理；解析模式负责域名与地址，规则负责连接去向。

listen 不是系统 DNS 设置

127.0.0.1:1053 只在本机提供一个非标准端口的 DNS 服务。多数系统 DNS 设置只能填写 IP，默认访问 53 端口，不能直接填写这个地址加端口。因此本文先用查询命令验证 1053，再配置 TUN 劫持。不要为了让其他设备访问就随手改成 0.0.0.0:53：这会扩大监听范围，还需要检查端口冲突、防火墙与局域网访问边界。

nameserver：先用一份最小配置验证上游

下面是一份 mihomo 的 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

这里的 default-nameserver 用来解析 dns.alidns.com、doh.pub 这类上游主机名；真正的日常查询由 nameserver 处理。DoH 使用 HTTPS，常见连接端口是 443，但加密不保证服务始终可达，也不保证它给出的结果适合所有代理出口。

• 不要把列表当作“第一个坏了才用第二个”：内核可能并发查询或采用内部选择策略，列表顺序不是可靠的主备优先级。
• 不要一次填十几个上游：先用一到两个可达服务，故障时更容易确认超时发生在哪一端。
• 注意 IPv6 的范围：这里的 dns.ipv6: false 用来让 DNS 对 AAAA 查询返回空结果，不代表系统 IPv6 已关闭，也不阻止应用连接已知 IPv6 地址。

代理服务器本身若使用域名，mihomo 还支持 dns.proxy-server-nameserver，用于解析节点服务器域名。它不是专门解析被代理网站的上游。出现“节点域名解析失败”时，应先确认这一环能独立完成，避免“必须连上代理才能解析代理服务器”的循环依赖。

fallback 与 fallback-filter：不是超时备用按钮

fallback 容易被名字误导。它配合 fallback-filter 参与解析结果的筛选，不只是等待 nameserver 超时后才启用。配置了两组上游时，可能两边都会产生查询；哪些结果被接受，还取决于过滤条件和内核实现。

下面片段应加入现有的 dns 段，与 nameserver 同级。示例关闭 GeoIP 判断，避免依赖未核实的地区数据库，只展示明确的域名条件和可疑地址过滤。

  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.github.com'

三类过滤条件分别解决什么问题

• domain：指定域名使用 fallback 的解析结果。示例中的 +.github.com 匹配该域名及其子域名，不是让网站自动走代理。
• ipcidr：当普通上游返回的地址命中这些网段时，转而采用 fallback 结果。示例把零地址和回环地址列为可疑结果；如果某个内部域名确实应解析到回环地址，就不该照搬这项过滤。
• geoip 与 geoip-code：启用 GeoIP 判断后，可以按期望地区判断普通上游结果是否应被替换。常见配置为 geoip: true、geoip-code: CN，但它依赖数据库，海外 CDN 地址并不天然代表污染。

如果主要需求是“某类域名固定交给某个 DNS”，通常应该先考虑 nameserver-policy，而不是堆叠复杂的 fallback 条件。它表达的是解析上游的选择；代理出口仍然由连接规则决定。

  nameserver-policy:
    '+.cn':
      - https://dns.alidns.com/dns-query
    '+.github.com':
      - https://cloudflare-dns.com/dns-query

这一片段同样放在 dns 内。匹配策略的查询按指定上游处理，不要再用 fallback 的默认筛选逻辑去推断它。配置初期可在“策略解析”和“fallback 筛选”中先选一种验证，确认日志与结果一致后再组合。

dns-hijack：在 TUN 中接住 53 端口查询

在 mihomo 中，dns-hijack 属于顶层 tun 段，不属于 dns。它把进入 TUN 且匹配条件的 DNS 流量交给内核 DNS 模块。下面示例需结合已有 TUN 设置使用；客户端如果通过界面管理 TUN，应检查最终运行配置，防止界面将 YAML 覆盖。

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。开启 TUN 通常需要系统管理员权限或客户端的服务模式。若原有配置已经有 tun:，应修改其中字段，不要再次声明同名段。

这些请求不会因为写了 any:53 就自动被接管

• 浏览器 DoH：通常走 HTTPS 443，不匹配 53 端口。排查时可暂时关闭浏览器“安全 DNS”；Firefox 常见路径是“设置”→“隐私与安全”→“基于 HTTPS 的 DNS”。测试完再按使用需求恢复。
• Android 私人 DNS：严格模式通常使用 DoT 853。部分设备路径为“设置”→“网络和互联网”→“私人 DNS”，厂商名称可能不同，不能当作普通 UDP 53 处理。
• 未进入 TUN 的流量：局域网直连路由、其他 VPN、特殊网络接口或系统处理路径都可能使流量绕过 TUN。即使系统 DNS 指向路由器，也要验证这条流量是否真的被捕获。

监听成功、TUN 开启、DNS 劫持生效是三件不同的事。在手机上还要考虑 VpnService 的授权及其他 VPN 冲突；在桌面系统上则检查服务权限、路由与防火墙，不要通过反复更换解析器解决入口问题。

验证顺序：配置检查、定向查询、系统入口

第一步：检查 YAML 与启动日志

如果本机可直接运行 mihomo，可在配置所在目录执行以下命令。客户端用户也可以使用界面提供的配置检查功能；命令检查通过只说明配置可被解析，不证明上游一定可达。

mihomo -t -f config.yaml

出现未知字段时先核对内核，出现缩进或重复键问题时先修正文件。日志出现 address already in use，应查找占用 1053 的进程或换一个测试端口；不能靠修改上游 URL 解决监听冲突。

第二步：明确查询本机 1053 端口

安装了 dig 的 macOS 或 Linux 环境可以运行下面三条命令。第一条验证 UDP 查询，第二条验证 TCP，第三条检查 AAAA 行为。

dig @127.0.0.1 -p 1053 www.example.com A
dig @127.0.0.1 -p 1053 www.example.com A +tcp
dig @127.0.0.1 -p 1053 www.example.com AAAA

Windows 的 nslookup 可先进入交互模式，再设置测试端口。测试完成后输入 exit 退出。

nslookup
server 127.0.0.1
set port=1053
set type=A
www.example.com
exit

在 fake-ip 模式下，A 记录返回虚拟地址是正常的。要检查真实上游结果，可在备份后临时切到 redir-host，重新加载并清理相关缓存，再查询比较；测试后恢复原设置。不要把 fake-ip 响应耗时当成真实上游的网络延迟。

第三步：回到系统默认解析路径

确认本机查询成功后，再开启 TUN 并通过系统默认解析器查询，同时观察客户端日志。Windows 可用 ipconfig /flushdns 清理系统 DNS 缓存；使用 systemd-resolved 的 Linux 可用 resolvectl flush-caches。浏览器还可能保留自己的缓存与连接，需要重新启动或单独清理。

日常配置建议：保持解析链路可解释

日常使用可以从“一个 DNS 入口、少量可达上游、明确的规则模式”开始。需要固定解析上游时增加 nameserver-policy；确实存在错误结果筛选需求时，再配置 fallback-filter。每增加一层策略，都应能说明是哪类域名受影响、上游通过什么路径连接，以及失败时从哪里看日志。

DNS 加密可以保护到解析器之间的查询传输，但不是所有连接信息的隐藏开关；DNS 泄漏检测页面显示某个解析服务，也不直接说明全部应用流量的路径。要判断是否绕过预期入口，应结合抓包、解析日志与连接记录，而不是只看一次网页测试结果。

最后记住三组对应关系：nameserver 决定向谁查询，fallback-filter 参与选择哪些解析结果，tun.dns-hijack 决定哪些传统 DNS 请求被接入内核。把这三层分开验证，通常比反复替换整份“通用 DNS 配置”更快定位问题。其他基础字段可对照YAML 手册，连接与启动异常可继续查看疑难解答。