Clash DNS 配置详解:nameserver、fallback 与 fake-ip 劫持逐项说明

DNS 配置的四个环节

排查 Clash DNS，先把查询接入、解析模式、上游选择和连接分流分开。应用把域名交给哪个 DNS 服务，由系统、浏览器和接管方式决定；Clash 收到查询后，才会按 dns 配置处理。最后的连接出口由代理模式与 rules 决定，并不是填了某个 DNS 地址就一定走某个节点。

环节	关键字段	检查目标
查询接入	`listen`、`tun.dns-hijack`	应用查询是否进入内核
解析模式	`enhanced-mode`	返回真实地址还是映射地址
上游选择	`nameserver`、`fallback-filter`	接受哪一组解析结果
连接分流	`rules`、`proxy-groups`	实际连接使用哪个出口

订阅原文、客户端编辑器与最终运行配置可能是三个不同文件。订阅更新会覆盖原文时，应通过客户端提供的覆写或合并配置保留修改。合并后检查最终结果：同一个 YAML 映射中不要重复写两个 dns: 或两个 tun:。

nameserver、fallback 与引导解析

nameserver：常规上游，不是代理节点

nameserver 是 DNS 解析上游列表，可以填写普通 DNS 地址，也可以使用内核支持的 DoH、DoT 地址。普通地址 223.5.5.5 通常表示使用 UDP 53；https://1.1.1.1/dns-query 表示 DoH，通常通过 HTTPS 443 连接。上游必须在当前网络中可达，协议名称本身不保证请求成功。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

这是用于解释字段关系的片段，不是完整的节点配置。127.0.0.1:1053 只在本机监听，便于显式查询测试；操作系统不会因为这个监听端口存在就自动把所有 DNS 请求交给它。ipv6: false 控制此 DNS 模块的 AAAA 应答行为，不等于关闭操作系统 IPv6，也不等于阻止所有 IPv6 连接。

default-nameserver：解析 DNS 上游的域名

如果上游写成 https://dns.example.com/dns-query 这样的域名形式，建立连接前需要先取得它的 IP。default-nameserver 负责这类引导解析。为避免引导环路，示例使用字面 IP 地址。它不是“所有业务域名都先查询一次”的默认服务器，也不是代理节点专用解析器。

mihomo 还提供 proxy-server-nameserver，用于代理节点域名解析。节点地址本身是域名、且解析路由产生循环依赖时，需要单独检查这一层。不要把“网站域名解析失败”和“节点域名无法解析”归为同一个问题。

fallback：备用结果，不是串行等待链

配置 fallback 后，常见处理路径会并行发起主组与备用组查询，再依据过滤条件决定采用哪组结果。不要按“先等 nameserver 超时，再逐条尝试 fallback”理解。多个地址的应答竞争、缓存与失败处理受内核实现影响，列表顺序也不能直接当作严格的优先级。

DoH 只说明到解析服务这一段使用 HTTPS。它不会自动启用代理出口，也不能阻止浏览器使用自己的安全 DNS。DNS 请求是否遵循路由规则，需要结合内核字段、最终配置和日志确认。

fallback-filter：哪些结果需要切换

fallback-filter 不会修改 IP 所属地区，而是为选择备用结果提供条件。在上面的配置里，geoip: true 配合 geoip-code: CN，表示主组返回的地址若不符合指定地区条件，就倾向采用备用组结果。它依赖 GeoIP 数据；数据过期、CDN 调度变化或地址归属不准确，都可能改变选择结果。

geoip: false：停用这一项地理归属判断，不代表关闭全部过滤条件。
ipcidr：主组结果落入这些地址段时，使用备用结果。240.0.0.0/4 是常见的保留地址段过滤示例。
domain：匹配指定域名时直接使用备用组结果，不再依赖主组地址是否满足地区条件。

  fallback-filter:
    geoip: false
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

此片段应放在现有 dns 下，用来替换前例的 fallback-filter。example.com 是保留的文档示例域名，不是推荐的实际业务名单。这里关闭地区判断，只保留地址段和域名条件，方便隔离问题。不要未经验证就过滤所有私有网段：企业内部域名、路由器管理页和家庭 NAS 可能本来就应该解析到私有地址。

另一个常见误区是把 fallback-filter.domain 当成代理规则。它只控制 DNS 结果来源，不会生成 DOMAIN-SUFFIX 规则。网站即便使用备用解析结果，连接仍可能被 DIRECT 规则接走。

fake-ip 与 redir-host 的区别

fake-ip：先建立域名映射

enhanced-mode: fake-ip 会为适用的查询返回映射地址。应用连接这个地址后，内核可以找回原始域名，再进行规则匹配与连接处理。因此，在命令行看到 198.18.x.x 不等于解析污染；它可能正是本机配置的映射结果。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query

198.18.0.1/16 位于基准测试专用地址空间。使用前仍要检查本地路由，避免与实验网络冲突。返回映射地址以后，相关连接必须能够再次进入内核；如果 DNS 走了 Clash，但数据连接绕过接管，应用就可能无法访问这些地址。

