进阶配置 预计阅读 14 分钟

Clash DNS 配置详解：nameserver、fallback 与 DNS 劫持处理

梳理 Clash DNS 请求路径、主备解析器分工、fallback 过滤条件及常见异常的排查顺序。

先确认 DNS 请求实际经过哪里

Clash 的代理规则负责决定连接走直连、代理还是拒绝，但规则判断之前通常还存在域名解析过程。浏览器访问一个域名时，应用可能先调用操作系统解析器，也可能通过内置的加密 DNS 直接发起查询。操作系统解析器再把请求交给网卡指定的 DNS、路由器或 Clash 的本地监听端口。只有请求真正进入 Clash DNS 模块，配置中的 nameserver、fallback 和 fake-ip 才会生效。

常见请求路径可以概括为：应用提交域名，系统或 TUN 接管 DNS 查询，Clash 根据策略选择上游解析器，取得地址后匹配代理规则，最后建立直连或代理连接。若应用绕过系统解析器，或者局域网设备仍把 DNS 发给路由器，那么修改 Clash 配置不会改变这些请求的结果。

仅开启系统代理时，HTTP 与 HTTPS 流量可以进入 Clash，但 DNS 不一定同步进入。部分浏览器会在本地完成解析，部分 SOCKS 客户端则能把域名交给代理端解析。TUN 模式覆盖范围更大，可以通过路由和 DNS 劫持接管不遵循系统代理设置的程序，但仍要处理浏览器安全 DNS、虚拟机独立网络和局域网其他设备等例外。

一次查询涉及的四个层次

  1. 应用层：浏览器、命令行工具或其他软件决定使用系统 DNS、内置 DoH，还是把域名交给 SOCKS 代理。
  2. 系统层：操作系统缓存、网卡 DNS、VPN 接口优先级和本机 hosts 都可能在 Clash 之前产生结果。
  3. Clash DNS 层：监听端口、增强模式、主备解析器与域名策略决定查询方式和返回内容。
  4. 连接层：Clash 使用域名、目标地址与规则集选择出站，节点域名本身也可能需要额外解析。

排查时按层次向下推进，比反复更换公共 DNS 更有效。尤其要注意缓存：浏览器、操作系统和 Clash 都可能保存解析结果。修改配置后如果立即测试同一域名，旧结果可能掩盖配置变化。应先重新加载配置，再清理相关缓存或等待记录过期。

dns、default-nameserver 与 nameserver 的职责

一个便于理解的基础配置如下。字段支持情况会随原版 Clash、Clash Meta（现常称 mihomo）以及客户端集成版本而变化，实际使用时应以当前内核文档和配置校验结果为准。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

enable 与 listen

enable: true 启用内核 DNS 模块。listen 指定本地监听地址与端口；监听 0.0.0.0 表示允许从所有网络接口接收请求，因此在桌面设备上还应结合防火墙限制外部访问。如果只供本机显式使用，可以考虑监听回环地址。TUN DNS 劫持由内核转发时，具体监听方式取决于客户端和内核实现。

端口冲突是配置无法启动的常见原因。53 端口可能已被系统服务、容器工具或其他 DNS 程序占用，因此桌面客户端经常使用 1053 等非特权端口，再由 TUN 或系统设置把请求导入。不要在未确认占用情况时同时启动两个本地 DNS 服务。

default-nameserver：为上游域名提供引导解析

当 nameserver 使用 DoH 或 DoT 域名时，内核必须先知道这些上游主机的 IP，才能建立加密连接。default-nameserver 主要承担这一步引导解析，也常参与代理节点域名的初始解析。为了避免“解析 DNS 服务器还需要先访问同一 DNS 服务器”的循环，兼容性优先的配置通常在这里填写可直接访问的 IP 地址。

default-nameserver 不是普通域名查询的主要答案来源。把大量解析器都堆进这个列表不会自动提升速度，反而会增加结果差异和排查难度。选择少量、网络可达且响应稳定的解析器即可。

