Clash DNS 配置拆解：nameserver、fallback 与 dns-hijack 各管什么

先分清 DNS 查询入口、上游与结果筛选

Clash DNS 排错需要沿着查询路径检查：应用把请求发到哪里，内核是否收到请求，内核选择哪个上游，最后把什么结果交回应用。只修改 nameserver，不能保证浏览器的查询已经进入 Clash；开启 TUN，也不能保证应用自带的加密 DNS 会被普通端口劫持接管。

本文配置以 mihomo 内核为准。旧版 Clash 与不同客户端的字段支持、覆写方式并不完全相同。先在客户端的内核信息中确认实际运行的内核，再检查最终生效配置。客户端界面里的开关名称不是 YAML 字段的替代品。

字段	所在层级	负责的问题
`enable / listen`	`dns`	是否启用内置 DNS，以及在哪个地址、端口接收查询。
`nameserver`	`dns`	普通域名解析使用的主要上游。
`fallback`	`dns`	参与备用解析、供筛选逻辑选择的上游。
`fallback-filter`	`dns`	判断何时采用 fallback 的结果。
`dns-hijack`	`tun`	把 TUN 路径上匹配的 DNS 流量交给内置 DNS。

nameserver：内核使用的解析上游

nameserver 是内置 DNS 的主要解析服务器列表。它可以包含普通 DNS 地址，也可以使用内核支持的 DoH、DoT 地址。这里填写的是解析服务，不是代理节点；把节点服务器地址填进来，通常不会得到可用的 DNS 应答。

从一个可验证的最小配置开始

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

这是用于合并到现有配置的 DNS 片段，不是完整代理配置。1053 是内置 DNS 的测试监听端口，与常见的混合代理端口 7890 不同。回环地址只供本机访问，适合先验证解析链路；需要为局域网设备提供解析服务时，必须另行考虑监听地址、防火墙和访问范围。

redir-host 便于观察真实解析结果，适合本文的初步测试，不代表必须长期使用该模式。
ipv6: false 用于本例简化 AAAA 记录排查，不等于关闭操作系统 IPv6，也不等于阻断所有 IPv6 连接。
列出多个上游不代表严格按第一项、第二项逐个等待，也不能据此判断每次查询最终用了哪一项。

DoH 地址也可能需要先解析

如果把上游换成 https://dns.alidns.com/dns-query，内核首先需要知道 dns.alidns.com 的地址。default-nameserver 负责解析 DNS 服务器自身的域名，属于引导解析，不是普通网站的默认解析列表。使用不依赖域名引导的 IP 地址作为引导服务器，可以减少启动依赖环。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query

DoH 加密的是客户端到该解析服务之间的 DNS 传输，不会自动让所有应用连接经过代理。上游是否可达、解析请求如何出站、网站连接命中什么规则，仍需分别核对。

fallback 与 fallback-filter：备用结果不是简单的故障切换

fallback 不宜理解成“第一个 DNS 超时之后才启用的第二个 DNS”。配置它后，内核可向主要与备用上游并行发起解析，再根据 fallback-filter 的条件决定采用哪一侧的结果。实际请求次数还会受到缓存、解析策略和内核实现影响。

筛选条件可以针对域名，也可以检查主要解析结果的 IP。域名命中指定条件时，可直接采用 fallback；IP 条件则用于判断主要结果是否需要被备用结果替代。两者都不是连接分流规则：选择 fallback 解析，并不等于该网站连接一定走代理。

使用明确的 IP 条件，避免先引入地域判断

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8

本例显式关闭 GeoIP 筛选，仅把两个地址范围作为筛选条件：主要上游返回的地址若命中 0.0.0.0/32 或 127.0.0.0/8，则采用备用解析结果。这是便于理解的示例，不是对所有异常 DNS 应答的完整识别规则。部署前还要确认两个备用 DoH 服务在当前网络确实可达。

回环地址也可能是本地开发、广告过滤或组织内部策略的预期结果。因此不要看到特殊地址就一律认定为错误，更不要把整个私有地址空间直接加入筛选后，再期待内网域名保持原来的解析行为。

geoip 与 domain 分别控制什么

geoip: true 配合 geoip-code: CN 时，会依据主要结果的 IP 地域归属进行筛选；不属于指定地区的结果可能转用 fallback。判断依据是 IP 归属数据，而非网页内容。
GeoIP 判断依赖相应数据。数据缺失、过旧或地址归属不符合实际服务位置，都会影响结果，不应把地域判断当成解析正确性的证明。
domain 可列出应采用 fallback 的域名模式，例如 +.example.com。此处的 example.com 是语法示例，实际使用时只加入有明确需求的域名。
fallback-filter 不会过滤备用上游返回的所有不良内容，也不是广告过滤列表。

dns-hijack：把端口 53 查询交给内置 DNS

