进阶配置 2026-07-19 预计阅读 9 分钟

Clash DNS 配置详解:nameserver、fallback 与 DNS 劫持参数怎么填

Clash 配置文件里的 dns 段决定了域名解析走哪条路径、会不会被污染、能不能配合规则分流。本文逐项拆解 nameserver 与 fallback 的分工、fake-ip 与 redir-host 两种解析模式的差异、常见 DNS 劫持相关参数的作用,并给出可以直接套用的配置片段与验证步骤。

为什么 Clash 要自己处理 DNS

常规上网流程里,设备发起域名请求后先经过系统或路由器配置的 DNS 服务器解析出 IP,再拿着 IP 去连接目标服务器。如果这一步的 DNS 请求本身没有被代理,运营商或中间网络设备就有机会看到你在查询哪个域名,甚至返回错误的解析结果,这就是常说的 DNS 污染或 DNS 劫持。规则分流也依赖准确的域名信息:如果客户端拿到的域名对应的 IP 不可信,基于 DOMAIN-SUFFIX、GEOIP 等规则做出的分流判断就会失真。

Clash 与 Clash Meta(内核 mihomo)在配置文件里内置了一个独立的 DNS 模块,可以把域名解析这一步也纳入代理体系统一管理,而不是把解析权完全交给系统网络设置。这个模块由 dns 字段整体控制,其中 nameserver、fallback、enhanced-mode 是最核心的三个配置项,搭配得当才能既保证解析速度,又避免被污染或劫持。

DNS 段是否生效、生效到什么程度,和客户端具体实现相关,建议先确认使用的客户端(Clash Verge Rev、FlClash、mihomo 内核等)版本对 dns 字段的支持范围,再照抄配置。

nameserver 与 fallback:两组域名服务器各管什么

Clash 的 DNS 段里通常会看到两组服务器地址,分别写在 nameserver 和 fallback 字段下,它们不是简单的主备关系,而是承担不同职责的两套解析通道。

nameserver:默认解析通道

nameserver 是日常解析走的第一条通道,配置里填写的服务器地址会被用来解析绝大多数域名请求,包括规则判断本身也会用到这里返回的结果。国内场景下通常填写运营商 DNS 或公共 DNS(如 223.5.5.5、119.29.29.29),保证访问国内站点时解析速度足够快,不必绕一圈代理再回来。

fallback:兜底与国外域名解析通道

fallback 是一条兜底通道,配合 fallback-filter 使用时,常见做法是:先用 nameserver 解析域名,再检查返回的 IP 是否落在 fallback-filter.geoip-code 指定的国家段内(通常填 CN);如果不在国内 IP 段,说明这个域名很可能是需要走代理的国外站点,这时改用 fallback 里配置的境外 DNS(如 1.1.1.1、8.8.8.8)重新解析,避免用国内 DNS 解析国外域名时出现的响应慢或解析结果不准确的问题。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

其中 default-nameserver 是一条更基础的通道,专门用来解析 nameserver 与 fallback 字段里那些以域名形式书写的 DNS 服务器地址(比如某些写成域名的 DoH 地址),必须填纯 IP,不能再依赖尚未建立好的解析链路去解析自己。

fake-ip 与 redir-host:两种解析模式怎么选

enhanced-mode 决定了 Clash 把解析出来的域名信息如何交给后续的代理和规则模块处理,常见取值是 fake-ip 与 redir-host,两者的工作方式和适用场景差别很大。

fake-ip 模式

在 fake-ip 模式下,Clash 不会把域名解析出的真实 IP 直接交给应用程序,而是先返回一个虚拟的、位于私有地址段内的假 IP。应用程序拿着这个假 IP 发起连接后,流量会先进入 Clash,由 Clash 在内部把假 IP 映射回原始域名,再根据规则决定真正的出口和目标地址。这种模式的好处是解析速度快、能配合 TUN 模式做到全局透明代理,几乎是目前桌面客户端和路由器场景的默认选择。缺点是部分对 IP 有强依赖的应用(比如某些需要校验直连 IP 的服务、局域网设备发现)可能出现异常,这时通常需要在配置里为对应域名或 IP 段单独设置直连规则,或者把这些域名加入 fake-ip-filter 排除列表,让它们跳过假 IP 处理。

redir-host 模式

redir-host 模式则是老式做法:Clash 直接把域名解析成真实 IP 返回给应用程序,代理判断依赖的是应用程序连接时携带的 Host 头或 SNI 信息。这种模式兼容性更好,不容易出现假 IP 带来的兼容性问题,但解析和转发效率不如 fake-ip,且对不携带明确域名信息的协议(比如部分基于纯 IP 通信的应用)分流准确度会下降。目前主流 Clash Meta / mihomo 内核客户端已经把 fake-ip 作为推荐配置,redir-host 更多是历史配置或特殊兼容场景下的备选项。

切换 enhanced-mode 后建议重启客户端或重新加载配置,部分实现下解析缓存不会自动清空,可能出现切换后短时间内解析结果仍是旧模式的现象。

DNS 劫持相关参数怎么理解与配置

