前段时间，我们工作室有个采集任务突然慢了。
脚本没有更新，目标网站也能正常打开，但原本一秒左右的请求，陆续涨到了三四秒。最开始大家都觉得是这批 IP 不行，于是换了一批，又换了一批，速度还是时好时坏。
后来把测试条件逐项拆开，才发现出口 IP 其实没多大问题。真正拖慢请求的，是代理入口在晚高峰出现了抖动。换 IP 没用，换入口以后反而很快恢复了。
这也是代理延迟排查里最容易绕进去的地方：我们看到的是 IP 在变慢，实际出问题的却可能是线路、地区、并发，甚至是自己的连接池。
所以，我现在碰到代理请求慢，已经很少一上来就批量换 IP 了。
先别跑完整任务，拿一条请求测明白
业务脚本里混着调度、重试、解析、写库等操作，直接看整个任务耗时，很难判断时间到底花在了哪里。
我一般先把并发降到 1，固定一个代理、一个目标站，只发最简单的请求。
curl -x http://用户名:密码@代理地址:端口 \
-o /dev/null -s \
-w "connect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n" \
https://目标网站
这几个时间不需要分析得特别复杂。
connect 很高，通常先看业务服务器到代理入口这一段；connect 正常，ttfb 却很高，则更像是代理出口到目标站慢，或者目标站正在限制当前 IP。
如果 tls 经常跳动，也别忽略。跨境线路抖动、丢包以及反复建立新连接，都会把握手时间拉长。
至于 total，它只是最终结果。只盯着总耗时看，很容易把目标站处理慢、响应内容太大，也算到代理头上。
我还会顺手做两个对照：一个是不用代理直接访问，另一个是使用同一代理访问不同网站。
假如直连和代理都慢，问题未必出在代理。假如同一代理访问其他网站正常，只有某个目标站特别慢，就要考虑对方是否做了限速，或者当前出口到这个网站的路由不理想。
线路慢，不一定是带宽不够
有些代理测速时表现很好，放进正式任务却不稳定。
最典型的是单次请求只有几百毫秒，连续运行一段时间后，偶尔会冒出三秒、五秒甚至超时的请求。最后算平均值，好像还能接受，但任务队列已经被这些长尾请求拖住了。
这种情况，我不会先看宣传页面上的带宽数字，而是看两个东西：P95 有没有明显升高，以及异常是否集中在某些时间段。
如果白天正常，晚间开始波动，入口拥塞或者跨网质量下降的可能性就比较大。
线路问题还有一个很实用的判断方法：固定出口，换入口。
出口地区、目标网站和并发量都不动，只换代理入口。如果入口一换，延迟马上下来，那就没必要继续折腾出口 IP 了。问题大概率在业务服务器连接代理入口的途中。
需要进一步看路径时，可以跑一下：
mtr -rw 代理入口地址
或者使用 traceroute 观察有没有明显绕路。
不过我不会单凭某个中间节点不回包，就判断线路丢包。很多机房会限制 ICMP，路由工具只能提供线索，最后还是要看真实请求的建连时间、P95 和超时率。
地区看起来选对了，路径也可能是错的
“美国 IP”“日本 IP”这种标签，在选地区时其实有点粗。
美国东部和美国西部之间，本身就有不短的距离。如果目标服务器靠近洛杉矶，出口却在纽约附近，国家没有选错，请求照样要横穿一段很长的网络。
更麻烦的是代理入口。有些业务服务器部署在新加坡，连接的却是欧洲入口，然后再由欧洲转发到亚洲目标。出口地区乍看没问题，前面已经绕了一大圈。
所以地区排查不能只看出口 IP 在哪个国家。我一般会在纸上或者表格里记下四个位置：
业务服务器、代理入口、代理出口、目标服务器。
先看业务服务器能不能就近连接入口，再看出口是不是靠近目标站。很多延迟问题，把这四个位置摆出来以后就已经很明显了。
IP 地理库也不能完全相信。
有时查询结果显示东京，实际路由却不像东京节点；还有些 IP 在不同数据库里会显示不同城市。这可能是地理库没有及时更新，也可能显示的是注册信息，而不是实际机房位置。
遇到这种情况，我会再看 ASN 和路由方向，多找一两个地理库交叉确认。手里如果有东京、大阪、新加坡等多个地区的节点，就放在同一时间段、同一目标站下测试，不要今天测一个、明天再测另一个。
否则，地区差异还没看出来，时间波动先混进来了。
真正的问题，往往到并发上来以后才出现
单线程测速很快，并不能证明这个代理适合实际业务。
我见过不少情况，1 个并发时延迟很低，开到 10 个并发也没问题，到了 20 或 50，P95 突然上升，超时也开始增加。
背后的原因不止一种。可能是账户有连接数限制，也可能是入口节点开始排队；如果请求集中在一个出口 IP 上，还可能触发目标站的频率限制。
本地程序同样可能先撑不住。连接池太小，请求会在客户端等待；连接池开得过大，又可能在短时间创建太多连接。文件描述符、CPU、临时端口和重试策略，也都会影响结果。
因此，并发测试不要直接从 1 跳到业务峰值。
我通常会按 1、5、10、20、50 逐级增加，每一级运行相同时间。这里不需要堆很多指标，先盯住成功率、P95、建连时间和首字节时间就行。出现异常以后，再补看 P99、连接重置以及具体错误类型。
有个简单的判断：
- 并发上升后，
connect先变高，优先检查入口容量、账户并发限制和本地连接资源。 connect没什么变化，但ttfb越来越高，优先检查出口拥塞、单 IP 请求密度和目标站限速。
如果怀疑单 IP 压力过大，可以保持总请求量不变，把流量分散到多个出口 IP。
分散以后恢复正常，说明单 IP 请求密度值得重点排查。换成多个 IP 依旧慢，就别再把时间花在换 IP 上了，继续查共享入口、账户限制和本地程序更有效。
有时“代理慢”，其实是请求还没发出去
这类问题不太显眼。
业务日志里记录一条请求花了五秒，但其中两秒可能都在本地连接池里等空位。站在脚本的角度看，它确实用了五秒；站在代理的角度看，它只处理了后三秒。
每次请求都重新建立 TCP 和 TLS 连接，也会多花不少时间，跨境任务尤其明显。
我一般会做一组很直接的测试：同样的代理和目标站，一组复用连接，另一组每次重新建连。如果连接复用以后延迟明显下降，应该优先调整连接池，而不是判断代理节点不行。
重试策略也要看。
超时后立即重试，表面上是在补救失败请求，实际上可能把瞬时并发继续推高。原本只是少量请求变慢，连续重试以后，入口和本地连接池一起开始排队，最后看起来像整批代理同时失效。
我的实际排查顺序没那么复杂
先把并发降下来，使用一条简单请求拆出 connect、tls 和 ttfb。这一步是为了确认慢在哪里，而不是为了跑出一个好看的测速数字。
接下来固定出口地区，只换入口。
如果换入口有效，处理线路；如果没什么变化，再固定入口，更换出口城市或区域。出口靠近目标站以后明显变快，说明原来的地区选得不合适。
前两项都没有明显问题，最后再逐级增加并发。看从哪个档位开始，P95、首字节时间和超时率同时出现变化。
中间不要同时改入口、出口、IP 和并发。变量一多，测试结果即使变好了，也不知道是哪一个调整起了作用。
有几种现象，我会优先这样判断：
- 低并发也一直慢：先查距离和线路绕路。
- 白天正常，晚上变慢：先查高峰期入口拥塞。
- 换 IP 没用，换入口有效：重点看接入线路。
- 只有一个目标网站慢：检查目标站限速和出口路径。
- 单线程正常，并发后变慢：查账户限制、单 IP 密度和连接池。
- 建连很快，首字节很慢：查出口到目标站这一段。
这些都只是排查方向，不是看到某个现象就能直接定性。最好再安排一组只改变单个条件的测试，确认现象可以重复出现。
别让平均延迟把问题藏起来
假设十次请求里，九次是 300 毫秒，一次是 5 秒，平均下来不一定特别难看。但放到采集任务里，那一次长尾请求可能会一直占着连接，后面的任务也只能等。
因此，我现在基本不会只留一句“平均延迟 800 毫秒”。
测试记录里至少要有时间段、业务服务器地区、代理入口和出口地区、目标站、并发数、P50、P95、P99、成功率以及错误类型。是否复用连接，也要记下来。
信息看起来比一个平均数麻烦，但下一次再出现延迟升高时，可以很快判断是线路发生了变化，还是业务并发已经超过原来的稳定区间。
代理 IP 延迟高，不要急着用换 IP 解决所有问题。先拆请求阶段，再对照入口线路和出口地区，最后逐级增加并发。找到延迟从哪一步开始上升，比找一个暂时很快的 IP 更重要。
