代理IP配好后每个请求感觉比直连多了几百毫秒——不是代理带宽不够，是多了至少一次TCP握手和一次TLS握手。用curl的计时参数把延时拆开，能看到卡在哪一步。
用curl把请求时间拆开看
curl -x http://代理IP:端口
-w "DNS解析: %{time_namelookup}snTCP握手: %{time_connect}snTLS握手: %{time_appconnect}sn首字节: %{time_starttransfer}sn总时间: %{time_total}sn"
-o /dev/null -s https://目标网站输出解读：time_namelookup=DNS查目标域名的耗时。time_connect=TCP三次握手完成耗时（含DNS）。time_appconnect=TCP加TLS握手总耗时。time_starttransfer=从发请求到收到第一个字节的总耗时。time_total=完整请求时间。
典型直连：DNS 10ms + TCP 30ms + TLS 50ms = 约90ms建立连接。典型代理：DNS 5ms + TCP到代理 40ms + TLS到目标（经过代理）60ms + 代理转发延迟20ms = 约125ms。多了35ms是代理的转发延迟。
延时大头在哪
time_connect减去time_namelookup=纯TCP握手时间。如果这个值超过100ms→代理节点太远，换更近的节点。天行IP（邀请码 blsj，月付6元起）选延迟低的节点。
time_appconnect减去time_connect=纯TLS握手时间。TLS 1.3比1.2快一个往返（1-RTT vs 2-RTT）→确认代理和客户端都支持TLS 1.3。time_starttransfer减去time_appconnect=服务器处理时间→和目标网站性能有关，代理管不了。
复用连接省掉握手
HTTP Keep-Alive让同一个TCP连接可以发多个请求——省掉后续请求的TCP握手和TLS握手。相当于第一个请求90ms加后续每个请求5ms（只有转发延迟）。参考第34篇（ID 13579）的连接池配置。
常见问题
代理模式下time_namelookup比直连慢？
代理服务器的DNS解析目标域名时走了代理服务器的DNS——可能没有使用最快的DNS服务器。确认代理的DNS配置（看代理服务器用的是哪个DNS）。
time_starttransfer远大于time_appconnect？
从连接建立到收到第一个字节间隔太长→目标网站响应慢或代理转发慢。如果是代理转发慢（代理服务器的处理性能差），换代理节点。