nameserver：默认主解析器

nameserver 是常规查询的主要上游，可以使用普通 UDP DNS，也可以在内核支持时使用 DoH、DoT 等形式。不同解析器对 CDN 地址、IPv6 记录和污染环境的表现可能不同。将多个上游放在同一列表时，内核通常会并行或按内部策略请求，但这不等同于固定顺序的逐个备用机制。

解析器数量不宜过多。上游越多，越容易出现同一域名返回不同 CDN 地址、故障难以复现或部分请求绕过预期路径。配置初期可以只保留一个主解析器和一个独立备用解析器，确认链路稳定后再增加冗余。

fallback 与 fallback-filter 如何配合

fallback 并不是简单的“主服务器超时后再问备用服务器”。在经典 Clash 配置语义中，主解析器和备用解析器可能同时参与查询，随后由 fallback-filter 判断当前域名或主解析结果是否应该采用备用答案。因此，理解过滤条件比单纯添加备用地址更重要。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.githubusercontent.com"

geoip 与 geoip-code

启用 geoip 后，内核会根据主解析结果的地址归属判断是否采用 fallback 结果。以 geoip-code: CN 为例，主解析结果不符合指定区域时可能切换到备用答案。这种方式适合处理部分跨区域解析差异，但它依赖 GeoIP 数据库的准确性。云服务、Anycast、CDN 与新分配地址可能被归类到意料之外的区域，不能把地理判断当作绝对结论。

geosite 与 domain

geosite 可按域名集合指定 fallback 倾向，具体集合是否可用取决于内核和规则数据。domain 则适合加入少量需要明确使用备用解析器的域名。带 +. 的写法通常表示匹配根域及其子域，但不同版本对域名匹配格式的兼容范围需要通过配置校验确认。

不建议把大量站点逐条复制进 domain。列表越长，维护成本越高，也容易与 nameserver-policy、规则集或订阅配置产生冲突。若使用 mihomo，可以优先评估按域名指定解析器的策略字段，让用途更直观。

ipcidr

ipcidr 用于把特定地址范围视为异常或需要 fallback 的结果。例如保留地址段不应该作为普通公网域名的有效响应时，可以加入过滤条件。该字段应针对明确观察到的问题使用，而不是从不明来源复制大量网段。过滤范围过宽可能让正常 CDN 地址持续落入备用路径，增加延迟并造成结果波动。

使用 fallback 时的取舍

mihomo 中更细的解析器分工

mihomo 在 Clash 配置体系上扩展了 DNS 控制字段，常见的包括 nameserver-policy、proxy-server-nameserver 和 direct-nameserver。这些字段适合解决“业务域名、代理节点域名和直连域名不应共用同一解析路径”的问题，但并非所有旧版客户端都能识别。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.example.net":
      - https://cloudflare-dns.com/dns-query

proxy-server-nameserver 主要用于解析代理节点服务器自身的域名。节点尚未建立连接时，不能依赖必须经过该节点才能访问的 DNS，否则会形成启动循环。节点域名解析应选择当前网络可以直接到达的上游。

direct-nameserver 用于直连出站相关的域名解析，可以让直连站点采用更贴近本地网络的答案。是否启用、何时调用以及与规则匹配的关系会受到内核版本和 DNS 配置影响，迁移配置时应检查运行日志，而不是只看 YAML 是否能载入。

nameserver-policy 根据域名或规则集合指定上游，表达能力比统一的主备结构更直接。例如本地区域域名交给本地解析器，特定业务域名交给另一组加密解析器。策略之间可能存在覆盖关系，配置时应先写出预期矩阵：哪类域名、经哪个上游、对应什么出站，再逐项验证。

fake-ip 与 redir-host 的选择

enhanced-mode 决定 Clash 如何把 DNS 查询和后续连接关联起来。常见模式是 fake-ip 与 redir-host。两者都用于帮助内核保留域名信息，但工作方式不同。

