很多采集团队遇到代理池延迟高，第一反应是"这家代理不行，换一家"。但延迟不是一个不可拆解的黑箱。它是好几段独立耗时叠加出来的结果，每一段都能单独测量、单独定位。把 800ms 当成一个整体去评判供应商，往往会错杀。真正拖慢均值的，可能只是池里一小撮节点，或者一处被忽略的连接配置。
下面这次排查，目标是把一个日常跑电商选品和舆情监测采集的代理池，平均延迟从 800ms 压到 120ms。整个过程没有换供应商，全部靠分层定位加池治理完成。它更像一张可复用的排查清单，而不是一次运气。
第一步：先把"延迟"拆开，别拿总数下结论
单次请求经过代理，耗时至少由这几段构成：
- DNS 解析：把目标域名解析成 IP 的时间。
- 客户端到代理的 TCP 握手：建立连接的一个往返（RTT）。
- TLS 握手：如果走加密，通常再叠加一到两个 RTT。
- 代理转发处理：代理节点接收、鉴权、建立到目标的连接。
- 目标响应（TTFB）：目标服务器处理并返回首字节的时间。
- 数据传输：响应体下载完成的时间。
800ms 的均值里，这六段各占多少，直接决定了该动哪里。没有分层打点就开始优化，等于蒙着眼睛调参。
建立基线的办法：用带分阶段计时的请求逐段采样。以命令行工具为例，curl 的 -w 参数能直接打出 time_namelookup、time_connect、time_appconnect、time_starttransfer 等分段耗时；把这些字段对同一批目标跑上几百次，按 P50/P95 汇总，延迟到底堆在哪一层立刻就清楚了。
这次的基线拆出来是这样的：
| 分段 | P50 耗时 | 判断 |
|---|---|---|
| DNS 解析 | ~90ms | 偏高，没做缓存 |
| TCP + TLS 握手 | ~380ms | 异常高，怀疑没复用连接 |
| 代理转发 | ~150ms | 偏高，怀疑绕路或死节点 |
| 目标 TTFB | ~150ms | 正常，目标侧问题不大 |
| 传输 | ~30ms | 正常 |
结论很直接：目标服务器没问题，问题几乎全在握手和转发两段。这就把"换供应商"这个选项先排除了——同一批供应商节点，转发正常时明明只要 150ms。
第二步：握手 380ms，连接没被复用
握手段占了近一半耗时，几乎可以断定连接每次都在重建。高频采集里，同一个目标域名短时间内会被请求成千上万次，如果每次都重新走一遍 TCP 三次握手加 TLS 协商，握手 RTT 会被成倍放大，尤其跨区链路一个 RTT 就可能三四十毫秒。
排查确认了两点：客户端的连接池上限设得过低，请求排队等连接；同时 HTTP 层没有启用 keep-alive，每个请求用完即关。
优化动作：
- 开启并复用长连接（keep-alive），让同一目标的后续请求跳过重复握手。
- 复用 TLS 会话（session ticket / session resumption），把 TLS 从完整握手降级为简化握手，省掉一个 RTT。
- 把客户端连接池上限调到与实际并发匹配，消除排队。
这一步之后，握手段 P50 从 380ms 掉到约 90ms。单这一项就贡献了近 300ms。
第三步：转发 150ms，死节点和绕路
转发段偏高，通常是两类原因：池里混进了高延迟或半死的节点，轮询命中它们就拖慢均值；或者选路绕远，出口和目标不在同一区域、同一运营商，回程被迫跨区。最典型的绕路是华东的目标却命中了华南出口，白白多走一段。
对池子做延迟画像后发现两个问题：约 8% 的节点 P95 延迟超过 500ms，其中一部分实际已经不可用，请求命中后要等超时才重试，均值被它们严重抬高；选路是纯随机轮询，完全不考虑目标与出口的地理和运营商关系。
优化动作：
- 主动健康检查：周期性探测每个节点的连通性与延迟，把 P95 超阈值的节点从可用池里剔除，恢复后再放回。
- 快速失败：把单节点连接超时设短，失败立刻切换到下一个健康节点，而不是死等。
- 加权就近选路：按节点历史延迟和目标区域打分，优先选同区域、同运营商的出口，把随机轮询换成延迟加权选择。
这一步把转发段 P50 从 150ms 压到约 60ms，死节点带来的长尾也基本消失。
第四步：DNS 90ms，顺手做掉的缓存
DNS 每次都走完整解析,在高频重复请求同一批域名的场景里纯属浪费。加一层本地 DNS 缓存，对固定目标做预解析，解析段 P50 从 90ms 降到 20ms 以内。这一项不难，却是收尾时容易被漏掉的几十毫秒。
结果：各项贡献分解
| 优化项 | 削减耗时 |
|---|---|
| 连接复用 + TLS 会话复用 | ~290ms |
| 死节点剔除 + 快速失败 | ~130ms |
| 加权就近选路 | ~120ms |
| DNS 缓存 | ~70ms |
| 合计 | ~610ms |
平均延迟从 800ms 落到 120ms，长尾（P95）的收敛比均值更明显。值得强调的是：这里没有一项是"换了更好的供应商"。同一批节点资源，治理前后差了六七倍，差距全在测量、选路和连接管理上。
为什么对电商选品和舆情监测，延迟稳定性比峰值更重要
这两个场景的共同点是高频、持续、对时效敏感。电商选品要在价格和库存变动的窗口内把数据抓全，舆情监测要贴着事件发酵的节奏持续拉取。它们真正怕的不是偶尔一次慢，而是延迟不可预测，P95 忽高忽低会让采集队列积压、任务超时重试,进而拖垮整批数据的新鲜度。
所以选型和调优时，比"平均延迟多少"更该问的是"P95 稳不稳、死节点能不能被快速剔除、选路会不会绕远"。一个均值 120ms 但 P95 飙到 900ms 的池子，对高频采集的伤害，可能比一个均值 200ms 但 P95 稳定在 250ms 的池子更大。评估池子的健康度，看长尾比看均值诚实得多。
可复用的排查清单
遇到代理池延迟高，按这个顺序走，基本不会跑偏：
- 先分层打点，把总延迟拆成 DNS / 握手 / 转发 / TTFB / 传输，找出耗时集中在哪一段，再动手。
- 握手段高：查连接是否复用，开 keep-alive 和 TLS 会话复用，连接池上限对齐并发。
- 转发段高：给节点做延迟画像，剔除高 P95 和半死节点，把随机轮询换成健康检查加就近选路。
- DNS 段高：加本地缓存和预解析。
- 目标 TTFB 高：这一段是目标服务器的响应能力，通常不在代理侧，别在代理上白费功夫，考虑降低对单一目标的请求频率、错峰采集。
- 收尾用 P95 复核，而不是只看均值下没下来，长尾稳住了，采集队列才稳。
延迟这件事，多数时候答案不在"哪家代理更好"，而在"耗时到底堆在哪一层"。把这个问题问清楚，八成的高延迟自己就有了去处。