上游设置完成后，还需要确认应用的查询确实进入内核。在 TUN 模式下，dns-hijack 用来匹配经过 TUN 的 DNS 流量，并送往内置 DNS 处理。它解决的是查询入口问题，不能代替 nameserver，也不能修复一个本来就不可达的上游。

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

该片段与前面的 dns: 段并列合并。any:53 用于匹配 UDP 端口 53 查询，tcp://any:53 补充 TCP DNS。普通 DNS 不只有 UDP；响应截断后的重试或部分应用行为可能使用 TCP。

auto-route 用于自动配置流量进入 TUN 的路由，通常需要相应系统权限。客户端可能通过服务模式或授权流程启动内核，具体方式取决于平台。路由创建失败时，只看到“开启 TUN”的界面状态不足以确认接管成功。

系统平台还会影响接管边界。发往本地网络 DNS、回环地址或特定接口的查询，可能不经过预期的 TUN 路径。尤其在使用路由器地址作为系统 DNS 时，应通过实际查询与日志确认，而不是把 any 理解成操作系统中所有 DNS 请求。

Fake-IP 与订阅覆写：两类容易误判的现象

返回 198.18 开头的地址，不一定是解析异常

在 enhanced-mode: fake-ip 下，内核可以向应用返回映射地址，再用映射关系关联域名与后续连接。常见配置使用 fake-ip-range: 198.18.0.1/16。看到这个地址段，首先应检查当前增强模式，而不是立即更换 fallback。

Fake-IP 响应并不代表内核完全不需要真实解析；后续是否解析、使用哪个上游，还取决于连接处理与策略。fake-ip-filter 则控制哪些域名不采用 Fake-IP 响应，与 fallback-filter 的上游结果筛选是不同功能。需要真实地址的内网应用，应先检查域名例外和内网解析路径。

编辑订阅缓存，可能在更新后丢失

不少客户端会把订阅、本地覆写和界面设置合并成运行配置。直接编辑订阅下载得到的文件，下一次更新可能被替换；同时保留多个 DNS 配置入口，也可能导致最终值不是刚编辑的那一份。

先备份当前可工作的配置，记录系统代理与 TUN 的开关状态。
选择客户端支持的持久覆写入口，只保留一套清晰的 DNS 修改来源。
重载配置后，查看最终生效的 dns 与 tun 段，核对监听端口和缩进层级。
更新一次订阅，再检查覆写是否仍然存在。不要只测试首次导入。

验证顺序：先测内置 DNS，再测系统接管

一次同时替换上游、开启 Fake-IP 和开启 TUN，会使故障来源难以区分。建议先使用 redir-host 与 127.0.0.1:1053 验证解析服务，再逐项恢复实际所需功能。以下命令是检查方法，不是本站网络环境的实测结果。

第一步：检查配置并直接查询监听端口

mihomo -t -f config.yaml

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

第一条命令要求本机能直接运行 mihomo，并指向实际配置文件；客户端管理的内核应使用对应的配置检查入口。后两条适用于已安装 dig 的系统，分别验证 UDP 与 TCP 查询。关注 status、ANSWER SECTION 和实际响应，而不只是命令有没有退出。

Windows 可以启动 nslookup 进入交互模式，再指定端口与服务器。这里必须设置为 DNS 端口 1053，不能指向 HTTP/SOCKS 混合代理端口。

nslookup
set port=1053
server 127.0.0.1
example.com
exit

第二步：比较直接查询与系统默认查询

若直接查询 1053 超时，先检查内核是否启动、端口是否监听以及日志中的上游连接错误。
若直接查询正常，而不指定服务器的 nslookup example.com 失败，重点检查系统 DNS、TUN 路由和劫持范围。
若命令行正常、只有浏览器失败，检查浏览器安全 DNS、代理设置和缓存。解析正常也不能证明目标网站的 TCP 或 TLS 连接正常。
若刚改完配置仍得到旧结果，重载内核并处理相关应用缓存。Windows 可用 ipconfig /flushdns 清理系统 DNS 缓存，但它不会清除内核或浏览器各自维护的全部缓存。

现象	优先检查	不要先做什么
1053 端口无响应	`enable`、监听冲突、内核日志	反复修改连接分流规则
主要上游可用，fallback 超时	备用服务可达性与其出站路径	继续叠加更多不可达上游
仅内网域名失败	内网 DNS、域名定向解析与 Fake-IP 例外	把所有查询都交给公共 DNS
返回 Fake-IP 但网页打不开	后续连接是否仍进入同一内核	仅凭映射地址认定 DNS 污染

最终检查可以压缩成三个问题：请求有没有进入内置 DNS，上游有没有返回可用结果，后续连接有没有按预期处理。nameserver 与 fallback 处理解析来源，fallback-filter 处理结果选择，dns-hijack 处理 TUN 查询入口。按这个边界逐项修改，配置变化与故障现象才能对应起来。需要继续调整策略组与 TUN 时，可参阅mihomo 进阶配置手册。