我最初的想法很朴素：招聘站反爬再狠，我一个页面多换几个免费代理，总能撞过去。结果第一周就被打脸——不是抓不到，而是抓到的岗位信息开始“缺字段”，薪资和发布时间大片为空。翻日志才明白，封我的不是请求频率，是IP画像。这个认知偏差，大概是每个从免费池迁出来的人都要交的学费。
一、招聘站封你的真正原因：IP共用度，不是QPS
免费池的IP大多来自公开节点，一个出口IP在24小时里可能被几十个人拿去爬同一个站。我统计过一笔账：某个免费出口IP在一天内出现过47个不同UA，命中过11个不同账号的搜索路径。招聘站风控只要把它标成“共享出口”，你后面换什么UA、加多少延时都没意义——直接返回一个带验证码的302。
更隐蔽的是字段降级。有些站不封你，而是返回一个结构完整、内容被抽稀的页面，薪资区间变成“面议”，岗位描述只剩前50字。这种软封禁比403难排查得多，我第一次遇到时以为是解析规则挂了，调了三个小时代码，最后发现是IP的问题。说实话，那三个小时挺蠢的。
所以做代理IP测评时，我把“可用率”和“干净度”拆成两个指标看。前者决定你能不能连上，后者决定你连上之后拿到的是不是真数据。
二、三档代理的14天实测矩阵
这次代理IP测评我没按“池子大小”排名，而是按请求密度分档。同一个采集器（日请求约3.2万，覆盖5个招聘站）跑了14天，三档方案的账是这样：
| 档位 | 延迟中位数 | 可用率 | 单请求成本 | 平均封禁触发点 | 适合日请求量 |
|---|
| 短效动态（按IP计费） | 180ms | 92.4% | 约0.0003元 | 800次左右 | 1万–5万 |
| 隧道代理（按天计费） | 95ms | 99.5% | 约0.0005元 | 1500次以上 | 5万–50万 |
| 住宅/独享静态 | 320ms | 99.9% | 0.6元/IP/天 | 极少触发 | 5000以内高价值页 |
延迟那列别急着下判断。住宅代理慢，是因为它走真实家宽链路，不是质量差。但我一天要跑3万条，320ms意味着单线程跑不完，必须开并发，成本又绕回来了。住宅代理不是万能解，它是给“请求少、每条都值钱”的场景用的。
三、决策树：先算请求密度，再定档位
- 日请求 < 5000，且目标站有登录态、行为链风控 → 住宅或独享静态，宁可慢
- 日请求 5000–5万，页面无登录态 → 短效动态，按量买，别包月
- 日请求 > 5万，或需要长会话 → 隧道代理，按天摊薄最划算
- 混合打法：列表页走隧道，详情页走短效动态（我最后落地的就是这套）
这里有个反直觉的结论：隧道代理“每次请求换IP”，对招聘站是负优化。列表页和详情页靠会话cookie串起来，IP换太勤，cookie和IP对不上，直接被降级成面议页面。我把隧道会话粘性调到6分钟（一个IP连用6分钟再换），封禁率从18%掉到3.7%。这个参数大部分平台藏在“会话粘性”那一栏，不显眼，但它比换多少IP都重要。
四、我的落地配置与验证数据
采集器里加了两条硬规则，代码不长，但省了我两周返工：
SESSION_TTL = 360 # 会话保持6分钟，招聘站cookie与IP强绑定
BAN_WINDOW = 3 # 同一IP连续3次302到验证页，拉黑7天
MAX_CONCURRENCY = pool_size // 8 # 并发不超过池规模的1/8
第二条尤其关键：拉黑7天，不是5分钟。招聘站的记忆比你想的长，同一个IP反复撞验证码，会被打进长期黑名单。第三条是我交了学费才加的——并发从40拉到120那天，可用率直接掉到86%，池子IP周转不过来，这就是性能拐点。池子不是越大越好，是并发与池规模的比例要压住。
迁移后14天：字段完整率从71%提到99.2%，日均有效岗位从8200条涨到2.6万条，单条成本降到约0.0006元。边界也得说清楚，这套配置在日请求3万–5万很稳，真跑到百万级，隧道那一档就得拆成多供应商分流，单家池子扛不住。
综合性价比上我现在主用“隧道+短效”混合，长期合作那家在会话粘性和城市覆盖上最省心（mayihttp.com，池子3000万级、覆盖365个城市，隧道16元/天起）。选型没有第一名，只有你的请求密度配哪一档。