代理的速度不是一个数字:它包含延迟(到第一个字节的时间)、吞吐量(字节到达的速度)和成功率(获得可用响应的频率)——每一项都随小时、目标和出口IP而变化。在某一时刻的单一测试几乎无法告诉您任何信息,这就是为什么供应商的营销数字和一次性的评论如此容易产生却难以付诸行动。这是我们用于自己排名的方法:测量什么、如何测量、多久测量一次,以及如何总结结果使其有意义。

四个数字

指标回答的问题获取方式典型良好值
延迟(TTFB)每个请求在数据开始传输前等待的时间在小型资源上使用 curl -w %{time_starttransfer}数据中心:比直连多10–50毫秒;住宅/移动:多80–300毫秒
吞吐量批量数据传输的速度对固定大小的下载(1–10 MB)计时数据中心:接近线路速度;住宅:5–50 Mbit/s;移动:5–30 Mbit/s
成功率请求以真实2xx完成的频率统计多次请求的结果在中立目标上>98%;在受保护的目标上较低是目标的行为
正常运行时间代理可访问的频率数天内定期进行连通性探测数据中心/ISP:>99.5%;轮换池掩盖了个别中断

报告只给出一个“速度”数字的,通常是在安静时段从数据中心代理下载大文件时的吞吐量——这是最有利的组合。

命令之前的原则

  1. 测量差异,而非绝对值。始终连续运行相同的请求直连和通过代理,并报告差异。否则,您自己连接的波动会混入代理的测量中。
  2. 始终使用相同目标。使用一个小型、快速、稳定的端点,且不限制速率——例如主要CDN上的静态文件,或您自己的服务器。切勿针对您打算抓取的网站进行基准测试;其反机器人响应是另一项测量。
  3. 多样本,跨时间分布。每次运行至少20个请求;在一天中的多个小时以及一周内运行。代理是共享基础设施,负载随提供商和出口IP所在地区的业务时间而变化。
  4. 报告百分位数,而非平均值。一次30秒的超时就会破坏平均值。中位数(p50)告诉您典型体验;p95告诉您糟糕日子的体验;两者都比平均值更重要。
  5. 预热。丢弃每次运行的第一个请求——DNS和TLS会话建立使其比其他请求慢。
  6. 一次只改变一个变量。将提供商A的数据中心与提供商B的住宅代理进行比较,是比较类型,而非提供商。

使用curl测量延迟

# 直连
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# 通过代理
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

通过代理时,time_connect是到达代理的时间;目的地的连接和TLS在隧道内进行,计入time_appconnect/time_starttransfer。要比较的数字是ttfb:代理减去直连即为代理增加的延迟。循环执行:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

吞吐量

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

使用足够大的文件,使连接建立只占很小一部分(5–10 MB),但又足够小,以免在多次运行中消耗按GB计费的住宅代理配额。在轮换池中,吞吐量随出口主机的连接而变化;运行足够多的样本以查看分布,并记住在按GB计费的套餐中,吞吐量也决定了您花钱的速度。

成功率

每个请求的结果是:返回预期大小的2xx;目标返回4xx/5xx;代理错误(407、连接拒绝、超时);或带有200状态的挑战页面(CAPTCHA/插页)——最后一种容易被简单的计数器遗漏,因此要检查响应体,而不仅仅是状态码。在Python中:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

将代理故障(407、连接错误、代理超时)与目标故障(403、429、挑战)分开。前者是提供商的问题;后者涉及IP在该目标上的声誉,属于另一项测试——参见反机器人系统如何评分请求。

正常运行时间

正常运行时间是按日历时间计算的成功率。安排一个轻量级探测——上述延迟命令,或一个简单的CONNECT——每5–15分钟一次,至少持续一周,记录每次结果并附时间戳,然后计算成功探测的比例。有两个微妙之处:

  • 轮换池掩盖中断。如果一个出口失效,您会得到另一个;网关本身才有正常运行时间。探测网关,并单独跟踪当您请求粘性会话时分配的IP变化的频率——意外的变化是软中断。
  • 静态IP(数据中心、ISP)通常是“99.9%”声明的对象。99.9%意味着每月停机43分钟;99.5%是3.6小时。两者都可以通过一周的15分钟探测轻松区分。

安排运行

一个最小但有意义的计划:在出口IP本地时间的03:00、09:00、14:00和20:00进行延迟+成功率测试(20–50个请求),每天一次,持续七天;每次运行测一次吞吐量;每15分钟进行一次连通性探测。这每天每个代理只需几百KB用于延迟,几十MB用于吞吐量——即使在按GB计费的套餐上也可承受,只要使用小文件。从一台持续运行的机器(小型VPS是理想选择)上使用cron运行,并为每个请求写一行CSV。我们发布的排名——例如速度排名和可靠性排名——正是基于这种为期一周的系列数据,而非一个下午的测试。

解读结果

  • p50延迟接近该类型的正常值,且p95在p50的约3倍以内:健康。p95远高于p50意味着间歇性拥塞——提供商在高峰时段超卖。
  • 在中立目标上成功率低于约97%且由代理端错误导致:基础设施问题,不是您的问题。
  • 白天明显比夜晚差:共享容量;询问专用选项或在调度中接受。
  • 同一提供商的数据中心表现优异,但住宅代理表现不佳:正常——不同产品;比较住宅代理应与住宅代理比较。
  • 正常运行时间低于声明:您现在有了日志可以向支持人员展示,这比抱怨更有价值。

最后,记住类型。住宅和移动代理本质上较慢——流量确实经过家庭线路或蜂窝塔——为了速度而购买它们是类别错误;参见代理类型比较。将它们与同类产品以及您的任务实际需求进行比较。还要注意,通过代理的连接运行HTTP/2而非HTTP/3,因此在直连基线位于启用QUIC的站点时,要同类比较(详情)。

常见问题

如何测试代理速度?

多次请求相同的资源,直连和通过代理,在一天中的多个时段;比较首字节时间(延迟),并分别对固定大小的下载计时(吞吐量)。报告中位数和第95百分位数,而非平均值。

什么是良好的代理延迟?

相对于直连:数据中心代理增加几十毫秒;住宅和移动代理增加约80–300毫秒,因为流量经过消费者连接。根据每种类型的正常值进行判断。

如何检查代理正常运行时间?

按计划(每5–15分钟)探测至少一周,记录每次结果,并计算成功探测的比例。对于轮换池,探测网关;对于静态IP,探测IP本身。

为什么我的结果与供应商的声明不同?

声明通常是最佳情况:数据中心产品、安静时段、大下载、单一样本。您的测量包括高峰时段、您获得的特定出口IP以及百分位数。您的数字是预测您体验的数字。

我应该针对要抓取的网站进行基准测试吗?

不要用于速度。其反机器人层会增加挑战和阻止,衡量的是IP声誉,而非代理性能。使用中立静态资源进行速度测试,并单独进行声誉测试。

我需要多少样本?

每次运行至少20个以获得稳定的中位数,每天多次运行,持续一周,以查看时间和星期几的影响。正常运行时间无论如何都需要一周。