Clash DNS 解析失败与 DNS 泄漏：配置核对指南
核心核对
确认 dns.enable 已开启，监听端口没有冲突，并使用可访问的上游解析器。用同一域名分别测试系统解析和客户端解析，避免把缓存差异误判为泄漏。
兼容性
局域网域名、公司内部域名应指定直连解析或遵循管理员 DNS。修改模式后清理缓存并重启应用，逐项验证。
从真实日志识别 DNS 根因
公开问题 #1716 中的关键错误是 dns resolve failed: all DNS requests failed，其首个下游错误为 UDP 读取 i/o timeout。它说明“连接超时”可能发生在解析阶段，而不是节点握手阶段。保留完整日志在本机，公开工单只提供脱敏片段：
level=warning msg="... dns resolve failed: all DNS requests failed,
first error: read udp [local-ip]:[port]->[dns-ip]:53: i/o timeout"在 Linux/macOS 上先以只读命令确认默认解析器和实际结果：
resolvectl query example.com 2>/dev/null || scutil --dns
dig +time=2 +tries=1 example.com
dig @127.0.0.1 -p 1053 +time=2 +tries=1 example.com只有本地监听端口成功、默认解析失败时，再检查 TUN DNS 接管与防火墙；两者都失败时，才考虑上游 DNS、网络出口或名称本身。不要为“修复泄漏”关闭证书验证或把凭据写进 YAML。
诊断范围
“Clash DNS 解析失败与 DNS 泄漏：配置核对指南”应先按可观察现象缩小范围：处理 Clash 域名打不开、解析慢或担心 DNS 未按预期走向的问题。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。
操作步骤
- 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
- 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
- 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。
验证与回退
完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。
来源与适用边界
本页的“证据与参考”只用于说明已公开的配置说明或个案范围；它不能证明你的网络、账号、节点或服务端当前处于同一状态。将日志中的令牌、订阅地址、账户资料和网络标识删除后再用于比对。
来源与更新
本文的实际现象与命令依据下列公开来源整理；示例中的地址和标识符均已脱敏。
排查顺序
- 记录症状确认客户端、系统、错误文本与发生范围。
- 低风险核对先检查本文对应的配置、权限、网络或版本条件。
- 复测与回退只改变一项；现象变化后再决定是否继续。
常见问题
修改 DNS 后所有网站打不开？
先恢复已验证的默认 DNS，再检查监听地址与防火墙规则。
fake-ip 一定更好吗？
取决于应用兼容性；局域网设备和部分应用可能更适合 redir-host。
确认结果、回退与日志
每次只修改一项并复测原始现象。若出现新错误，恢复导出的配置或关闭刚启用的开关；仍未解决时，请保留客户端与系统版本、错误文本、发生时间、已尝试步骤以及脱敏日志。
不要公开订阅地址、账号或完整连接信息。文中的命令与配置片段仅适用于其标注的客户端和系统；未提供命令时，请以来源中的官方界面或系统文档为准。
补充更新：按解析链路排查 Clash DNS 失败与泄漏
简答：Clash DNS 解析失败先确认是系统、浏览器还是 mihomo 在解析，再核对 dns.enable、listen、enhanced-mode、nameserver 与 TUN 劫持；用日志、nslookup 或 dig 和实际访问结果交叉验证，不能只看泄漏检测页。
定义：Clash DNS 泄漏是域名请求绕过客户端预期的 DNS 处理链路，直接由系统、浏览器、路由器或其他解析器发出；解析失败则是请求未获得可用的 DNS 响应。
先按现象定位：不要一上来更换 DNS
更新于 2026-10-22。先记录一个失败域名、使用的模式、是否开启 TUN，以及客户端日志中是否出现解析超时。mihomo 的 DNS 模块由 dns.enable 控制；关闭时会使用系统 DNS，enhanced-mode 支持 fake-ip 和 redir-host。这些字段应以最终运行配置为准，而不是只看订阅原文。mihomo DNS 配置文档
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 所有域名都无法解析 | dns.enable、listen、上游 DNS 是否可达 | 查看日志，再用系统命令测试默认 DNS |
| 只有部分域名失败 | nameserver-policy、fallback、IPv6 与规则 | 对同一域名分别测试 A、AAAA 和不同解析器 |
| 网页能开但检测页显示运营商 DNS | 浏览器 DoH、系统 DNS、TUN 是否重复或绕行 | 暂时关闭浏览器独立 DoH，重启客户端后复测 |
| 仅内网域名或局域网设备异常 | fake-ip-filter、nameserver-policy 与内网 DNS | 为内网域名保留真实解析或指定内网解析器 |
| 节点域名无法解析 | proxy-server-nameserver | 先给节点域名配置可用的专用解析器，避免解析依赖代理本身 |
最小改动核对：先看最终运行配置
如果使用 mihomo 内核，可先保留一份当前配置，再只核对 DNS 相关字段。官方示例说明，nameserver-policy 优先于普通 nameserver 和 fallback 查询；proxy-server-nameserver 仅用于解析代理节点域名，不能把它当成所有网站的默认 DNS。字段说明与官方示例
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-filter:
- '*.lan'
- '*.local'
nameserver:
- https://dns.example.invalid/dns-query
proxy-server-nameserver:
- 223.5.5.5
上面的 dns.example.invalid 只是占位符，不能直接使用。应替换为你所在网络实际可访问、并符合组织策略的解析器；查不到可用地址时，不要把示例地址当作保证。若怀疑 fake-ip 与某个内网应用不兼容，可临时改为 redir-host 做单变量对照，确认结果后再决定是否回退。
使用 TUN 时，官方文档说明 dns-hijack 会把匹配的 DNS 连接导入内部 DNS 模块；但在 Windows 和 macOS 上，mihomo 不能自动劫持发往局域网的 DNS 请求，Android 开启 Private DNS 时也可能无法自动劫持。mihomo TUN 与 DNS 劫持说明
可复现验证：系统解析、客户端日志与浏览器分别测试
- 先测本地网络：关闭客户端或暂时停用 TUN，确认普通网络可以访问测试域名；如果此时也失败，先处理 Wi-Fi、路由器、系统 DNS 或企业网络策略。
- Windows 测试：在命令提示符执行
nslookup example.com，再指定解析器执行nslookup example.com 1.1.1.1。Microsoft 文档说明，nslookup可用于诊断 DNS 基础设施，未指定服务器时使用系统默认 DNS。Microsoft nslookup 文档 - macOS 或 Linux 测试：使用
dig example.com和dig @解析器地址 example.com，比较响应是否超时、返回 SERVFAIL，或只缺少 AAAA 记录。不要把单次缓存命中当成完整结论。 - 再启用客户端：确认配置已成功加载，观察 DNS 日志是否出现超时、拒绝、无上游响应或端口占用；随后直接访问同一目标站点，记录是否能建立连接。
- 最后测浏览器：浏览器可能拥有独立的安全 DNS。Firefox 可在“设置—隐私与安全—DNS over HTTPS”中调整保护级别；Chrome 也提供“使用安全 DNS”选项。排查时可暂时关闭该功能进行对照，恢复正常后再决定是否启用。Firefox DNS over HTTPS 说明 Chrome 安全 DNS 说明
验证标准应至少包含两项：目标域名能够解析并访问，以及客户端日志显示请求走了预期链路。在线 DNS 检测页只能作为辅助信号，不能单独证明所有应用、所有协议都没有绕行；还要结合浏览器设置、TUN 状态、系统解析结果和实际访问进行交叉判断。
固定排障顺序与回退动作
- 本地网络：先换一个网络或关闭其他 VPN、代理和安全软件，排除多个网络接管者同时运行。
- 系统时间：检查日期、时区和自动校时。加密 DNS 或节点连接出现证书错误时，时间偏差会影响握手；修正后重启客户端复测。
- 订阅状态：确认订阅未过期、更新请求没有返回错误，且最终配置确实包含 DNS 设置。
- 节点与解析器：区分“节点域名解析失败”和“网站域名解析失败”，前者优先检查
proxy-server-nameserver。 - DNS、MTU 与 IPv6：一次只改一个变量。先临时关闭 IPv6 或将
enhanced-mode改为另一模式对照；若 DNS 能解析但连接仍超时，再单独排查 MTU。 - 系统代理与 TUN 权限：确认只有一个客户端接管系统代理或虚拟网卡，检查防火墙、网络扩展、VPN 权限和 DNS 劫持状态。mihomo 官方文档还提醒，Windows 的 TUN 严格路由可用于阻止普通多宿主 DNS 解析造成的泄漏，但也可能改变局域网访问行为。TUN 路由与 strict-route 说明
每次修改前保存原配置；如果改动后现象扩大，立即恢复上一份配置并重启客户端。日志截图或配置片段发给他人前，应删除订阅链接、节点地址、用户名、密码、令牌和外部控制器密钥。
哪些情况不应直接判定为 DNS 泄漏
规则模式下，国内站点显示本地出口或本地解析结果，可能是规则和直连策略正常生效，不等同于 DNS 泄漏。相反，如果浏览器使用独立 DoH、系统启用了 Private DNS、路由器强制转发 53 端口，或多个客户端同时运行，仅查看 Clash 面板并不能覆盖全部解析路径。
判断时建议采用“同一域名、同一网络、同一时间段、关闭缓存后重复测试”的方法，并把系统命令、客户端日志、浏览器设置和实际访问结果放在一起比较。没有抓包或完整日志时，只能写成“检测结果显示某解析器”，不要扩大为“所有 DNS 请求都泄漏”。
常见问题
Clash DNS 解析失败时，先改 nameserver 还是先改 fake-ip？
先看日志和现象。所有域名都失败时先检查 dns.enable、listen 和上游可达性；只有内网或特定应用异常时，再用 redir-host 与 fake-ip 做单变量对照。mihomo 将两者定义为不同的 DNS 处理模式，不能把改模式当成通用修复。
DNS 检测显示运营商 DNS，就一定是 Clash DNS 泄漏吗？
不一定。检测页可能只观察到某一条解析路径，浏览器 DoH、系统 DNS、路由器转发和 TUN 劫持都可能影响结果。应同时查看客户端日志、浏览器安全 DNS 设置，并用同一域名重复验证。
Windows 怎么确认 DNS 是否真的解析失败？
先执行 <code>nslookup example.com</code>，再指定服务器执行 <code>nslookup example.com 解析器地址</code>。如果默认 DNS 超时而指定服务器成功，问题更可能在系统或网络提供的解析器；如果两者都失败，再检查本地网络、客户端和上游可达性。
fake-ip 会导致局域网设备或公司内网域名打不开吗？
有可能出现兼容性差异，尤其是局域网域名、内网设备和依赖真实地址的应用。可将相关域名加入 fake-ip-filter，或为内网后缀配置 nameserver-policy；修改前先确认管理员提供的内网 DNS。
开启 TUN 后仍然出现 DNS 泄漏，应该查哪里？
先查 dns-hijack、auto-route、strict-route 和防火墙权限，再查 Windows、macOS 或 Android 的特殊限制。官方文档明确列出部分平台不能自动劫持局域网 DNS，Android 的 Private DNS 也可能影响劫持。