fake-ip：返回保留地址并建立域名映射

在 fake-ip 模式下，Clash 为查询分配一个保留地址，例如来自 198.18.0.0/16 的地址段，并记录这个地址与原始域名的映射。应用随后连接该地址时，流量被 Clash 接管，内核根据映射恢复域名并执行规则。它通常具有较好的域名规则命中能力，也能减少先取得真实地址再判断的歧义。

fake-ip 地址只在 Clash 接管链路中有意义。若流量没有进入 Clash，系统或其他设备直接尝试访问这个保留地址，连接就会失败。局域网发现、打印机、游戏主机、企业认证、时间同步和部分依赖真实 DNS 回答的程序也可能与 fake-ip 不兼容。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
    - "time.*.gov"

fake-ip-filter 中的域名会跳过 fake-ip 返回方式，改为取得真实地址。过滤项应从实际故障出发逐步添加。直接使用过大的通配范围会削弱 fake-ip 的域名映射优势，还可能使部分请求在连接前发生本地解析。

redir-host：返回真实地址

redir-host 模式通常向客户端返回真实 IP，并在连接阶段尽量关联域名。它对依赖真实地址的设备和程序更友好，但在复杂转发、连接复用或只剩目标 IP 的场景中，域名规则识别能力可能不如 fake-ip 稳定。具体行为还会受到 sniffing、TUN 栈与内核版本影响。

桌面日常使用可以先测试 fake-ip；遇到局域网服务、企业网络或特定应用不兼容时，优先添加精确过滤项。如果问题范围广且无法稳定过滤，再评估 redir-host。切换模式后应清理 DNS 缓存并重启相关应用，因为旧 fake-ip 记录不会立即从所有缓存层消失。

TUN 模式中的 DNS 劫持处理

这里的“DNS 劫持”是 TUN 配置中的流量接管功能：把发往指定端口的 DNS 请求重定向给 Clash DNS 模块，而不是指运营商篡改解析结果。它解决的是应用仍向网卡 DNS 或路由器发送 53 端口查询的问题。

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

any:53 表示接管目标为任意地址、端口为 53 的传统 DNS 请求。不同内核版本还可能支持其他格式。客户端图形界面若已经自动生成 TUN 设置，不应同时在多个位置重复定义，否则可能出现配置覆盖或启动失败。

传统 DNS 劫持通常只能覆盖 UDP 或 TCP 53 端口，不能自动拦截浏览器直接访问外部 HTTPS 地址的 DoH，也不能把所有 DoT 请求透明改写。浏览器启用独立安全 DNS 后，查询表现可能与系统工具不同。排查时可以暂时让浏览器使用系统解析器，确认 Clash 路径稳定后，再决定是否保留浏览器内置设置。

常见接管失败场景

旁路由环境还要确认 DHCP 下发的网关与 DNS。仅把 DNS 地址指向旁路由，不代表所有连接都会经过旁路由；仅把网关指向旁路由，也不保证终端不会使用自定义加密 DNS。网关、DNS、转发规则和防火墙应作为同一条路径检查。

解析异常的分步排查顺序

DNS 故障表现相似，但原因可能位于不同层次。以下顺序从配置载入、监听状态、上游访问一路检查到规则和缓存，适合处理“网页打不开”“部分域名超时”“TUN 开启后无法解析”以及“同一站点结果反复变化”等问题。

第一步：确认配置已经被当前内核接受

先查看客户端日志和配置状态，确认 YAML 缩进、字段类型和协议地址没有错误。尤其注意列表缩进、冒号后的空格、域名规则中的特殊字符以及旧内核不支持的新字段。图形客户端可能同时存在订阅原始配置、覆写配置和运行时合并配置，应以最终生效配置为准。

第二步：确认本地 DNS 端口正在监听

