说句实在话，很多人拿到代理IP之后第一反应就是"快不快"，然后打开某个测速网站点一下，看到个数字就觉得自己搞清楚了。但实际操作中你会发现，同一个IP，上午测和下午测差出一大截；用浏览器测和用脚本测，结果能差出几十毫秒甚至更多。这不是IP的问题，是你测的方法不对。
代理IP的"速度"其实是个复合概念，它包含连接建立时间、数据传输延迟、并发稳定性这几个维度。你只测一个维度，就像用体温计量血压——数字有了，但说明不了问题。下面这套方法是我自己反复验证过的，不管你是做数据采集、市场调研还是其他业务场景，都能帮你把代理IP的真实表现摸得明明白白。
测速之前，先把这几个变量锁死
很多人测完速度发现"忽快忽慢"，其实不是IP不稳定，是你测试环境本身就不干净。我见过最离谱的情况是：同事开着视频会议在同一个网段测速，结果比正常延迟高了将近200ms，然后跑来问是不是IP质量有问题。
所以测速前，你至少要把这几件事确认好：
第一，本地网络要干净。关掉那些后台自动更新的软件、云盘同步、视频会议。你本地带宽被占满了，测出来的延迟全是假的。最简单的办法：先跑一次本地测速（不挂代理），记下基准延迟，后面所有数据都跟这个基准比。
第二，测试目标要固定。别一会儿测A网站一会儿测B网站。不同服务器所在机房不同、带宽不同、响应逻辑不同，你测出来的数字没有可比性。建议固定一个目标地址，比如一个轻量级的HTTP接口，每次测都打同一个地址。
第三，时间窗口要一致。网络是有潮汐的，早高峰和深夜的链路负载完全不一样。如果你要对比不同IP的表现，尽量在同一个时间段内完成测试，别上午测一批、晚上再测一批然后混在一起看。
第四，代理协议要统一。HTTP、HTTPS、SOCKS5这三种协议在握手阶段开销不一样，你拿HTTP的延迟去跟SOCKS5比，那肯定比不出个所以然来。
别再用"打开网页看加载时间"这种土办法了
我知道很多人测代理IP就是挂上代理然后打开一个网页，看它几秒加载完。这个方法的问题在于：网页加载时间 = 代理延迟 + 目标服务器响应时间 + 页面资源下载时间 + 浏览器渲染时间。你测的其实是四样东西的总和，根本剥离不出代理本身贡献了多少。
正确的做法是只测TCP连接建立到收到第一个字节（TTFB）这段时间，或者更精确一点，测一个极小请求（比如一个HEAD请求或者一个返回空JSON的接口）的完整往返时间。这样你测到的才是代理链路本身的延迟。
下面这张表能帮你快速判断哪种测速方式靠谱：
| 测速方式 | 能反映什么 | 主要干扰因素 | 推荐程度 |
|---|---|---|---|
| 浏览器打开网页看加载 | 综合体验（含渲染） | 目标服务器、页面复杂度、浏览器缓存 | 不推荐 |
| ping命令 | ICMP层延迟 | 部分代理不支持ICMP，结果可能不准 | 仅作参考 |
| curl测TTFB | 单次HTTP往返延迟 | 目标服务器响应速度 | 推荐 |
| 脚本批量测+统计 | 延迟分布、稳定性、并发表现 | 本地环境（需控制变量） | 强烈推荐 |
手把手：用Python写一个靠谱的代理测速脚本
下面这段代码是我实际在用的，逻辑不复杂，但覆盖了单次延迟、多次采样取中位数、超时判定、错误捕获这几个关键点。你拿去改改就能跑。
import requests
import time
import statistics
import concurrent.futures
def single_test(proxy, target_url="https://httpbin.org/get", timeout=8):
"""单次测速：测完整HTTP往返时间"""
start = time.perf_counter()
try:
resp = requests.get(
target_url,
proxies={"http": proxy, "https": proxy},
timeout=timeout,
headers={"User-Agent": "SpeedTest/1.0"}
)
elapsed_ms = (time.perf_counter() - start) 1000
return {
"proxy": proxy,
"status": resp.status_code,
"latency_ms": round(elapsed_ms, 2),
"ok": resp.status_code == 200
}
except requests.exceptions.Timeout:
return {"proxy": proxy, "status": "timeout", "latency_ms": None, "ok": False}
except Exception as e:
return {"proxy": proxy, "status": "error", "latency_ms": None, "ok": False, "msg": str(e)}
def batch_test(proxy_list, rounds=5, target_url="https://httpbin.org/get"):
"""
对一组代理IP做多轮测速
rounds: 每个IP测几轮，取中位数更抗干扰
"""
all_results = []
for proxy in proxy_list:
latencies = []
for i in range(rounds):
r = single_test(proxy, target_url)
if r["ok"]:
latencies.append(r["latency_ms"])
time.sleep(0.3) 间隔300ms，避免触发限流
if latencies:
all_results.append({
"proxy": proxy,
"median_ms": round(statistics.median(latencies), 2),
"min_ms": round(min(latencies), 2),
"max_ms": round(max(latencies), 2),
"stdev_ms": round(statistics.stdev(latencies), 2) if len(latencies) > 1 else 0,
"success_rate": f"{len(latencies)}/{rounds}"
})
else:
all_results.append({"proxy": proxy, "median_ms": None, "success_rate": "0/5"})
return all_results
用法示例
proxies = [
"http://120.55.xx.xx:8080",
"http://117.136.xx.xx:8080",
"http://222.186.xx.xx:8080",
]
results = batch_test(proxies, rounds=5)
print(f"{'代理IP':<28} {'中位延迟':>10} {'最小':>8} {'最大':>8} {'波动':>8} {'成功率':>8}")
print("-" 80)
for r in results:
if r["median_ms"] is not None:
print(f"{r['proxy']:<28} {r['median_ms']:>8}ms {r['min_ms']:>6}ms {r['max_ms']:>6}ms {r['stdev_ms']:>6}ms {r['success_rate']:>8}")
else:
print(f"{r['proxy']:<28} {'超时/失败':>10} {'':>8} {'':>8} {'':>8} {r['success_rate']:>8}")几个要点说一下：
为什么用中位数而不是平均值？因为网络偶尔会抽风，某一次延迟飙到800ms，平均值就被拉高了，但中位数不受极端值影响，更能代表"正常情况下的真实速度"。
为什么每轮之间sleep 300ms？你连续打同一个代理节点，短时间内请求太密集，对方可能会触发限流或者排队，测出来的延迟就不是真实链路延迟了，而是排队时间。
为什么用perf_counter而不是time.time()？perf_counter是单调递增的高精度计时器，不受系统时间调整影响，测毫秒级延迟更准。
并发测速：单个快不代表扛得住
上面那个脚本是串行测的，一个IP测完再测下一个。但实际业务中你往往是同时开多个请求走代理，这时候表现可能完全不一样。有些IP单线程延迟只有80ms，但你一并发到20个请求，延迟直接飙到500ms以上，这就是并发能力的问题。
加一段并发测试的代码：
import concurrent.futures
def concurrent_test(proxy, concurrency=10, target_url="https://httpbin.org/get"):
"""
并发测速：同时发concurrency个请求，看延迟怎么变化
"""
def worker(_):
return single_test(proxy, target_url)
with concurrent.futures.ThreadPoolExecutor(max_workers=concurrency) as pool:
futures = [pool.submit(worker, i) for i in range(concurrency)]
results = [f.result() for f in concurrent.futures.as_completed(futures)]
latencies = [r["latency_ms"] for r in results if r["ok"]]
if not latencies:
return {"proxy": proxy, "concurrency": concurrency, "all_failed": True}
return {
"proxy": proxy,
"concurrency": concurrency,
"median_ms": round(statistics.median(latencies), 2),
"p95_ms": round(sorted(latencies)[int(len(latencies)0.95)], 2),
"success_count": len(latencies),
"total": concurrency
}
对比：单线程 vs 10并发 vs 30并发
proxy = "http://120.55.xx.xx:8080"
for c in [1, 10, 30]:
r = concurrent_test(proxy, concurrency=c)
print(f"并发数={c:<4} 中位延迟={r.get('median_ms','N/A')}ms P95={r.get('p95_ms','N/A')}ms 成功={r.get('success_count','0')}/{c}")你跑完会发现一个规律：并发数上去了，中位延迟可能变化不大，但P95（95%的请求延迟）会明显上升。这个P95值才是你实际业务中"最慢的那批请求要等多久"的关键指标。如果你的业务对延迟敏感，P95比中位数重要得多。
测速结果怎么读？别只看一个数字
跑完测速你手里会有一堆数字，怎么判断这个IP到底行不行？我给你一个实操中的判断标准：
延迟绝对值：国内节点之间，中位延迟在100ms以内算优秀，100-200ms算正常，超过300ms就要警惕了。但注意，这个数值跟你的本地位置和目标服务器位置有关，跨省的延迟天然比同省高，别拿北京到广州的延迟去跟北京到天津比。
波动（标准差）：同样中位延迟120ms，标准差5ms和标准差80ms完全是两回事。前者说明链路稳定，后者说明这个IP的出口带宽可能不够用，或者上游路由不稳定。做持续采集的话，标准差比平均值更值得你关注。
成功率：5次测试里3次成功2次超时，这个IP你基本可以放弃了。正常可用的代理IP，在合理超时设置下成功率应该在95%以上。如果频繁超时，要么是IP本身质量不行，要么是目标服务器对代理IP做了限制。
并发衰减比：单线程延迟100ms，30并发时中位延迟变成350ms，衰减比3.5倍，说明这个节点的并发承载能力有限。如果你的业务需要高并发，这个指标比单线程延迟重要。
选IP的时候，测速只是最后一步
测速能告诉你"这个IP现在快不快"，但选IP不能只看速度。我见过不少用户光盯着延迟数字，结果选了一堆"快但脏"的IP——延迟是低，但IP被大量使用过，目标端直接识别为代理，请求全被拒了，速度再快也没用。
所以实际选IP的时候，IP纯净度和可用率跟延迟同等重要。你测速之前最好先确认一下IP的"出身"：是不是运营商正规分配的、有没有被标记过、近期使用频率高不高。这些指标直接决定了你的请求能不能正常到达目标端。
我自己现在用的方案是神龙HTTP，简单说一下为什么选它。它家IP资源来自国内三大运营商正规授权，池子里有3000万+的IP储备，每天更新去重，IP纯度标称99.8%，可用率99.9%。这个数据意味着什么？你拿到的IP大概率是"干净"的，不会因为IP本身被标记而频繁被目标端拒绝，测出来的延迟才是真实链路延迟，而不是"被拒后重试"的假延迟。
另外它支持300+城市级精准定位，你测速的时候可以指定同省或邻近城市的节点，这样测出来的延迟数据才有参考意义。协议上HTTP/HTTPS/SOCKS5都支持，API接口兼容主流爬虫语言，你上面那段Python脚本稍微改一下代理获取方式就能直接对接它的API，不用手动一个个填IP。
套餐方面，如果你只是偶尔测个速度、做小规模采集，短效动态IP池（3/5/10/15/30分钟时效）就够了，按量或按时计费，灵活。如果你需要IP存活时间长一些、做持续性任务，长效静态IP池（1到24小时）更合适。对稳定性要求很高、IP需求量不大的场景，固定IP池基于云主机构建，纯净度99.83%，按个数售卖，适合"一个IP用到底"的需求。
常见问题
Q：我测出来的延迟比直连高了200ms，正常吗？
要看你的代理节点跟目标服务器在不在同一个区域。代理IP的链路是"你→代理节点→目标服务器"，多了一跳，延迟天然会比直连高。如果代理节点跟目标服务器在同一个省份，多出来的延迟在30-80ms属于正常范围。如果跨了大半个中国，多100-200ms也说得过去。但如果同省节点延迟比直连高了300ms以上，那这个IP的链路质量确实有问题，建议换一批再测。
Q：为什么同一个IP，我测和另一个同事测结果差很多？
大概率是你们本地网络环境不同。一个在办公室走公司宽带，一个在家走家用宽带，出口运营商可能都不一样（比如一个电信一个联通），到代理节点的路由路径完全不同。还有一种可能是你们测的时间点不同，网络负载有波动。建议你们在同一个网络环境下、同一时间段内各测5轮取中位数，这样才有可比性。
Q：测速的时候用HTTP还是HTTPS测更准？
如果你实际业务走的是HTTPS，那就用HTTPS测。HTTPS比HTTP多一个TLS握手过程，会多出50-150ms的开销（取决于是否复用连接）。你用HTTP测出来80ms，实际HTTPS业务可能是150ms，这个差距不能忽略。测速协议一定要跟实际业务协议保持一致，否则数据没有参考价值。
Q：我一次要测几百个IP，串行跑太慢了怎么办？
用上面那个并发测试的思路，但注意并发度别拉太高。你同时打500个不同IP，每个IP只发1个请求，这没问题。但如果你同时对同一个IP发500个请求，那测出来的就不是IP质量了，是它能不能扛住500并发。建议对几百个IP做"筛选性测速"时，每个IP发2-3个请求就够了，目的是快速淘汰明显不行的（超时、高延迟），再对剩下的做精细的多轮测速。
最后说一句，测速这件事没有"一劳永逸"的说法。网络环境是动态的，运营商线路调整、目标服务器扩容、你本地网络变化，都会影响延迟。我一般建议每周跑一次全量测速，日常业务中如果突然感觉"变慢了"，先跑个快速测速确认是IP的问题还是本地网络的问题，别上来就怀疑IP质量。
