我先说怎么封你：三条规则决定了代理选型的天花板
最贵的代理不一定最扛封。这句话我在给招聘站写风控规则的时候没什么感觉，等到自己带队做岗位数据采集，才被现实按在地上教了一遍。
招聘类站点的风控（风控即风险控制，这里指识别异常流量的规则集）核心逻辑只有一条：身份和行为不能错配。具体拆成三条硬规则——IP归属城市要和所查岗位的城市对得上；同一cookie会话内，IP的ASN（自治域，可以粗略理解为运营商或机房的归属）不能突变；请求间隔要符合人的浏览分布，不能是恒定的800毫秒。
这三条直接框死了选型空间。机房IP段在ASN层面就是公开的，我们当时的规则里，机房段的命中率大概92%，也就是说拿机房代理去采，等于举着牌子告诉对方我是脚本。反倒是住宅网络，哪怕是动态住宅换得勤，判定成本会高很多。
这里有个我踩过的认知坑：一度以为“池子越大越安全”。后来自己跑了一段时间数据才反应过来，反过来才对——池子越大，单IP在被复用到下一次之前的暴露窗口越短，“同一C段高频访问不同岗位”这种聚类规则反而更容易把你捞出来。这个偏差我纠正了差不多两周。
三档选型矩阵：按目标站风控强度分层，不按报价单分层
代理商给的套餐名（动态、隧道、静态住宅）看着很专业，但和你要打的站对不上号。我建议的分层标准是目标站的检测类型，而不是价格。招聘采集场景下我实测的对照如下：
| 档次 | 成本参考 | 单IP平均可用时长 | 1000次请求封禁率 | 适合的目标站 |
|---|
| 免费公开池 | 0元 | <30秒 | 87% | 无，纯浪费时间 |
| 机房动态 | 0.0022元/IP起 | 3~6分钟 | 41% | 前程无忧等以节奏检测为主的站 |
| 隧道代理 + 城市定向 | 16元/天起 | 整段会话稳定 | 12%（配合粘性会话） | BOSS直聘、猎聘等强校验站 |
第一档不用讨论。免费池我拿100个并发跑过一轮，前50次请求就挂了43个，剩下的一半是超时，等于在给脚本喂噪声。
第二档是很多人图省事的默认选项：单价低，机房动态换得也算快。但注意——前程无忧这种站主要靠请求间隔的分布特征做检测，IP换了也救不了你不改节奏。我在这里吃过一次亏：老板非要省这笔钱，坚持只上机房动态，结果业务方连续三天投诉岗位数据缺了四成。
第三档才谈得上稳。城市定向（让代理按目标岗位所在城市出IP）是关键，隧道代理把轮换逻辑放在服务商侧，你在Python里只维护一个入口地址，省掉了自己管IP池的活。我自己常用的一家在这块的调度稳定性不错，mayihttp.com 那套城市级定向+隧道模式，成本按天算反而比按IP买更可控。
配置层：把“会话粘性”做对，比换哪家都重要
这一节是我最想说的，因为绝大多数采集脚本死在这里，而不是死在代理质量上。
最典型的错误写法是“每请求一换IP”。反爬侧看到的现象是：同一个cookie、同一个UA、30秒内从15个不同ASN的IP发出请求，这种信号强度比固定IP还高，等于自己递上判据。正确做法是会话粘性：绑定一个IP，在同一个cookie会话里连着跑8~12分钟，再整体换掉。
- 隧道代理建立会话：在账号名后追加会话标识，让服务端把这条连接固定到同一个出口IP。
- requests里只挂代理地址，不要每次请求重建Session。
- 设置8~12分钟的会话生命周期，到点主动换会话ID，不要等被封了再换。
- 节奏层叠一个对数正态分布的随机间隔，均值1.8秒，替代固定sleep。
关键的判断依据是：IP的质量差异在封禁率上只值10~15个百分点，而轮换粒度做错能直接让你归零。这个结论我用三组对照跑出来的，不是拍脑袋。
另一个不常见但很致命的点：不同站点的约束维度是不一样的。BOSS直聘强校验账号与IP的区域一致性，IP跳到别的城市但账号历史都在北京，权重直接掉；而智联一类更看重单位时间内的请求密度。所以选型不是“选一个万能代理”，是“给每个目标站配一套轮换参数”。
决策树：按天请求量倒推，别按池子大小倒推
把上面沉淀成可以直接抄的判断顺序：
- 日请求量 < 5000 且目标站是节奏型 → 机房动态足够，0.0022元/IP的成本模型最划算。
- 日请求量 5000~50000 且目标站强校验IP区域 → 隧道代理+城市定向，按天计费。
- 日请求量 > 50000 → 先别加代理预算，先降请求频次，因为封禁拐点通常出现在单城市单小时2000次以上。
- 只要出现“同一账号多地登录”告警 → 立刻停采查cookie与IP的一致性，加代理救不了。
说句实在的，这套方案在日均3万请求的量级够用，真跑到百万级，可能要换成自建拨号池，我没在那个体量上跑过，不敢乱下结论。但有一点我很确定：代理选型失败的原因，七成在轮换粒度和节奏控制，只有三成在IP本身。先把脚本的行为写像人，再去纠结买哪家，顺序反了就是白花钱。