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

先分清 Clash DNS 的处理路径

Clash DNS 配置不是简单地把系统 DNS 换成另一个地址。启用内置 DNS 后，客户端会接收域名查询，再根据 nameserver、fallback、规则与增强模式决定如何解析。连接建立时，Clash 还需要把域名、解析结果和代理规则关联起来，因此 DNS 配置会直接影响规则命中、首次打开速度和部分应用的可用性。

一次常见查询可以拆成四步：应用发出对 example.com 的查询；系统或 TUN 将 53 端口请求交给 Clash；Clash 使用配置中的上游服务器解析；连接请求再按照域名规则、IP 规则或最终规则选择直连与代理。任何一步绕开 Clash，都可能出现域名规则未命中、解析结果被缓存或网页能打开但应用连接失败。

enable、listen 与基础字段怎么写

enable：打开内置 DNS

enable: true 表示启用 Clash 的 DNS 模块。设为 false 后，其余 dns 字段不会按预期参与解析。配置加载成功不等于查询已经进入该模块，还要结合系统代理、TUN 或客户端的网络扩展实现判断。

listen：提供本地 DNS 监听端口

listen: 127.0.0.1:1053 表示只在本机回环地址的 UDP/TCP 1053 端口提供 DNS 服务。1053 是常见的非特权测试端口，也能避免与系统占用的 53 端口冲突。若写成 0.0.0.0:1053，同一局域网中的设备可能访问该端口，因此移动设备日常配置通常优先使用回环地址或由客户端自动管理监听。

listen 只是“在哪里等待查询”，不是“把查询抓过来”。在启用 TUN 的桌面环境中，通常还要配置 tun.dns-hijack；在 iOS 中，DNS 接管往往由客户端的 Network Extension 完成，部分客户端会忽略 YAML 里的 tun 段并使用应用自身的开关。

一份可作为起点的配置

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

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  fallback:
    - https://8.8.8.8/dns-query
    - tls://1.0.0.1:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

这份示例适合支持 Clash Meta 或 mihomo 语法的客户端作为基础模板。具体客户端可能对 DoH、DoT、IPv6 或 TUN 字段进行二次处理，导入后应先查看配置校验结果。若配置核心较旧，也要确认它是否识别 geoip-code、DoT 地址和增强模式字段。

nameserver、default-nameserver 与 fallback 的区别

default-nameserver：为加密 DNS 地址做启动解析

当 nameserver 使用 https://dns.alidns.com/dns-query 这类包含域名的 DoH 地址时，Clash 首先要知道 dns.alidns.com 对应哪个 IP。default-nameserver 主要承担这类启动解析，也称 bootstrap DNS。这里优先填写可直接访问的 IP 地址，避免“需要先解析 DoH 域名，但解析本身又依赖 DoH”的循环。

如果所有上游都写成域名，并且 default-nameserver 本身不可达，日志中常见的现象是 DNS 请求超时、配置刚启动时无法联网，或重复出现解析上游域名失败。排查时可先保留一个当前网络可访问的纯 IP DNS，再验证 DoH 地址。

nameserver：日常查询的主要来源

nameserver 是普通查询的主要上游。可以填写传统 UDP DNS、TCP DNS、DoT 或 DoH。UDP 地址写法如 223.5.5.5，DoT 可写为 tls://1.1.1.1:853，DoH 可写为 https://1.1.1.1/dns-query。混用协议便于排查网络限制，但上游数量不是越多越好，两个稳定且路径明确的服务器通常比堆叠六七个地址更容易定位故障。

fallback：按过滤条件选择备用结果

fallback 容易被理解成“nameserver 超时后再使用的备用 DNS”，实际行为通常更接近并行获取候选结果，再由 fallback-filter 判断采用哪一组结果。不同核心版本在并发、缓存和结果选择上存在细节差异，但不能把它当成传统的主备切换。

例如启用 geoip: true 且设置 geoip-code: CN 后，主要解析结果若不符合过滤条件，核心可以采用 fallback 返回的结果。domain 中明确列出的域名也可以优先使用 fallback 结果。规则库版本、GeoIP 数据和上游返回的 CDN 地址都会影响判断，因此不建议仅凭“IP 看起来不在本地”就认定配置错误。

fallback-filter 每个条件如何生效

geoip 与 geoip-code

geoip: true 启用基于 IP 地理数据的筛选，geoip-code: CN 指定用于判断的地区代码。它依赖客户端随附或下载的 GeoIP 数据，不是实时查询服务。数据文件缺失、过旧或路径配置错误时，筛选结果可能与预期不同。

ipcidr

ipcidr 用 CIDR 网段标记需要采用 fallback 候选结果的地址。常见示例 240.0.0.0/4 覆盖保留地址范围，用来排除明显异常的解析结果。不要随意加入大范围公网网段，否则正常网站也会持续走 fallback。

domain

domain 用于指定域名。mihomo 常见写法 +.example.com 可匹配该域名及其子域名。若只为少量网站指定独立上游，较新的 mihomo 配置也可考虑 nameserver-policy，将特定域名直接映射到指定 DNS，逻辑通常比大范围 fallback 筛选更清楚。

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

  nameserver-policy:
    "+.example.net":
      - https://1.1.1.1/dns-query
    "geosite:cn":
      - https://dns.alidns.com/dns-query

nameserver-policy 是否支持规则集写法，取决于所用核心和客户端打包版本。使用 mihomo v1.19 系列配置时，应以客户端显示的核心版本和配置校验结果为准。若客户端仍使用较早的 Clash 核心，可以改用普通域名列表，避免直接复制不受支持的规则集语法。

fake-ip 与 redir-host 怎么选

fake-ip：先返回保留地址，再关联真实域名

