解析故障、连接故障和 TLS 证书故障不能互相替代判断。不要用“换一个公共 DNS”处理所有情况。
先辨认域名解析失败的证据
浏览器提示找不到地址，或日志出现解析失败时，才优先怀疑 DNS。记录失败域名、时间和错误文字，用两个不同的公共域名复测。只有某个网站失败，可能是该网站自己的记录或服务异常；所有域名失败但基础网络正常，才进一步检查解析路径。
不要简单把域名换成 IP 在浏览器中测试 HTTPS：证书和站点路由可能依赖域名，这种测试产生的新错误会误导判断。内网管理员提供的 IP 连通结果可以作为线索，但仍需与域名查询和应用错误一起分析，不能单独断定 DNS 已坏。
找到应用实际使用的解析路径
浏览器、操作系统和 Mihomo 内核可能使用不同的解析设置。系统代理工作正常，并不代表系统全部 DNS 查询都经过客户端。TUN 的 DNS 接管也要结合生效配置与平台限制判断。观察访问时是否出现客户端连接记录，以及日志是否指出内核查询失败。
若一个浏览器正常、另一个失败，先比较它们的安全 DNS 与扩展设置；若系统应用正常、TUN 场景失败，查看 TUN 与内核 DNS 的组合。先记下当前值，按自己网络的要求做一次可逆对照，再恢复，避免同时改路由器、系统和浏览器三处设置。
核对上游解析器与配置覆盖
查看内核实际使用的 DNS 设置，确认上游地址可达、协议写法与内核版本相符。上游的地址解析、通信路径与目标站点的通信路径可能不同，代理节点能连接不等于解析器也能连接。不要因为日志出现 timeout 就持续追加更多上游，那会让实际选择过程更难判断。
最近修改过扩展配置时，检查它是否覆盖了订阅的 DNS 内容。备份后用原订阅验证，若原订阅正常，逐项恢复扩展。只改变已经有证据指向的字段，并查看加载后的配置；编辑文件中的值不一定等于内核最终使用的值。
内网域名和 hosts 单独排查
公司内部域名通常需要内部解析器。公共 DNS 不一定知道这些记录，因此“换成公共 DNS”可能让问题扩大。Mihomo 的 nameserver-policy 可以为特定域名选择解析服务器；域名范围和服务器地址应由你的网络管理员提供，不要照抄示例网关。
部分加速工具也会修改系统 hosts。若只有它处理过的网站失败，先查看是否存在对应条目，记录并由条目所属工具或管理员恢复。不要清空整个 hosts 文件，它可能承载工作环境配置。内网 DNS 路由与站点访问路由均需符合组织网络要求。
验证解析与访问同时恢复
修改后重新发起域名查询和网页访问，必要时重启相关应用以避免旧缓存影响。确认公共站点能够打开，内部资源按预期解析，且连接记录中的直连或代理策略正确。只看到 DNS 返回地址仍不够，最终连接失败可能属于节点、路由或服务问题。
当两个公共域名及必需内网域名均能稳定使用，停止继续替换解析器。若结果不一致，保留时间、查询类型、应用与运行模式等差异，以脱敏错误片段求助。公开材料中避免暴露内部主机名、网段和配置令牌；这些细节可以只交给受信任的管理员。
相关问题
fake-ip 模式是不是 DNS 出错？
不一定。fake-ip 是内核的一种解析与映射工作方式，返回映射地址不能单独证明故障。需要结合实际访问和连接记录判断。
公共 DNS 能解析公司内部域名吗？
通常不能依赖它。应使用组织提供的内部解析器，并为对应域名配置合适的解析和访问路径。
资料与适用范围
本文以原创步骤解释操作思路，不声称已经在所有设备和版本上实测。菜单名称、默认值与兼容条件可能随版本变化，请结合当前项目说明核对。
需要修正内容？请阅读反馈与纠错，不要公开完整订阅或账户凭据。
