HTTP 请求里的解析发生在哪一步

用代理IP时，十次网页打不开的情况里，有相当一部分卡在打开页面的第一步，跟内容本身没关系。请求还没发出去，地址就先没解析出来。这一步在直连场景里几乎无感，到了走代理的场景，它的位置和归属就变得值得说清楚。

一次普通的页面访问，实际包含两个阶段：先把域名换成地址，再拿地址去建立连接。两个阶段的归属在不同配置下不一样，这直接决定了看到的结果。

解析发生在请求的哪个位置

域名换成地址这一步，发生在真正发送请求之前。这一步没完成，后面的事都无从谈起。顺序上它是第一环，因此排查打不开问题时，它也是最该先确认的一环。很多人一上来就怀疑IP质量，实际上连地址都没解析出来，后面的环节根本还没开始跑。

解析结果没拿到，请求根本发不出去。

连接复用之后还解析吗

连接建立之后，只要还在复用同一条连接，就不会重新做这一步。这也是为什么有时候换了几次IP，看到的结果还是一样：旧连接没关，请求仍然走在原来的路径上。反过来，连接断开后重建，才会带上新的解析结果。理解这一点，能解释不少看似矛盾的观察。

代理场景下谁来解析

这里有个容易混淆的地方。代理链路上，有的配置是访问端自己解析好，再把地址交给中间环节；有的则把域名直接交过去，由对方代为解析。两种做法看到的结果可能不同，因为解析所在地会影响返回的地址，进而影响最终连到哪里。确认这一环由谁负责，是排查跨区域访问差异时最先要做的事。

解析结果什么时候会变

域名对应的地址不是永久固定的。服务方调整部署、线路调度变化、缓存到期，都会让解析结果换一个。变化本身是正常的，问题在于变化发生时，正在跑的任务可能被打断。这也是为什么长时间运行的任务，对稳定线路的需求会更高一些。

1. 确认解析这一步是否已经完成
2. 确认由本机还是远端负责解析
3. 检查是否存在正在复用的旧连接
4. 对比不同时间点的解析结果是否一致
5. 记录变化发生的时刻，与业务异常时间对照

按这个顺序排查

从第一步往后走，每一步都确认清楚再进入下一步，比跳着猜效率高得多。多数打不开的情况，在前两步就能定位。

代理链路上面打不开时先把解析这一环排掉，再看IP和线路，方向才不至于跑偏。这一步花的时间很短，能省掉的返工却不少。