很多人第一次接触 Clash 的 DNS 配置时会有点懵：内核自己有一套 DNS 模块，客户端还能选「系统代理」或「TUN」，网站到底是怎么被解析出来的？这篇文章从原理讲起，帮你把 dns 这一段配置真正读懂。

为什么代理工具还要管 DNS

如果域名解析走的是本地运营商 DNS，即使流量最终通过节点转发，解析结果也可能已经被污染或返回了不准确的 IP，导致规则分流命中错误的地区判断（比如 GEOIP,CN 误判）。所以 Clash 内置了 DNS 模块，接管解析过程，让「解析」和「转发」都在自己的可控范围内。

两种解析模式：redir-host 与 fake-ip

这是配置 DNS 前最需要搞清楚的一对概念，二者的核心区别在于「客户端拿到的 IP 是不是真实的」。

模式解析结果适用场景
redir-host真实公网 IP兼容性最好，适合有些应用需要拿到真实 IP 做校验的场景
fake-ip虚拟的私有段 IP解析速度快、避免 DNS 泄露，是目前的主流推荐配置
dns: enable: true enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter: - "*.lan" - "+.local"
局域网设备发现、部分游戏联机或内网服务，如果解析异常，优先检查是不是被 fake-ip 影响了，可以把对应域名加入 fake-ip-filter 排除。

接入 DoH / DoT，避免上游 DNS 被污染

如果 nameserver 只配置了明文的 UDP DNS（如 8.8.8.8），请求本身在链路上还是可能被劫持或篡改。加密 DNS（DoH/DoT）把查询包装进 HTTPS/TLS，能有效降低被污染的概率。

dns: nameserver: - https://dns.alidns.com/dns-query # DoH - tls://dns.google # DoT fallback: - tls://1.1.1.1 - tls://8.8.8.8 fallback-filter: geoip: true geoip-code: CN

nameserver 是默认解析组，fallback 是当默认解析结果落在指定地区外（通过 fallback-filter 判断）时才会用到的备用解析组，通常配置为速度快、抗污染能力强的境外 DNS。

nameserver-policy：按域名指定 DNS

如果只想让特定域名走特定 DNS（比如内网域名走本地 DNS，其余走加密 DNS），可以用 nameserver-policy 单独指定：

dns: nameserver-policy: "example.internal": "192.168.1.1"

IPv6 双栈环境下要注意什么

如果本地网络同时具备 IPv4 和 IPv6，且运营商的 IPv6 出口质量一般，很多时候反而会拖慢访问速度——浏览器按照 Happy Eyeballs 机制会同时尝试两种协议，但 Clash 默认可能没有对 IPv6 解析做特殊处理。可以通过 ipv6 字段显式控制是否解析并使用 IPv6 结果：

dns: ipv6: false # 关闭 IPv6 解析，避免走质量较差的 IPv6 链路

如果你的 IPv6 出口本身质量不错，也可以保留开启，并让 fake-ip 同时覆盖 IPv4/IPv6 两套结果，具体取舍建议实际测速对比后再决定，而不是照抄某一份「万能配置」。

DNS 与本地 hosts 的优先级

部分场景下（比如自建服务测试、临时屏蔽某个域名）会想直接编辑系统 hosts 文件。需要注意的是，一旦 Clash 接管了 DNS（dns.enable: true），系统 hosts 里的映射不一定会被内核感知到，因为解析请求可能根本没有经过系统的 resolver。这种场景下更推荐直接在 Clash 配置里加一段 hosts 字段，效果等价但作用域更明确：

hosts: "my.local.test": "192.168.1.20"
Clash 里配置的 hosts 优先级通常高于常规的 DNS 解析流程，适合做本地开发环境的域名映射，而不必再去改系统级 hosts 文件。

不同客户端的 DNS 设置界面差异

图形化客户端通常会把 dns 这段配置封装成「基础」「进阶」两级开关：基础模式下只暴露一个「增强模式」的下拉选择（对应 enhanced-mode），进阶模式才会展示 nameserver、fallback 等具体字段。如果你在客户端界面上找不到某个字段，一般还是可以通过直接编辑配置文件（或者叫「配置」里的原始 YAML 编辑入口）来补充，客户端读取配置时并不会因为界面没展示而忽略这部分内容。

域名解析异常的排查思路

  1. 先确认 DNS 模块是否开启：dns.enable 为 false 时，Clash 不会接管解析，交由系统处理。
  2. 检查是否命中了错误的规则：部分域名规则写在了 DIRECT 之前，导致该走代理的域名被直连解析。
  3. 怀疑 fake-ip 冲突：内网设备、局域网打印机、游戏主机发现异常时，先把对应域名加进 fake-ip-filter。
  4. 用外部工具交叉验证：在开启/关闭代理两种状态下分别执行 nslookup 或访问在线 DNS 检测工具，对比解析结果差异。
修改 DNS 配置后建议重启内核或点击客户端里的「重新加载配置」，部分客户端不会自动热更新 DNS 模块。

移动端要不要单独调整

手机端因为经常在 WiFi 和移动网络之间切换，DNS 缓存的表现会比桌面端更「敏感」一些：切换网络后如果发现某个网站解析出的还是切换前的结果，往往不是配置问题，而是系统或客户端本身缓存了上一次的解析记录，等待缓存过期或手动重启一次代理服务即可。移动端应用商店里的部分客户端出于省电考虑，会限制后台重连频率，如果长时间挂起后遇到解析异常，也可以先尝试完全退出客户端再重新打开。

TUN 模式下 DNS 的表现有什么不同

开启 TUN 模式后，系统层面所有流量（包括 DNS 查询）都会经由虚拟网卡接管，理论上比传统的系统代理模式覆盖更完整，能拦截到一些不遵循系统代理设置的应用（例如部分使用了自定义 DNS 解析库的程序）。但这也意味着一旦 DNS 配置出错，影响范围会更大——因此建议先在系统代理模式下把 dns 配置调试稳定，再切换到 TUN 模式验证效果，而不是一开始就在 TUN 模式下反复试错。

小结

日常使用直接用 fake-ip + 加密 DNS 上游就已经能覆盖绝大多数场景；只有遇到内网发现、特定协议异常时才需要精细调整 fake-ip-filter 或 nameserver-policy。把这套逻辑理清楚后，「网页打不开却能测速」这类问题基本都能自己排查定位。