除了 nameserver 与 fallback 的基本分工,Clash 的 DNS 段还提供了几个专门用于对抗 DNS 劫持、提升解析安全性的参数,理解它们的作用能帮助排查“网页打不开但代理明显在工作”这类问题。

使用加密 DNS 协议

直接用普通的 udp:// 明文 DNS 请求,依然存在被中间网络设备篡改或阻断的风险。把 nameserver 或 fallback 里的地址换成 tls://(DNS over TLS)或 https://(DNS over HTTPS)前缀,可以让 DNS 请求本身走加密通道,减少被劫持篡改的机会。例如 https://1.1.1.1/dns-query 或 tls://8.8.8.8:853 都是常见写法,大多数 mihomo 内核客户端都原生支持这两种前缀。

listen 与劫持局域网 DNS 请求

dns.listen 字段用来指定 Clash 内置 DNS 服务监听的本机端口(比如 0.0.0.0:1053),配合系统代理或 TUN 模式的 DNS 劫持开关,可以把设备本身发出的 DNS 请求强制拦截并转交给 Clash 处理,而不是绕过 Clash 直接打到系统配置的 DNS 服务器上。如果发现某些应用的域名请求完全没有走代理规则,往往就是因为这个劫持环节没生效,应用程序用了硬编码的 DNS 地址,绕开了系统解析入口。

nameserver-policy 精细化分流

对于个别域名需要走特殊 DNS 服务器解析的场景(比如公司内网域名必须用内网 DNS,不能走公共 DNS 解析出错误结果),可以用 nameserver-policy 针对具体域名或域名后缀单独指定解析服务器,优先级高于全局的 nameserver 配置:

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.internal":
      - 10.0.0.53

这类配置常用于混合办公、内外网并存的环境,避免内网服务因解析走错通道而无法访问。

验证 DNS 配置是否真正生效

写完配置后不能只靠“网页能打开”这种模糊判断,建议按下面的步骤逐项核实。

  1. 查看客户端的连接日志或 DNS 查询记录:多数图形化客户端(如 Clash Verge Rev)在“连接”或“日志”面板里能看到实时的域名解析请求,确认目标域名确实经过了 Clash 处理,而不是绕过。
  2. 用命令行工具核对解析结果:在终端执行 nslookup 目标域名 127.0.0.1 -port=1053(端口需替换为实际 dns.listen 设置的端口),看返回的是假 IP 还是真实 IP,与预期的 enhanced-mode 一致即可。
  3. 测试国内外站点的分流是否符合预期:分别访问一个明确的国内站点和一个明确的国外站点,结合规则日志确认前者走了直连、后者走了代理节点,而不是两者都走同一条路径。
  4. 检查是否存在解析泄漏:部分应用会内置自己的 DNS 逻辑绕开系统设置,如果怀疑某个应用泄漏了真实解析请求,可以临时关闭该应用的网络权限或用防火墙规则单独观察其 DNS 流量,确认是否真的被劫持进了 Clash。
配置项作用常见取值
nameserver默认解析通道,处理大部分请求223.5.5.5、119.29.29.29
fallback兜底通道,配合过滤器处理境外域名tls://1.1.1.1:853
fallback-filter判断解析结果是否需要切到 fallbackgeoip-code: CN
enhanced-mode决定 fake-ip 或 redir-host 解析模式fake-ip
nameserver-policy为特定域名指定专用解析服务器按域名/后缀映射

建议先用一份成熟客户端自带的默认 DNS 配置作为基线,确认基础规则正常运作后,再按自己的网络环境逐项微调 fallback 与 nameserver-policy,避免一次改动过多参数导致排查困难。

常见误区与排查思路

实际配置过程中,几个误区容易反复出现,提前了解可以省掉不少排查时间。

  • 把 fallback 当成主 DNS 使用:如果 fallback-filter 配置不当或缺失,可能导致所有请求都被判定为需要走 fallback,国内站点解析速度反而变慢,这种情况需要检查 geoip-code 是否正确填写。
  • 混用未加密与加密 DNS 却没有统一超时策略:加密 DNS 请求耗时通常略高于明文请求,如果客户端超时设置过短,可能出现解析间歇性失败,可以适当调整客户端的 DNS 超时参数或减少 fallback 列表里的服务器数量。
  • 忽略 IPv6 对解析结果的影响:部分网络环境启用了 IPv6,如果 Clash 的 ipv6 字段与系统实际网络状态不匹配,可能出现解析出的 IP 类型与实际可用连接方式不一致,建议按自己的网络环境显式声明 ipv6: true 或 false,不要留空。
  • 规则里用了 IP 段判断但解析模式是 fake-ip:fake-ip 模式下应用程序拿到的是假 IP,如果规则严重依赖真实 IP 段(如 GEOIP),需要确认客户端内核在做规则匹配时是否已经把假 IP 还原成真实 IP 再判断,不同实现的处理顺序可能有差异,遇到匹配异常时可以先切到 redir-host 模式对比验证。

DNS 段的配置不需要一次到位,先用基础的 nameserver + fallback + fake-ip 组合跑起来,再根据实际使用中遇到的具体问题(某个应用连不上、某个内网服务解析错误)逐项加参数修正,通常比一开始就堆砌所有可选字段更容易维护。

下载客户端