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 未按预期走向的问题。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。

操作步骤

1. 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
2. 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
3. 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。

验证与回退

完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。

来源与适用边界

本页的“证据与参考”只用于说明已公开的配置说明或个案范围；它不能证明你的网络、账号、节点或服务端当前处于同一状态。将日志中的令牌、订阅地址、账户资料和网络标识删除后再用于比对。