解析到错误 IP 导致 TLS 握手失败

anyrouter.top 在 Oracle2/DO 解析到源站 IP（TLS/HTTP 正常），本地却解析到某 CDN 边缘 IP 并在 TLS 阶段失败；根因是本地 DNS 解析路径与代理出口分离，而非源站或代理本身。

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

[!info] related notes

所属 MOC: DNS 知识地图

差异归因: 为什么同一域名返回不同 IP

诊断流程: 系统化 DNS 诊断流程

代理分离: 代理只改出口不改解析决策

Mihomo: Mihomo redir-host vs fake-ip

TLS 层: tls-handshake-failure-debugging

解析到错误 IP 导致 TLS 握手失败

现象、触发条件与影响范围

访问 https://anyrouter.top 时：

环境	得到的地址	TLS	HTTP
Oracle2	`155.102.x.x`	正常	200
DO	`43.109.x.x`	正常	200
本地/沙箱（挂 Oracle1 代理）	`104.17.x.x`	handshake failure	失败

触发条件：在本地用浏览器/客户端访问，且经由 Oracle1 代理。影响：网站打不开，错误发生在 HTTP 请求之前（TLS 握手阶段）。

快速判断路径

故障在 TLS 握手，不是 DNS 解析报错，也不是 HTTP 层。
远端（Oracle2/DO）能正常拿到 200 → 源站、证书、TLS 本体大概率没问题。
差异首先体现在「解析到的 IP 不同」。

假设与区分假设的证据

已可确认

不同环境 DNS 答案不同。
连 155.102.x.x 或 43.109.x.x 的路径可用。
本地解析到的 104.17.x.x 路径在 TLS 阶段失败。
故障发生在 HTTP 之前。

尚不能仅凭三台机器确认

一定是权威按 ASN 主动分流；
一定是 Cloudflare 权威返回了错误结果；
一定是本地 DNS 缓存；
Oracle1 与 Oracle2 一定用相同递归 DNS；
104.17.x.x 一定完全没有证书（也可能该边缘在此 SNI/配置下拒握手）；
差异一定发生在权威层（也可能在递归/DoH/缓存/劫持层）。

更严谨描述：

本地某条 DNS 解析路径返回了一个当前不能正确承载 anyrouter.top TLS 服务的 Cloudflare 地址，而 Oracle2/DO 的解析路径返回了可用的源站地址。

最终根因及其机制

最可能的机制（按 proxy-and-dns-separation 解释）：

Chrome 查询 anyrouter.top
   ↓ Chrome DoH / Windows DNS / Mihomo 本地 DNS
得到 104.17.x.x
   ↓ Mihomo 选 Oracle1 代理
   ↓ Oracle1 帮你连接 104.17.x.x
   ↓ TLS handshake_failure

Oracle1 只改变了 TCP/TLS 流量从哪发出，没改变客户端最先获得的哪个目标 IP。 而 Oracle2 浏览器整条链路都在 Oracle2，DNS 拿到的是 155.102.x.x，直接连正确源站。

「本地 DNS 缓存」可能延长错误结果，但当前最强解释是解析路径本身不同（浏览器/Windows/Mihomo/本地递归用了与 Oracle2 不同的解析路径），而非单纯缓存。

修复方式和为什么有效

临时验证：hosts

C:\Windows\System32\drivers\etc\hosts
155.102.x.x anyrouter.top

ipconfig /flushdns

绕过所有普通 DNS 查询，快速验证「源站本身没问题」。缺点：IP 变了失效、破坏 CDN/容灾、不能自动跟随 CNAME、可能影响 HTTPS/SVCB/ECH。

优先：高优先级域名规则

rules:
  - DOMAIN-SUFFIX,anyrouter.top,PROXY   # 放在 GEOIP/IP-CIDR/MATCH 之前

避免为检查 IP 规则而提前解析目标地址。

推荐：fake-ip 保留域名交远端

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.x.x/16
rules:
  - DOMAIN-SUFFIX,anyrouter.top,PROXY

路径变为：浏览器拿 fake IP → Mihomo 恢复域名 → 按域名走 Oracle1 → 域名交远端解析。本地不必先用错误 A 记录定目标（见 mihomo-dns-redir-host-vs-fake-ip）。

其他

nameserver-policy 让该域名走特定 DoH（可 #PROXY 走代理出口），但答案仍取决于该 DoH 从权威拿到的内容。
开启 TUN DNS 劫持（dns-hijack: 0.0.x.x:53）+ strict-route 减少泄漏。
最彻底：远程浏览器（解析/连接/TLS/HTTP 全在 Oracle2），无控制面/数据面分离问题。

回归验证与预防

按 dns-systematic-diagnosis 三步即验证根因：

# 1. 直连正确源站
curl.exe -vk --resolve anyrouter.top:443:155.102.x.x https://anyrouter.top/
# 2. 本地解析
curl.exe -vk --proxy socks5://127.0.x.x:7891 https://anyrouter.top/
# 3. 远程解析
curl.exe -vk --proxy socks5h://127.0.x.x:7891 https://anyrouter.top/

若出现「--resolve 成功、socks5h 成功、socks5 失败」→ 确定根因是本地 DNS 解析没跟着代理出口移动。之后用 fake-ip/高优先级域名规则固化，并避免长期依赖 hosts。