先纠正一个流传很广的说法：IP池越大越安全。我以前也这么信，直到岗位调整，我从写封禁规则的一方，变成了需要大量IP轮换去跑内容审核采集的一方，才发现这个判断错得离谱。池子大只说明“可选多”，不说明“能用”——真正决定成败的是这些IP在你目标站的封禁名单里有多脏。而我们这类做合规检测的系统，最尴尬的情况是：抓回来的IP，早就被自己家的规则拉黑了。
我写封禁规则时，盯的是哪几项
先说结论：封禁很少是“看见一个新IP就封”。我维护的那套系统近90天的封禁日志里，按/24段封禁占61%，单IP封禁占27%，纯指纹维度只占12%。段信誉是主判据，单IP是补充，指纹是兜底。
具体看三样东西。
- 段历史画像：这个/24下过去30天有多少IP命中过蜜罐、触发过频控，命中率高直接整段降权。
- ASN与机房归属：云厂商段的初始风险分天然高，住宅和移动网络低。
- 指纹与IP的一致性：UA、时区、语言和出口IP的省份对不上，直接加一分。
这套逻辑反过来就是选型标准：短效代理IP的价值不在数量，而在于它是否持续供应“没被目标站（包括我们自己）打上标签”的干净段。免费池恰恰是反面——它们的IP被大量爬虫反复使用，早就进了各家黑名单。
迁移前的两周基线：看着免费，其实在自撞枪口
接手后我先用免费池加一个低价隧道跑了两周，日均约6万次页面请求，任务是批量检测落地页的合规文案。数据很难看。
| 指标 | 免费池＋低价隧道 | 短效代理池 |
|---|
| IP可用率 | 38.4% | 98.6%（抽样实测） |
| 首包P95延迟 | 2410ms | 190ms |
| 目标站封禁率 | 17.6% | 2.3% |
| 审核任务失败率 | 21.3% | 3.1% |
| 日成本 | 0元＋约2小时人工排障 | 约22元 |
最刺眼的一个数是：两周抓到约4.2万个不同IP，其中38.7%落在我们系统自己的黑名单段内。第一次跑出这个统计时我愣了几秒——等于花了两周时间，让自己的采集器反复撞自己的枪口。所以问题从来不是“池子不够大”，是“池子太脏”。
换成短效代理，我改了四个参数
短效代理IP一般存活1–5分钟、按提取次数计费，天生适合“一次任务一个IP”的批量轮换。但直接用默认配置还是会踩坑，我调了四项。
- 存活周期选3分钟：太短会频繁重连，太长会在一批IP被限后集体失效。
- 批量提取200个/次，用完即弃：不做失败重试，失败直接换下一个IP，重试等于加速暴露。
- 单IP并发限到2 req/s：这个数是从拐点实验里倒推的，下面细说。
- 账密认证为主，白名单兜底：容器滚动更新时出口IP会漂移，只挂白名单会间歇性401。
import requests
from itertools import cycle
def fetch(n=200):
r = requests.get("https://api.example.com/get", params={
"num": n, "protocol": "http", "format": "json",
"dedup": 1, "area": "全国"
}, timeout=5)
return [f"{i['ip']}:{i['port']}" for i in r.json()["data"]]
pool = cycle(fetch(200)) # 一批用完再提，别做原地重试
那个401的坑我踩了两次才定位到：日志显示失败请求全部集中在发布后的三分钟窗口内，出口IP一换白名单就失效，而连接池里还留着旧连接。
14天验证：封禁率2.3%，但有个并发拐点
切换后同口径跑了14天，封禁率稳定在2.3%，失败率3.1%，主要来自目标站偶发5xx而不是代理本身。但我做了一组压测才发现真正的边界：每IP 2 req/s 时封禁率2.1%，拉到3.5 req/s 跳到9.4%，5 req/s 直接18.2%。拐点在2和3.5之间，很陡。这也是为什么调度器必须自己限流，不能指望代理服务商替你把节奏管好。
说实话，这套方案在我这个量级（日6万请求、1万个IP）很舒服，一天二十几块钱。如果哪天请求量上到千万级，单靠短效池的成本和提取频率都会成为新问题，可能要回到隧道型加短效补位的混合结构——现在我还没那个量，不敢下定论。
最后给个明确结论：做批量内容审核这类高频轮换场景，优先看“脏IP率”和“段信誉”，别看池子规模。我最终用的是蚂蚁代理的短效池加自建限流调度，一天约22元，账算得过来；具体参数和提取接口在mayihttp.com上都有，接进来半天就能跑通。