系统化 DNS 诊断流程

不要反复换 DNS，应逐层确定「哪个组件返回了哪个 IP」：从 Windows 系统解析、指定公共 DNS、清除缓存、统一浏览器 DNS，到 --resolve 直连、socks5/socks5h 对比、Mihomo 日志、权威直查与 TLS 直连。

#type / howto #status / growing #tech / network #protocol / dns

[!info] related notes

系统化 DNS 诊断流程

目标和可观察的成功状态

逐层隔离「哪个组件返回了哪个 IP」，最终回答：解析路径是否给错 IP？还是网络/TLS 本体问题？成功状态 = 能指出差异发生在系统/浏览器/代理/递归/缓存/权威哪一层。

前置条件与风险

  • 需要管理员/终端权限执行 ipconfig、Clear-DnsClientCache、改浏览器与安全 DNS设置。
  • 改 hosts、关安全 DNS、切 fake-ip 都只是诊断手段，确认根因后应按需恢复（见每步「恢复」）。
  • 不要一上来反复换 DNS——那会混淆缓存状态，反而难定位。

步骤（逐层）

第一层：Windows 系统解析

Resolve-DnsName anyrouter.top -Type A
Resolve-DnsName anyrouter.top -Type AAAA
Resolve-DnsName anyrouter.top -Type CNAME
Resolve-DnsName anyrouter.top -Type HTTPS

记录：DNS 服务器是谁、A/AAAA/CNAME/HTTPS 各是什么、TTL 多少。

第二层：指定传统公共 DNS

Resolve-DnsName anyrouter.top -Type A -Server 1.1.1.1
Resolve-DnsName anyrouter.top -Type A -Server 8.8.8.8
Resolve-DnsName anyrouter.top -Type A -Server 223.5.5.5

注意：普通 UDP/TCP 测试不能完全排除 UDP 53 被透明重定向（见 dns-filtering-hijacking-pollution）。

第三层：检查并清除 Windows 缓存

ipconfig /displaydns | findstr /i anyrouter.top
Clear-DnsClientCache

然后完全退出浏览器并重启代理核心，再复测。

第四层：暂时统一浏览器 DNS

Chrome：设置 → 隐私和安全 → 安全 → 使用安全 DNS。诊断阶段可暂时关闭安全 DNS，让 Chrome 走系统/Mihomo 路径；或固定一个明确自定义 DoH 再与系统比较。

不要一边让 Chrome 用自定义 DoH，一边用 flushdns 判断浏览器解析——Chrome 可能根本没用 Windows DNS（见 browser-secure-dns）。

第五层：绕过 DNS，直连正确源站

curl.exe -vk --resolve anyrouter.top:443:155.102.x.x https://anyrouter.top/

--resolve 同时：强制连 155.102.x.x + TLS SNI 仍发 anyrouter.top。若返回 200 → 本机到源站网络/TLS/HTTP 都正常，主要问题在 DNS 选择。

第六层：测试错误边缘

curl.exe -vk --resolve anyrouter.top:443:104.17.x.x https://anyrouter.top/

稳定出现 TLS 握手失败 → 该 IP + 此 SNI 的 TLS 路径异常（不是页面缓存）。

第七层：对比 SOCKS 本地/远程解析

curl.exe -vk --proxy socks5://127.0.x.x:7891 https://anyrouter.top/
curl.exe -vk --proxy socks5h://127.0.x.x:7891 https://anyrouter.top/
结果结论
socks5h 成功、socks5 失败本地 DNS 路径错，远端解析可用
两个都失败Mihomo 可能仍自解析/规则错/Oracle1 与 Oracle2 不同
两个都成功、浏览器失败Chrome Secure DNS/缓存/扩展/QUIC 问题
两个都连 104.17.x.x域名没真正交远端解析

第八层：查看 Mihomo 连接日志

访问一次后看 Host / Destination IP / Matched Rule / Outbound / Network。重点看目标地址最终是 104.17.x.x 还是 155.102.x.x；若日志已显示 104.17.x.x，说明连接前已采用本地 DNS 结果（见 mihomo-dns-redir-host-vs-fake-ip）。

第九层：在 Oracle1 上直接查询

getent ahostsv4 anyrouter.top
dig anyrouter.top A AAAA CNAME HTTPS

若 Oracle1 返回 155.102.x.x 而 socks5h 仍失败 → 本地代理没真用远端解析；若 Oracle1 也返回 104.17.x.x → Oracle1 与 Oracle2 环境不同。

第十层：区分权威分流 vs 递归问题

dig anyrouter.top NS
dig @<ns> anyrouter.top A +norecurse     # 分别从本地与 Oracle 对权威直查
dig +trace anyrouter.top A

权威直接回答不同 → GeoDNS/来源分流/Anycast/权威策略；权威相同、递归不同 → 递归缓存/过滤/ECS/劫持/旧 CNAME（见 why-same-domain-different-ip）。

中间结果与最终验证

  • 第五层 --resolve 成功 → 排除网络/TLS 本体。
  • 第七层 socks5h 成功 + socks5 失败 → 锁定「本地 DNS 给错 IP」。
  • 第九/十层直查权威 → 锁定「权威分流」还是「本地链路」。

恢复与回归

创建于 2026/7/31 更新于 2026/7/31