代理 DNS 解析失败：从域名错误到分流恢复

日志里的 no such host、Could not resolve host、lookup ... timeout 都指向解析阶段，但失败的域名未必是你正在浏览的网站：它可能是订阅服务器、代理节点，也可能是 DNS 服务器自身。先找到报错中的域名和上下文，再决定改哪一层。解析和路由的完整关系见 DNS 与代理分流。

先判断失败发生在哪里

记录出现错误的操作以及第一条解析报错，避免只截取最后的“连接失败”。

发生时机	常见失败对象	下一步
只有更新订阅失败	订阅域名	先查订阅更新流程
全部请求失败，日志反复出现同一节点域名	节点地址或其启动解析路径	检查节点域名如何解析
只有某些网站失败	目标域名、特定 DNS 策略	对比系统与内核解析
启用 TUN 后所有域名异常	DNS 接管、监听、路由循环	先关闭 TUN 恢复，再逐项核对
只有一个浏览器失败	浏览器安全 DNS 或独立代理	与另一应用及内核日志对比

先保留原 DNS、TUN 和浏览器安全 DNS 设置。不要把完整订阅链接当作域名传给诊断命令，也不要为了排查将内核 DNS 端口开放到公网。

第一步：测试系统查询，不急于改设置

下面的 www.example.com 是占位域名，替换为实际报错域名；优先测试公开域名，不要把内部域名交给公共 DNS。

# Windows；macOS / Linux 有 nslookup 时同样可执行
nslookup www.example.com
# 第二条仅为本次查询指定服务器，不改系统 DNS
nslookup www.example.com 1.1.1.1

macOS / Linux 也可用：

dig www.example.com A
dig @1.1.1.1 www.example.com A

默认查询超时而指定 DNS 成功，提示默认解析路径值得检查；两者都超时，也可能是当前网络不允许访问这些 DNS。NXDOMAIN 表示该查询返回域名不存在，SERVFAIL 表示解析服务无法完成请求，和没有收到响应的超时不同。不同服务器返回不同的有效 IP 并不自动代表异常。Microsoft nslookup 错误说明

系统查询成功也不能证明浏览器和内核使用同一路径。TUN 可能接管查询，浏览器可能使用自己的加密 DNS，客户端还可能单独解析节点域名。保留这些结果，再看实际请求。

直接查询内核已启用的 DNS 监听

如果当前生效配置已明确启用本地 DNS 监听，可以向这个地址和端口单独查询。下面仅假设监听为 127.0.0.1:1053；先替换成实际值，不要把 HTTP/SOCKS 代理端口当成 DNS 端口，也不必为了测试额外开放监听。

# macOS / Linux：已安装 dig 时使用；不会修改系统 DNS
dig @127.0.0.1 -p 1053 example.com A +time=2 +tries=1

Windows 可在终端输入 nslookup 进入交互界面，再逐行执行以下内容；最后一行退出工具，不会更改系统 DNS：

server 127.0.0.1
set port=1053
set type=A
example.com
exit

得到预期记录或 Fake-IP 映射，说明这一监听能回答该次查询；它仍不证明上游 DNS 经指定节点传输。若这里超时，而系统查询成功，检查监听是否启动、端口是否相符及内核的上游日志；若直接查询成功、原应用失败，回查应用 DNS、缓存和接管路径。内核没有独立 DNS 监听时，跳过这项，使用其 DNS 日志与下面的 SOCKS 对照。dig 参数、nslookup 自定义端口

第二步：对比应用本地解析与代理端解析

若客户端提供 SOCKS5 或 mixed 端口，可使用同一个目标做两次对照；7890 必须换成实际支持 SOCKS 的端口：

# macOS / Linux；Windows 把 curl 改成 curl.exe
curl -q --proxy socks5://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/
curl -q --proxy socks5h://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

socks5:// 让 curl 在本地解析目标名；socks5h:// 把目标域名交给 SOCKS 代理。后者成功、前者解析失败，是本地目标解析路径异常的线索。这里的“交给代理”是交给本机内核，最终由内核或远端完成解析取决于协议和配置，不能保证查询一定发生在境外。curl 的 SOCKS 解析区别

两次都失败时，检查报错是否变成节点域名解析、TLS 或认证错误；如果失败阶段已经改变，就应按新错误继续，而不是继续随机替换 DNS。请求成功后也要在连接列表确认实际出站，规则可能选择直连。

命令把 -q 放在 curl 的第一个参数位置，仅跳过默认 curl 配置文件，不会修改系统代理或 DNS。这样可以避免默认文件里的附加代理、重试或证书选项影响对照；--noproxy localhost 则单独覆盖本次代理绕过名单。其他例子中的 curl 参数可查 官方手册。

第三步：检查内核 DNS 的职责是否配置正确

以 mihomo 为例，先在客户端查看当前生效配置，不要只修改一个尚未启用的订阅文件。以下字段承担不同职责：

字段	要核对的内容
default-nameserver	DNS 服务器域名的启动解析是否可用
proxy-server-nameserver	节点域名解析是否能够在节点未建立前完成
nameserver / nameserver-policy	普通目标及特定域名是否交给预期解析器
direct-nameserver	直连流量是否保留需要的解析路径
respect-rules	DNS 连接是否按规则发送，是否造成启动依赖

如果“解析节点必须先连代理，而连接代理又必须先解析节点”，就会形成循环。应使用客户端或服务商推荐的、当前网络可达的启动解析方案，而不是把所有 DNS 查询都强制走尚未建立的节点。字段含义及版本要求以 mihomo DNS 官方文档为准；sing-box、Xray 的字段不能直接照搬。

订阅更新会覆盖原文件时，持久修复应使用客户端支持的覆写或扩展配置。一次只调整相关字段，保留前后差异；没有证据时不要把整套陌生 DNS 配置复制进去。

第四步：分辨 Fake-IP、浏览器与 IPv6 的影响

Fake-IP 用映射地址把域名与后续连接关联起来。mihomo 示例范围包含 198.18.0.0/16，所以出现此类地址不自动说明被劫持。需要核对查询与连接是否由同一内核接管；只让 DNS 进入 Fake-IP、流量却绕过内核，或退出后继续使用旧映射，都可能失败。

浏览器安全 DNS 可能使浏览器与系统命令得到不同结果。先记录其原设置，仅在个人设备上做一次受控对照，重开浏览器再测；若没有改善，恢复原值。企业管理的浏览器设置应由管理员确认。

IPv6 方面，可分别查询 A 与 AAAA 记录，结合客户端日志观察是否只有某一地址族的连接失败。AAAA 为空与查询超时不是同一件事。不要只因 IPv6 存在就永久关闭整机 IPv6；应先确认网络和客户端的 IPv6 路由、DNS 与出站配置一致。

成功验证、恢复与求助

修复后按三层验证：相关公开域名能够按预期查询；客户端日志不再出现同一解析错误；原应用通过正确规则与出站完成实际访问。再检查局域网设备、公司或校园内网是否仍能正常解析，并在客户端重启后复测。

关闭排查时临时启用的高详细度日志，恢复无效的 DNS、浏览器和 TUN 改动。若停用客户端后仍无法访问，先恢复原系统 DNS 并重新打开受影响应用，避免残留映射或指向已关闭本地 DNS 的设置；无需先清空全部网络配置。

求助时提供失败的是哪类域名、错误原文、查询结果、客户端/内核版本、系统代理或 TUN 状态、是否启用 Fake-IP、SOCKS 两次对照结果及最近改动。内部域名、订阅令牌、认证内容和可识别个人的访问记录应先脱敏。