curl 测代理IP延迟，最值钱的不是它测出的总时间，而是它能把一次请求拆成几个阶段、分别计时。走代理IP的请求从发出到完成，要经过解析、连接、转发、目标处理好几步，curl 用 -w 参数加时间变量，就能把这些阶段的时间一个个打出来——总时间变慢的时候，你能直接看出慢在哪一段。
时间变量的写法是一条固定套路：在 curl 命令里加 -w 参数，后面跟一个引号包起来的格式串，里面写变量名。比如想看总耗时，就在格式串里写 time_total；想看连接耗时，就写 time_connect。一条命令可以同时输出好几个时间，用换行或者分隔符隔开，输出就是一排清晰的数字，比图形界面给的总时间有用得多。
四个核心时间变量各代表什么
time_connect：建立连接花了多久
time_connect 测的是从开始到 TCP 连接建立的时间，它反映的是「到代理IP服务器这段路」的往返质量：连接慢，说明本地到代理IP服务器的链路有延迟，或者代理IP服务器响应慢。这个数字受线路距离影响最大，出口离你越远，这个时间通常越长。
time_appconnect：代理握手用了多久
time_appconnect 测的是连接建立之后、应用层握手完成的时间，走代理IP时这一步是客户端和代理之间的协议协商。这个时间平时很短，但如果代理IP服务器负载高或者协议处理慢，它会明显变长——看到它偏高，方向就指向代理IP服务那一侧的处理能力。
time_starttransfer：首字节等了多久
time_starttransfer 测的是从开始到收到第一个字节的时间，它包含连接、握手、发出请求、目标开始返回的全过程，是最接近「体感等待时间」的指标。网页转圈半天其实就是首字节迟迟不来。这个时间偏长，可能是链路慢、可能是目标处理慢，要结合前面几个时间一起判断卡在哪。
time_total：全部完成的总时间
time_total 是整个请求从开始到结束的总时间，包含下载内容的时间。它是最直观的「这次访问花了多久」，但也是最笼统的——只有它变慢时你不知道慢在哪，所以要配合前面几个分段时间一起看。总时间慢而各段都快，那慢的时间基本花在下载内容上，指向带宽问题。
看这四个时间有一个顺序技巧：从上到下逐段对比。time_connect 慢了看链路，appconnect 慢了看代理服务，starttransfer 慢了看目标，只有 total 慢了看带宽。逐段排除，几秒钟就能定位到段。
多测几次取中位，别拿单次数值下结论
curl 的时间输出是一次请求的结果，网络天然有波动，单次数字可能有偶然性——赶上一次网络抖动，total 可能虚高。所以拿时间变量测代理IP延迟时，习惯上要连着测几次，比如连续跑五遍同样的命令，记录每遍的总时间，看中间水平的数值而不是最快或最慢的那次。中间值才是这个代理IP出口的真实水平。
连着测几遍还有一个额外收获：能看出稳定性。五次结果都差不多，说明代理IP出口稳定；五次结果忽高忽低，说明它在波动——稳定性差对某些业务的影响比延迟高更严重。前面讲过测量要看延迟和失败率，curl 连测几遍，两个维度都能量到：时间看延迟，有没有报错看失败。
用时间变量量完延迟，还有一个基本问题要回答：这个代理IP出口到底是不是我要的那个？出口对不对，直接决定后面所有测试有没有意义。