先说个反常识的结论：在招聘数据采集这个场景里，我花三倍价钱换来的住宅代理，把封禁率从4.1%推到了12.7%。
这个项目日均请求120万，目标是拉勾、BOSS直聘、智联这类站点的岗位信息，抓岗位名、薪资区间、公司规模、更新时间和HR活跃度五个字段。这几个站点的反爬是账号、行为、IP三层叠加的，IP只是其中一层——这一点我也是跑了整整一周才彻底想明白。
预算翻三倍，封禁率反而翻了一倍
我们原方案是某家按流量计费的住宅代理，单价约0.045元/IP，差不多是普通数据中心IP的20倍。按常理"住宅"两个字就是质量保证，但跑满24小时之后数据很难看：
| 供应商类型 | 单价 | 平均延迟 | 首日封禁率 | 连续7天封禁率 |
|---|
| 住宅代理A（按流量） | 0.045元/IP | 820ms | 4.1% | 12.7% |
| 数据中心短效B | 0.0022元/IP | 38ms | 6.1% | 5.4% |
| 隧道代理C | 16元/天 | 52ms | 1.2% | 1.5% |
| 自建机房+轮换 | — | 15ms | 21.3% | 直接被全段拉黑 |
问题出在延迟。住宅代理平均820ms，为了凑够并发我只能拉长单IP的请求窗口，结果同一IP上的请求时间序列变得异常密集，恰好撞在招聘站的行为模型上。再加上住宅IP复用率高，这批网段早就被标记了。代理的质量不由IP类型决定，而由IP、会话、请求节奏三者的匹配度决定。
风控重心，已经从IP转移到会话
去年下半年我们抓包对比过某招聘站的验证码触发逻辑，发现两个阈值：同一IP每秒请求数超过3次会触发，但如果请求间隔的方差小于0.1（也就是节奏太规律）同样会触发。这意味着单纯堆IP池已经没用了，你换得再勤，行为特征还是那副机器样。
这也解释了为什么表现最好的是隧道代理：出口IP固定、会话保持，请求节奏天然更像真人。16元/天的单价看着不便宜，但一条隧道能扛的并发量比按IP计费的方案高一个量级，算下来单次请求成本反而更低。
我现在用三个硬指标筛供应商
踩了三次坑之后，我把选型标准从"池子多大"改成了这三条：
- 会话粘滞能力：隧道代理至少要支持5到30分钟可调。注意别贪长，我一开始设30分钟，某站第三天开始整段封IP，改成8分钟后恢复正常。
- 城市级精度：招聘岗位带强地域属性。之前用的一家只有一线城市节点，采成都岗位返回的全是北上广的重复数据，返工了两天。
- 峰值并发衰减率：宣传的并发和实际可持续并发差多少。实测某家标称1000并发，跑到400时可用率掉到91%，这个数字销售永远不会主动告诉你。
节奏控制这块，代码比选型更容易被忽略。固定sleep是最蠢的做法：
import requests, time, random
s = requests.Session()
s.proxies = {"http": "http://user:pwd@tunnel-host:port",
"https": "http://user:pwd@tunnel-host:port"}
for page in range(1, 51):
r = s.get(url, params={"page": page}, timeout=8)
if r.status_code in (403, 429):
time.sleep(random.uniform(2.5, 6.0)) # 退避要带抖动
continue
time.sleep(random.uniform(1.2, 3.8)) # 固定1秒 = 送人头
迁移后的数字，和几个边界
现在的架构是隧道代理打主力、短效代理兜底：封禁率稳定在0.9%，重试率从18%降到2.3%，月成本从约2400元降到1100元左右，可用率99.9%，平均延迟控制在10ms以内。目前隧道那一档我们用的是 mayihttp.com，3000万+的池子和365+城市覆盖刚好能满足招聘站点的地域定向需求，短效按0.0022元/IP补充，用来跑突发的历史数据补采也不心疼。
但得说清楚边界：这个方案在日均百万级够用，如果每天跑到千万级，单条隧道的并发要重新核算，多半得上多隧道加自建调度层。另外，城市级精度在三四线城市仍然不稳，我们采西部某省会时遇到过约7%的IP实际归属地偏差，这部分数据后来是靠二次校验剔掉的。代理IP哪家好这个问题，答案永远跟着你的场景走——先想清楚站点在查什么，再决定买什么。