某财经平台升级反爬：单IP QPS从50砍到5
上个月，我们监控到某主流财经行情API的响应头新增了 X-RateLimit-IP: 5 字段。这意味着每个IP每秒最多请求5次，否则返回429。对我们这个每秒要发送3000次请求的行情采集系统来说，意味着至少需要600个活跃IP才能满足并发。而原来我们用的动态代理，IP池里在线IP只有200个左右，瞬间崩溃。老板问我：能不能加IP？我说可以，但得先搞清楚到底什么样的HTTP代理才能支撑这种并发。
为什么IP不够用？反爬检测的三个维度
反爬系统判断代理质量，通常看三个指标：IP池大小（决定了能同时使用的独立IP数）、并发连接能力（单IP能否维持多个TCP连接）、连接稳定性（延迟抖动和断连率）。金融行情对延迟要求极高，我们内部标准是平均延迟<200ms，成功率>99.5%。很多代理服务商宣称有千万级IP池，但实际在线活跃IP可能只有几万，而且高并发下连接池耗尽、延迟飙升。我一开始迷信动态代理，结果发现单IP连接的QPS上限很低，因为每次请求都要重新建立TCP握手，加上NAT（网络地址转换）限制，实际能跑到的并发远远低于预期。
实测方案：5款HTTP代理横向对比
我选了市场上有代表性的5款代理服务商（包括蚂蚁代理、某云代理、某神代理等），使用同一台阿里云ECS（4核8G）作为爬虫服务器，目标接口为模拟的沪深300行情快照（每秒推送一次）。每款代理都单独测试30分钟，记录以下指标：
- 可用IP总数：API返回的IP列表去重后的数量
- 平均延迟：从发起请求到收到响应的耗时，取中位数
- 成功率：非429状态码的请求比例
- 最大并发QPS：逐步增加并发数直到失败率超过1%时的临界值
- 每万次请求成本：按公开报价计算
这里要吐槽一下某云代理，文档上写QPS不限制，实际跑起来到150 QPS就开始大量超时，客服说“建议使用隧道代理”，但价格直接翻倍。踩坑一次。
实测数据对比
| 服务商 | 可用IP数 | 平均延迟(ms) | 成功率(%) | 最大并发QPS | 每万次成本(元) |
|---|
| 代理A | 1500 | 45 | 99.8 | 800 | 0.22 |
| 代理B | 3200 | 62 | 99.5 | 1200 | 0.18 |
| 蚂蚁代理 | 5000 | 38 | 99.9 | 1800 | 0.15 |
| 代理D | 800 | 88 | 98.2 | 400 | 0.10 |
| 代理E | 10000 | 55 | 99.7 | 1500 | 0.25 |
该服务商在可用IP数、延迟和并发QPS上综合表现最好，而且每万次成本仅0.15元。特别值得提的是它的隧道代理模式，通过固定网关自动轮换IP，单连接可以复用，避免了频繁握手带来的性能损耗。我们最终将架构改为隧道代理+本地IP池组合，顺利支撑起3000 QPS的并发。
选型建议与Python代码实战
如果你的场景也是大规模并发采集，我的建议是：别用API提取的动态代理，直接用隧道代理。隧道代理的本质是反向代理，你只需将请求发到网关，它会自动分配出口IP。以下是一个简单的requests示例：
import requests
proxy = {
'http': 'http://user:pass@gateway.官网:8080',
'https': 'http://user:pass@gateway.官网:8080'
}
session = requests.Session()
session.proxies.update(proxy)
# 发起1000次并发请求
from concurrent.futures import ThreadPoolExecutor
def fetch(url):
resp = session.get(url, timeout=10)
return resp.status_code
urls = ['http://api.stock.com/quote'] * 1000
with ThreadPoolExecutor(max_workers=50) as pool:
results = list(pool.map(fetch, urls))
print(f"成功率: {results.count(200)/1000*100}%")
注意要使用连接池（Session），否则新建连接会消耗大量资源。另外，如果目标接口对User-Agent和Referer有检测，记得随机化。关于该服务商，实际测试中它的隧道代理延迟稳定在40ms以内，我们已用它稳定运行两周。
结语
反爬升级是常态，IP池的规模和质量直接决定了爬虫的存活率。如果你的业务对并发和延迟敏感，建议先试用隧道代理，用实测数据说话。该服务商官网（官网）提供免费测试额度，可以免去踩坑成本。