检查配置指定的地址和端口是否存在监听进程。如果端口被其他程序占用，Clash DNS 模块可能启动失败，而代理核心的其他功能仍然运行。此时系统代理看似正常，依赖域名解析的连接却会失败。更换端口后，还要同步修改系统 DNS 转发或 TUN 接管设置。

第三步：分别测试主解析器和备用解析器

暂时只保留一个 nameserver，关闭复杂过滤策略，验证普通域名是否能稳定解析。然后单独测试 fallback 上游。若 DoH 无法连接，检查其主机名是否能通过 default-nameserver 完成引导解析，以及当前网络是否允许访问对应地址和端口。

第四步：检查节点域名的启动循环

如果代理节点使用域名，而 DNS 上游又必须通过该节点访问，内核启动时可能无法解析节点，继而无法建立代理，再导致 DNS 上游不可达。处理方式是为节点域名使用当前网络可直连的引导解析器，mihomo 用户还可以核对 proxy-server-nameserver。

第五步：检查 fallback-filter 是否过宽

临时移除 geosite、domain 和大范围 ipcidr，只保留最小配置。若问题消失，再逐组恢复条件。某个域名频繁在不同解析结果间变化时，应记录主备上游各自返回的地址及过滤判断，而不是继续增加备用服务器。

第六步：确认 fake-ip 流量确实进入 Clash

如果查询返回 198.18.0.0/16 一类地址，说明 fake-ip 正在工作。随后连接失败通常表示对应流量没有被 TUN、透明代理或系统代理正确接管。此时重点检查路由和应用代理方式，而不是更换 DNS。若只有个别局域网或认证域名异常，可把它们精确加入 fake-ip-filter。

第七步：处理 IPv6 不一致

ipv6: false 通常会限制 Clash DNS 返回 AAAA 结果，但系统、浏览器或其他解析器仍可能取得 IPv6 地址。如果网络存在不完整的 IPv6 连通性，应用可能优先尝试 IPv6 后超时。应确认系统 IPv6、Clash DNS 设置、TUN 路由与代理节点能力是否一致，而不是只改一个开关。

第八步：清理缓存并使用同一测试条件复查

重新加载配置后，清理浏览器和操作系统 DNS 缓存，关闭再启动目标应用。测试时固定网络、域名、运行模式和策略组，避免同时切换多个变量。先验证 DNS 返回，再验证 Clash 日志中的规则命中和出站选择，最后检查连接是否建立。

长期稳定的配置不依赖解析器数量，而依赖清楚的职责边界。建议先建立最小可用结构：一组可直连的引导解析器、一组默认主解析器、必要时一组 fallback，再根据明确需求加入策略解析和 fake-ip 过滤。

  1. 先确定当前客户端使用的内核名称与版本，避免直接套用不支持的字段。
  2. 让 default-nameserver 保持简短，用于解决加密 DNS 与节点域名的引导问题。
  3. 为 nameserver 选择稳定可达的主要上游，不混入用途不明的地址。
  4. 只有在确实存在解析差异时启用 fallback，并为过滤条件记录原因。
  5. 使用 fake-ip 时维护小而精确的过滤列表，定期删除已不需要的例外。
  6. TUN 环境同步检查 DNS 接管、路由、IPv6 与浏览器内置安全 DNS。
  7. 每次只修改一组字段，保留可回退的原始配置，并通过日志验证实际路径。

订阅提供的配置可能已经包含 DNS 段。客户端覆写功能如果再次添加同名字段，最终结果可能是替换、合并或完全忽略，具体取决于客户端实现。更新订阅前应确认自定义 DNS 位于独立覆写中，还是直接写进订阅副本；更新后则检查最终配置，防止自定义内容被覆盖。

对于多数桌面场景，优先解决“请求是否进入 Clash”和“上游是否可达”两个问题，再优化 fallback 与策略分流。对于旁路由和多设备网络，则要额外确认 DHCP、默认网关、终端自定义 DNS 与 IPv6 出口。把解析路径画成从应用到上游的顺序图，通常比不断增加配置字段更容易定位故障。

下载Clash