enhanced-mode: fake-ip 会从指定地址池返回一个映射地址，常见范围是 198.18.0.1/16。应用随后连接该地址时，Clash 根据内部映射恢复原域名并执行规则。它能减少部分场景下的额外解析等待，也有利于保持域名规则信息。

在测试环境中执行 dig @127.0.0.1 -p 1053 example.com A，若返回 198.18.x.x，通常说明请求已进入 fake-ip 流程。这个结果不是网站的真实公网 IP，不应拿去和公共 DNS 查询结果逐项比较。

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

打印机、路由器、局域网发现和部分依赖真实 IP 的服务可能不适合 fake-ip。可以用 fake-ip-filter 排除本地域名，但应从实际故障域名开始添加，不要直接复制上百条来源不明的列表。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "router.asus.com"
    - "time.apple.com"

*.local 常与 mDNS 和局域网发现有关。iOS 上的 AirPlay、隔空打印或家庭设备发现出现异常时，可先检查这些域名是否被 fake-ip 接管，同时确认客户端是否允许本地网络访问。iOS 26 中对应权限可在「设置」→「隐私与安全性」→「本地网络」查看。

redir-host：直接返回真实解析结果

redir-host 通常向应用返回真实 IP，兼容路径更直观，但域名与连接的关联能力取决于流量接管方式。遇到银行类应用、局域网设备或特殊协议与 fake-ip 不兼容时，可以临时切换到 redir-host 做对照。如果切换后立即恢复，优先完善 fake-ip-filter，而不是同时更换节点、规则和 DNS。

DNS 劫持与 TUN 模式怎么配置

DNS 劫持在这里指客户端把发往其他 DNS 地址的 53 端口请求转交给 Clash 内置 DNS。它解决的是应用绕过系统 DNS、直接访问固定 DNS 服务器的问题。仅配置 listen 不会改变这些数据包的目的地。

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

any:53 用于接管常见 DNS 请求，tcp://any:53 覆盖 TCP DNS。DoH 使用 HTTPS 的 443 端口，DoT 常用 853 端口，不能依靠普通的 53 端口劫持完整识别。应用内置 DoH 时，还需要通过域名规则、连接策略或应用本身的设置处理。

在 iPhone 和 iPad 上，客户端通常通过 iOS Network Extension 建立 VPN 配置。YAML 中的 tun 字段是否生效由客户端实现决定。遇到系统状态和应用状态不一致时，可到「设置」→「通用」→「VPN 与设备管理」→「VPN」确认当前连接；然后返回客户端查看日志中是否出现 DNS timeout、no such host 或上游连接失败。

配置后的验证步骤

1. 先做语法校验。 YAML 使用空格缩进，不能混入 Tab。dns、tun 应位于正确层级，列表项前保留连字符。
2. 查看监听状态。 桌面端可确认 1053 端口是否被核心监听。若端口已被其他程序占用，改为 1054 后同步修改测试命令。
3. 查询一个未缓存域名。 在可使用命令行的设备执行 dig @127.0.0.1 -p 1053 example.com A。fake-ip 模式应看到 198.18.0.0/16 范围内的地址，redir-host 模式应看到公网地址。
4. 比较首次与再次查询。 同一测试环境中，首次查询若为 1800 毫秒、再次查询为 20 毫秒，通常说明缓存正常但上游建立连接较慢；若每次都超过 2000 毫秒并超时，应检查 DoH 路径和 default-nameserver。
5. 检查规则命中。 打开一个有明确域名规则的网站，在客户端连接记录中确认显示的是域名规则，而不是意外落到 IP-CIDR 或 MATCH。
6. 清理旧缓存再复测。 修改增强模式后应重启核心或使用客户端的刷新 DNS 缓存功能。仅刷新网页可能仍在使用应用、系统或浏览器保存的旧结果。

常见误区与推荐调整顺序

把更多上游当成更稳定

上游服务器越多，路径差异、并发结果和日志噪声也越多。排查阶段先使用一个 UDP DNS 和一个 DoH，确认两者分别可达，再决定是否保留。移动网络、公司 Wi-Fi 和家庭宽带对 53、853、443 端口的限制可能不同，稳定性应以当前网络实测为准。

同时启用 fallback、policy 和大量过滤

fallback-filter、nameserver-policy 与代理规则可以共同影响一次访问。一次加入大量条件后，很难判断最终由哪条配置决定。推荐顺序是：先让 nameserver 正常工作，再选择 fake-ip 或 redir-host，然后添加少量 policy，最后才引入 fallback 筛选。

把 DNS 问题当成节点问题

DNS 查询在连接节点之前或并行发生。更换代理节点后暂时恢复，可能只是缓存被刷新或上游连接重新建立。判断时应查看日志：解析阶段出现 context deadline exceeded、no such host，优先处理 DNS；已经得到目标 IP，但代理握手超时，才继续检查节点和线路。

忽略 IPv6 的前后不一致

ipv6: false 通常表示 DNS 模块不返回 AAAA 结果，但系统、TUN 和代理节点仍可能有各自的 IPv6 设置。若网络只有不稳定的 IPv6 路由，可以先关闭 DNS IPv6 做对照；若必须访问 IPv6-only 服务，则要同时确认本地网络、节点和规则都支持 IPv6，不能只把该字段改为 true。

一份稳定配置的关键是路径清楚：用 default-nameserver 完成启动解析，用少量 nameserver 处理主要查询，确有地区筛选需求时再加入 fallback，通过 fake-ip 或 redir-host 保持域名与连接关系，最后由 TUN 或 iOS 网络扩展接管实际流量。按这个顺序调整，DNS 超时、规则未命中和局域网异常通常都能被分层定位。