小批量采集时一切正常，一上百万级就开始翻车：
- 任务跑到一半，全是超时和状态码 429
- 日志里总是那几条 IP 在挨打
- 新 IP 不停加，封得越来越快，成本一路飙升
多半不是代理本身不行，而是 IP 池设计和轮换策略太粗：出口分工不清、轮换要么太频繁要么太集中、并发完全靠感觉开。
下面按现象、原则、策略、模板四步，把一套能扛百万级采集的思路讲清楚。
================================
一、采集上量后最典型的几种崩法
1、量一大，错误率陡增
小规模测试几乎不报错，一上量就开始：
- 前半段正常，后半段大量超时和连接重置
- 某些 IP 连续返回状态码 429 或验证码页
- 速率越来越慢，最后只能停任务
说明目标站和代理池已经被打到过载。
2、池子看着大，真的在干活的就几条
常见现象是：
- 日志里高频出现的只有少数 IP
- 很多节点几乎没有请求，却在持续计费
- 被封掉的总是那几条常用出口
轮换不均衡，调度层没有真正做到按池分摊压力。
3、IP 死得快，越加线越不稳
表现为：
- 新线刚加上，一轮任务下来又黑了一批
- 某些站点几天就要大换血
- 采集量没实质提升，代理账单先翻倍
根源还是粗暴：池无分工，轮换无规则，并发无上限。
================================
二、设计 IP 池前要想清楚的三条原则
1、分工清晰，一类任务一类池
不要让一批 IP 干所有活，至少要拆出几类：
- 重页面采集和轻量接口采集分开
- 需要登录态和纯游客访问分开
- 业务访问和纯采集分开
同一个出口既跑登录，又跑高频采集，既像真人又像脚本，很容易被风控单点标记。
2、轮换可控，在固定集合里轮
轮换是为分散风险，不是制造混乱：
- 单次任务只在固定的小集合里轮
- 一批 URL 固定用一条 IP 或少数几条 IP 跑完
- 有登录态的采集尽量保持账号和出口对应关系稳定
池内可控轮换远比全池随机乱跑安全得多。
3、并发有上限，不靠运气试
并发必须有硬规则：
- 单站点总请求频率设上限，例如每秒二十到五十次
- 单 IP 请求频率设小上限，例如一到三次
- 对敏感接口单独再限一层
有了这些边界，局部抖动不会轻易拖垮全局。
================================
三、IP 池和轮换策略怎么搭
1、按任务类型拆出三类池
先按任务粗分三类，再考虑细调：
- 页面池
- 抓商品详情页、列表页等重页面
- 以机房 IP 为主，数量充足
- 总容量大，请求频率收紧
- 接口池
- 抓结构化数据接口
- 可混合少量住宅和机房
- 单 IP 请求频率可以略高
- 登录池
- 登录、验证码、人机校验、获取 Cookie
- 以住宅 IP 为主
- 账号级采集先在这里拿 Cookie，再交给页面池或接口池跑
接入端约束任务和出口池关系，每类任务只走自己的池。
2、轮换粒度控制在批次级
实用做法是：
- 把一百万地址拆成许多批次，例如每批五百到一千个
- 每批固定使用一条 IP 或少量几条 IP
- 批次跑完再轮换接口，不在每个地址上轮换
这样：
- 统计清晰，哪条 IP 状态好坏一目了然
- 封禁可控，某条 IP 出问题只影响自己的批次
- 行为自然，更像几台忙碌的机器，而不是每页一个新出口
3、重试策略和轮换一起设计
按错误类型区分处理：
- 网络抖动类错误
- 同一 IP 上重试一到两次
- 再失败就换下一条 IP，并标记当前 IP 状态不佳
- 明显限频和验证码
- 降低该 IP 权重，延后再次使用时间
- 同时检查该批次请求频率是否过高
- 永久错误
- 比如地址不存在，直接记失败，不再重试
不要写成任何错误都立刻多次重试并频繁切 IP，只会把局部问题拉成全局雪崩。
================================
四、新手可照抄的百万级采集模板
1、池子规划与绑定
假设场景：
- 一个电商站，每日采集一百万个商品详情页
- 有一百条机房 IP，十条住宅 IP
- 既要抓页面，又要做价监接口请求
可以在代理平台建三类池：
- LOGIN_POOL
- 十条住宅
- 只做登录和 Cookie 获取
- PAGE_POOL
- 八十条机房
- 商品详情页抓取
- API_POOL
- 二十条机房
- 价监接口、库存接口
登录池只养账号，页面和接口由机房池跑量。
2、拆批与并发控制
调度大致按这样来：
- 登录全部走 LOGIN_POOL，保持账号和住宅 IP 尽量稳定
- 一百万地址切成一千个批次，每批一千个
- 为 PAGE_POOL 里的每条 IP 配一组批次列表
- 批次只在自己的 IP 上跑，连续报错才迁移到其他 IP
整个站点总请求频率先压在每秒三十到四十次，每条机房 IP 刚开始限制在每秒两次左右，再根据实测慢慢调高。
================================
五、顺手用易路，让池子和轮换更好管
上面这些策略如果只写在文档里，很难长期执行，落到具体代理平台会轻松很多，这也是不少团队会用易路代理托底的原因之一：
- 易路同时提供住宅、机房、移动多种线路，可以直接按登录池、页面池、接口池三类建线路组
- 面板自带线路分组和标签，脚本只写用哪个组，不用手动维护大堆 IP 列表
- 每条线路有延迟和成功率统计，哪条 IP 经常出错、哪个池在高峰表现差，一眼就能看出来
- 多端统一接入，浏览器、脚本和爬虫框架都能用同一套出口策略，避免各写一套
实际落地时，可以先在易路后台建好 LOGIN_POOL、PAGE_POOL、API_POOL 三类线路组和标签，再在调度器里把任务批次绑定到这些标签上，让错误统计和轮换逻辑落在固定出口池上。跑几轮采集，对照易路面板里的成功率和延迟数据，逐步微调请求频率和批次大小，系统会越来越稳。