fake-ip-filter 用来让指定域名返回真实解析结果。上述示例使用通常的黑名单过滤语义，不同时配置其他过滤模式。内网服务可以按实际域名加入列表；但 .local 常由 mDNS 处理，把它加入过滤列表并不意味着 Clash 会代理所有组播发现请求。

redir-host：返回真实地址

redir-host 返回实际解析地址，并利用解析记录关联域名与连接。它适合需要真实 IP 的兼容性场景，但多个域名共享地址、应用自行解析或缓存过久时，域名关联未必完整。两种模式都不等同于嗅探：mihomo 的 sniffer 是从后续连接信息识别域名的另一套机制。

TUN dns-hijack：把查询接入内核

dns-hijack 属于 tun，不是 dns 的子字段。mihomo 中常见的写法如下；将它与上一节的 DNS 片段合并时，两个顶层字段应保持同级。

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

any:53 接管进入 TUN 的常规 UDP 53 查询，tcp://any:53 补充 TCP 53。接管后的查询由内核 DNS 模块处理，不要求系统把服务器显式写成 127.0.0.1:1053。但前提仍是数据包实际经过 TUN 路径，且当前平台支持相应的路由与接管功能。

开启 TUN 通常需要管理员权限或系统授权。创建虚拟网卡成功后，还要检查路由是否生效。
浏览器 DoH 使用 HTTPS，Android 私人 DNS 常使用 DoT；它们不是普通的 53 端口查询，不能靠上述两行自动改写。
仅开启系统 HTTP 代理，不保证应用的 DNS 查询也进入内核。部分应用先用系统 DNS 解析，再发起代理连接。
多个 VPN、虚拟网卡或本地 DNS 服务同时运行时，先保留一条接管链进行验证，避免互相改路由。

不要为了接管方便直接把 dns.listen 改成 0.0.0.0:53。这会改变监听范围，还可能与系统解析服务发生端口冲突。只有确实需要为局域网设备提供 DNS 时，才应配置对外监听，并同时限制防火墙来源与可访问网络。

常见组合与配置选择

使用条件	建议起点	重点验证
先排查解析上游	redir-host + 本机 1053 监听	显式查询能否取得真实地址
需要按域名稳定分流	fake-ip + TUN 接管	映射地址对应的连接进入内核
企业内网或家庭服务较多	按域名指定 DNS 与过滤例外	内部域名没有发往公共解析器
需要比较两组解析结果	nameserver + fallback + 明确过滤条件	选用结果符合预设条件

mihomo 可通过 nameserver-policy 为特定域名指定上游。例如，公司 DNS 位于 192.168.50.1，且内部域名使用文档示例后缀 corp.example 时，可以在现有 dns 下加入：

  nameserver-policy:
    '+.corp.example':
      - 192.168.50.1

实际使用时必须换成真实的内部后缀与可达的 DNS 地址，并验证相关域名是否还需要加入 fake-ip-filter。域名策略、备用过滤与连接规则是不同层次的选择；排障时先去掉互相重叠的策略，确认基础解析，再逐项加回。

如果希望 DNS 连接遵循分流规则，mihomo 的 respect-rules 需要结合 proxy-server-nameserver 等设置规划，避免“解析节点需要先连接节点”的循环。基础配置尚未验证前，不建议把该开关与多个域名上游策略一次性加入。

验证顺序与故障定位

第一步：验证配置与监听

使用对应的 mihomo 可执行文件检查语法，再通过客户端重载。下面假定当前目录存在实际配置文件 config.yaml，并已安装 dig：

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

语法检查成功不代表所有上游均可达。UDP 查询成功、TCP 查询失败时，先确认监听与本机防火墙；两者均超时时，检查 dns.enable、端口占用和最终运行配置。fake-ip 模式返回映射地址只能证明本地映射路径工作，不能单凭这一项确认真实上游健康。

第二步：验证系统路径

显式指定 127.0.0.1 与端口，是在测试内核监听。接着执行 nslookup example.com，测试系统默认解析路径。两者结果不同不一定是故障，但如果预期所有查询都经由内核，就需要检查系统 DNS、TUN 路由和浏览器安全 DNS 设置。

第三步：验证连接与出口

清理缓存，关闭旧标签页或旧应用连接，再发起一次访问。
在客户端连接列表中检查目标域名、命中的规则和最终策略组。
若解析成功但连接超时，检查节点可达性、代理协议和目标端口，不要立即更换 DNS。
若只有内部服务失败，分别查询内部 DNS 与公共 DNS，确认是否缺少域名上游策略。
若怀疑 DNS 绕过，结合抓包查看离开物理网卡的 UDP/TCP 53、853 及已知 DoH 连接。公共测试页显示的解析器位置不能独立证明本机请求路径。

一次只调整一个环节：先让内核可以解析，再确认应用查询进入内核，最后观察连接规则。这样才能区分上游不可达、过滤条件错误、fake-ip 连接绕行和 TUN 未接管这四类问题。字段的完整上下文可继续查阅配置大全；首次安装与导入流程见使用教程。