上个月月底，我给工作室挂机的机器腾出晚上的算力，接了个学术论文采集的活——六个数据库、两万三千多篇文献的元数据。刚跑两天，其中一个库的响应从平均340ms变成大面积超时，返回清一色429。翻日志才发现，对方把频率判定窗口从60秒压到了5秒，我们原来“每IP每30秒发2次”的节奏当场报废。
我手上22个游戏账号白天挂机，代理池本来就是现成的。索性拿这批资源做了组对照实验，把短效代理IP的接入方式和并发阈值一次性摸清楚。下面这组数据跑了11天，不是拍脑袋。
实验设计：三种接入方式跑同一批任务
对照组只改一个变量——代理的接入方式，目标站、任务量、重试逻辑全部锁死。三种方式分别是：
- API提取：每发一次请求前调接口拉一个新IP，用完即弃
- 隧道代理：固定入口，服务端按策略自动轮换出口IP，客户端不用管
- 账密+白名单：固定几个长效IP，靠账号密码鉴权
统一参数：并发8、超时8秒、失败重试2次、每次请求间隔随机300-800ms。每个方案跑4000条请求，记录成功率、平均延迟和封禁次数。
第一轮结果：封禁率差在“换IP的时机”
我一开始以为池子越大越安全，API提取每条请求都换IP，理论上最不容易被盯上。跑完才发现完全相反。API提取的封禁率是隧道代理的3.2倍，因为同一个会话里IP疯狂跳变，反而触发了对方的风控规则——学术库判定“同一账号短时间跨地域访问”，直接拉黑。
| 接入方式 | 成功率 | 平均延迟 | 封禁次数 | 单请求成本 |
|---|
| API提取（每请求换IP） | 81.4% | 412ms | 37 | 0.0022元 |
| 隧道代理（会话粘性） | 94.7% | 286ms | 11 | 0.0031元 |
| 账密+白名单 | 88.2% | 521ms | 24 | 0.0018元 |
隧道代理赢在“IP换得没那么勤”。它给每个会话保持同一个出口几分钟，符合正常用户的访问特征。这个发现跟我预想的差得挺远，说白了，短效代理IP的价值不在“换得快”，在“换得对”。
并发拐点：从8加到16，再往上就崩
接入方式定了隧道代理，接下来调并发。这是短效代理最容易翻车的地方——加机器容易，加并发是真会崩。我把并发从8按8的步长往上推，每档跑30分钟取稳态数据：
| 并发数 | 成功率 | 平均延迟 | 429占比 |
|---|
| 8 | 94.7% | 286ms | 2.1% |
| 16 | 92.3% | 341ms | 4.8% |
| 24 | 76.9% | 612ms | 18.4% |
| 32 | 63.2% | 1104ms | 31.7% |
拐点在16到24之间，保守取16。超过之后成功率断崖，延迟翻倍，说明瓶颈不在代理池容量，而在目标站对单IP的频率容忍度。这里有个反常识的细节：并发拉高后，隧道代理的出口IP复用率上升，等于变相把请求压到更少的IP上，自己把自己封了。
跑通两周的配置与两个坑
最终稳定运行的组合是隧道代理+并发16+会话保持300秒，提取代码大致这样：
import requests, time, random
PROXY = "http://user:pass@tunnel.host:port"
def fetch(url):
for i in range(3):
try:
r = requests.get(url, proxies={"http": PROXY, "https": PROXY}, timeout=8)
if r.status_code == 200:
return r.text
except Exception:
pass
time.sleep(random.uniform(0.3, 0.8))
return None
隧道入口最后用的是蚂蚁代理16元/天那档，按每天8小时的量折算，比纯按IP计费省了近四成。踩过的坑记录一下：凌晨2点到4点批量任务会把池子打空，延迟从300ms飙到2秒以上，后来加了错峰和失败降级才稳住；另一个坑是重试间隔写死成固定值，被识别出机器特征，改成随机后429明显下降。
短效代理IP这东西，接入方式选错，池子再大也是白搭。如果你也在做类似的采集，建议先花半天把并发拐点测出来——这比换服务商有用得多。我这套参数在小几万条的体量够用，真到每天百万级，可能得往会话池调度的方向再改。完整的接入文档在 mayihttp.com 上能查到。