为什么低延迟代理下载文件仍然可能很慢
连接延迟和下载吞吐量衡量的是代理请求的不同环节。应根据具体任务选择测速方式。
能快速返回小页面的代理，下载文件时仍可能很慢。前一种请求主要反映连接建立和响应的延迟；较大的传输还取决于这条路径能持续承载多少数据。
哪个指标能回答你的问题？
| 任务 | 值得观察的指标 |
|---|---|
| 打开小页面或发送简短的 API 请求 | 收到响应所需的时间，包括连接建立。 |
| 下载文件 | 使用合适测试文件测得的总传输字节数和平均吞吐量。 |
| 在大量请求下保持应用响应灵敏 | 预期负载下的典型响应时间、失败情况和连接复用。 |
ICMP ping 是另一种测试。服务器可能在代理服务不可用时仍回应 ping，也可能在代理正常工作时屏蔽 ping。到代理地址的往返时间，还没有计入代理到目标站点的连接。
测量一次真实传输
使用你所控制的服务器上的文件，或专门供此类测试使用的文件。下面的示例丢弃响应正文，输出传输大小、平均每秒字节数及总耗时：
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin示例中的代理和文件 URL 都要替换。404 页面或拒绝访问的响应即使很快返回，也不能作为有效的下载基准。比较速度前，先检查状态、预期文件大小和内容。
平均速度字段的单位是字节/秒，而网络套餐宣传的比特/秒是另一种单位。从字节粗略换算为比特时乘以八；整个比较过程应保持单位一致。
保持比较条件一致
使用相同的目标、文件、客户端网络和超时设置。比较多次适量采样，不要只挑最快的一次。对于停滞的传输，应有意识地选择连接建立、总体耗时和低速限制。失败的请求也应保留在结果中：偶尔传得很快、却经常失败的代理，可能不适合必须完成的任务。
缓存文件与全新下载在服务内部可能走不同路径。新建连接后的请求与复用已有连接的请求，也可能如此。先确定应用需要哪种行为，再始终测量这种行为。
根据负载选择
对于小型 API 响应，收到首字节前多等一秒，可能比峰值吞吐量更重要。对于大文件下载，握手很快、正文却极慢并不划算。无论哪种任务，都要测试实际使用的目标；没有一个速度评分能描述经过某个代理的所有路径。
ProxyHub 代理列表不提供针对每个 IP 的独立吞吐量测量。协议或国家筛选并不是速度排名。