如何应对使用代理 IP 池的分布式采集？

应对代理 IP 池的分布式采集，核心思路不是"封 IP"，而是把识别维度从 IP 层上移到会话层、指纹层和行为层——只按 IP 限速，等于把预算花在攻击者最便宜的资源上：住宅代理按流量计费约 1–15 美元/GB，换一个 IP 的成本远低于你封一个 IP 的成本。

为什么单纯封 IP 对代理 IP 池几乎无效？

结论：代理池的 IP 是可消耗品，封禁只提高对手的采购成本，不改变其请求成功率。

典型代理池规模从几千到几十万 IP 不等，轮换策略通常是"每请求换 IP"或"每 N 分钟换 IP"。你用 WAF 拉黑一个 /24 段，对手下一分钟就能换一个 ASN。真正稳定的不变量是：TLS 指纹、HTTP/2 帧特征、UA 与 Accept 头的组合、鼠标轨迹缺失、请求间隔的规律性。防御要做的是抓住这些不变量，而不是追着 IP 跑。

第一步：把限速维度从 IP 改成"会话 + 指纹"

结论：限速键应该是（账号 | Cookie ID | JA3/JA4 指纹 | IP）的复合键，而不是单一 IP。

具体做法：在 Nginx/OpenResty 或网关层用 Redis + 令牌桶，键设为 rate:{ja3}:{cookie_id}，阈值例如 60 次/分钟、1000 次/小时。对没带 Cookie 的匿名请求，用 JA3 指纹 + UA + Accept-Language 拼一个临时会话 ID。IP 只做辅助：对单个 ASN 设并发上限（例如 200 并发），而不是逐 IP 封。

注意点：JA3 只覆盖 TLS 版本、加密套件、扩展列表，Chrome 每个小版本都会变，需要逐版本维护基线，误杀率会明显上升。所以指纹只能作为加权信号，不能作为唯一判据。

第二步：用行为序列区分"换了 IP 的人"和"没换 IP 的机器"

结论：同一个采集器即使换了 1000 个 IP，其请求序列的统计特征也几乎不变。

三个可落地的特征：一是请求间隔方差，真人间隔从秒级到分钟级波动大，脚本通常高度均匀，方差/均值比小于 0.3 就值得怀疑；二是资源完整性，真实用户很少只请求 API 或详情页而不加载 JS/CSS/图片，采集器常常只取 HTML 或 JSON；三是前端埋点，采集器通常不上报 mousemove、scroll、visibilitychange 事件，全程为 0 的直接降权。

工程上把这三项做成 0–100 的风险分，超过阈值（例如 70）触发验证而不是直接封禁，可以显著降低误杀。

第三步：把采集成本推高到不划算

结论：当单次请求成本超过代理流量成本时，采集在经济上自然停止。

手段包括四项：返回体膨胀——对可疑会话返回大量无效字段的 JSON，例如用 1MB 载荷换 5KB 真实数据，住宅代理按流量计费，成本直接放大 200 倍；Proof-of-Work——要求客户端解一个 SHA-256 前导 20 位为零的哈希，正常浏览器 200–500ms 完成，脚本批量跑就要堆 CPU；动态令牌——页面内嵌一次性 token，与 Cookie、时间戳、UA 绑定，有效期 30 秒，且不可跨 IP 复用，这一点正好克制轮换 IP 的池子；蜜罐字段——表单里放 display:none 的隐藏 input，真人不会填，填了的直接进黑名单。

怎么判断防护有没有生效？

结论：只看拦截量没有意义，要看"每万次请求的真实数据获取量"。

建议监控三个指标：日活用户误杀率控制在 0.1% 以下；可疑流量拦截率 90% 以上；平均单次数据获取成本（含对手的代理流量支出）相对基线提升 10 倍以上。每周抽样 100 个被拦截会话人工复核，误杀率一上升就调低阈值。

总结一下：应对代理 IP 池的思路是"不追 IP，追不变量"——复合键限速抓住会话，JA3/HTTP2 指纹抓住客户端，行为方差抓住脚本，PoW 与流量膨胀抬高成本；IP 封禁只保留在兜底层，比如对已知数据中心 ASN 直接下发验证，而不要作为主力手段。