代理只改出口不改解析决策
访问网站是「先把域名解析成 IP」和「再连接这个 IP」两个独立动作；代理通常只改变连接从哪发出（数据面），未必改变最初解析到哪个 IP（控制面），这是本地挂代理仍失败的根因。
#type / synthesis
#status / growing
#tech / network
#protocol / dns
[!info] related notes
- 所属 MOC: DNS 知识地图
- 解析 vs 连接: DNS 不只是电话簿
- 远程解析: SOCKS5 本地 vs 远程解析
- fake-ip: Mihomo redir-host vs fake-ip
- 实战案例: 解析到错误 IP 导致 TLS 握手失败
代理只改出口不改解析决策
覆盖范围与排除项
本文解释一个最常被误解的关系：代理（VPN/Clash/Mihomo/SOCKS）改变了「网站连接的出口」，但未必改变「域名最先被解析成哪个 IP」。排除项：本文不展开具体代理配置，只讲「解析决策位置」与「连接出口」为何会脱节。
为什么需要一起理解
访问一个网站至少有两个独立动作：
步骤 1：把域名解析成 IP （DNS）
步骤 2：连接这个 IP （TCP/QUIC/TLS/HTTP）代理主要作用于步骤 2 的出口位置。如果步骤 1 已经在本地解析到了错误 IP，代理只是忠实地帮你连这个错误 IP——出口再正确也没用。
依赖与协作模型
典型「本地挂代理仍失败」的路径：
Chrome 查询 anyrouter.top
↓
Chrome DoH / Windows DNS / Mihomo 本地 DNS
↓
得到 104.17.x.x（错误/不可用边缘）
↓
Mihomo 选择 Oracle1 代理
↓
Oracle1 帮你连接 104.17.x.x
↓
TLS handshake_failure对比「远程浏览器可行」的路径：
Oracle2 浏览器
↓
Oracle2 所用 DNS（得到 155.102.x.x）
↓
直接连接正确源站差别不在代理本身，而在解析决策发生在哪条 DNS 路径上。
一条具体关系路径
判断「是不是这个问题」的三步：
- 用
--resolve强制连正确 IP，若成功 → 不是网络/TLS 本体问题（见 howto dns-systematic-diagnosis）。 - 用
socks5h://（远程解析）成功、socks5://（本地解析）失败 → 本地 DNS 路径给错 IP（见 socks5-local-vs-remote-resolution）。 - 检查 Mihomo 是否在连接前就采用了本地 DNS 结果（redir-host 模式），而非把域名交远端（fake-ip 模式，见 mihomo-dns-redir-host-vs-fake-ip）。
决策规则与易混淆点
- 代理 ≠ DNS 也走代理：除非显式把域名交给远端解析，否则本地解析结果先定，代理只是转发连接。
- 想让「解析跟着出口走」，要么用 fake-ip 把域名交远端（见 mihomo-dns-redir-host-vs-fake-ip），要么用
socks5h，要么让 DoH 走代理出口但仍取决于解析器位置。 - 「本地 DNS 缓存」可能延长错误结果，但通常不是根因——根因是解析路径本身就不同（见 why-same-domain-different-ip、dns-caching-hierarchy）。
- 最彻底的方案是远程浏览器：解析、连接、TLS、HTTP 全在远端，不存在控制面/数据面分离（见 dns-wrong-ip-tls-handshake-failure-debug）。