结论先说：代理已经轮换，但目标站仍然返回 429 Too Many Requests，不要马上把问题归到“IP 池不够大”。429 的核心通常是请求频率、并发、账号/会话、目标站配额和出口信誉共同作用。正确顺序是先确认 429 来自目标站还是中间层，再把请求节奏、会话粘性、轮换粒度、目标站规则和代理类型逐项拆开验证。
如果同一批代理在低频、单账号、单任务下正常，一上并发就 429，优先处理请求节奏和任务调度；如果低频也很快 429，再看出口池质量、地区选择、会话参数和目标站是否已经识别同一业务行为。
结论：429 先查请求节奏，再判断代理池
429 Too Many Requests 表示请求过多。MDN 对 429 的说明强调，服务器可能用它表示客户端在限定时间内发送了太多请求，并可能通过 Retry-After 告诉你等待多久。这个边界很重要：429 不是“代理一定坏了”，也不是“换一个 IP 就必然恢复”。
排查时按这个顺序走：
- 确认 429 是目标站返回，还是 API 网关、CDN、代理中间层返回。
- 降低并发和频率，用单线程或小批量请求做基准测试。
- 检查是否把同一账号、同一 Cookie、同一浏览器指纹绑定到了过多 IP。
- 判断轮换粒度是否过粗或过细：每请求换 IP 不一定比稳定会话更好。
- 再评估代理类型、地区、池规模、出口信誉和业务场景是否匹配。
- 最后才扩大 IP 池或更换代理类型。
这套顺序能避免两个常见误判：一是把目标站限流误判成代理质量问题；二是把代理轮换当作唯一解法，反而让账号、会话和行为特征更异常。
第一步：确认 429 出现在哪一层
先看响应体、响应头和日志来源。
如果状态码来自目标网站，通常会伴随目标站自己的错误页、API 错误码、限流说明或 Retry-After。如果来自 CDN 或网关，页面可能显示 Cloudflare、Akamai、Nginx、API Gateway 等中间层信息。不同来源对应不同处理方式。
建议先做三个最小测试：
- 不走代理，用低频请求访问同一个接口或页面，确认目标站本身是否对你的账号、Token 或业务行为限流。
- 走同一个代理出口，把并发降到 1，间隔拉长到 10 到 30 秒，观察 429 是否消失。
- 保持同一请求节奏，只换代理地区或代理类型，观察是否只有特定地区、ASN 或出口段触发。
如果低频也触发 429，说明目标站可能已经按账号、Cookie、Token、设备指纹、ASN 或历史行为限流。这个时候继续高速换 IP，通常只会增加异常信号。
第二步：先降频和控并发，建立可复现基线
代理轮换只是改变出口，不会自动消除请求过快的问题。很多 429 的根因是任务调度太激进：同一时间开太多线程、重试没有退避、失败后立即补请求、分页和详情页同时打满。
先把测试收敛到一个可复现基线：
- 单任务、单账号、单代理出口运行 5 到 10 分钟。
- 设置固定请求间隔，并记录每分钟请求数。
- 关闭自动重试，或把重试改成指数退避。
- 记录每次 429 前的最近请求数、并发数、目标路径和响应头。
- 逐步增加并发，不要一次从 1 拉到几十或几百。
如果并发从 1 增到 5 就开始 429，问题多半不是“代理不够多”，而是目标站对账号、路径或业务动作有低阈值限制。此时应该先优化节奏、队列、缓存和重试策略，再考虑扩池。
第三步：检查账号、Cookie 和会话是否比 IP 更稳定
很多目标站并不只按 IP 限流。账号、登录 Cookie、设备指纹、User-Agent、请求路径、Token、Referer 和行为顺序都可能进入限制规则。
几个典型现象要分开判断：
- 多个 IP 共用同一个账号，仍然 429：优先查账号级配额、Token 配额或接口级限流。
- 每个请求都换 IP，但 Cookie 不变：目标站可能看到同一会话在多个地区快速漂移。
- IP 换了，浏览器指纹不变：对于账号运营或浏览器自动化，单纯换出口可能不足以降低关联。
- 只在某些接口 429：首页正常，搜索、详情、提交或登录接口被限，说明路径级限制更强。
这类情况适合把“IP 轮换”改成“会话稳定 + 低频轮换”。例如一个账号在一段时间内使用固定出口，任务结束或冷却后再换；而不是每个请求都更换出口。需要动态住宅出口时，可以从按会话稳定性选择动态住宅代理入口核对轮换与会话参数；如果要重新比较代理类型和地区入口，可以从按业务频率和地区查看代理服务入口回到主站导航。
第四步：判断轮换粒度是否适合当前任务
轮换太少会让单个出口承受过高请求量；轮换太频繁也可能制造异常。关键不是“越频繁越安全”，而是让出口、账号、会话和请求行为保持一致。
可以按任务类型选择粒度：
- 公开页面采集：可以按域名、分页段、任务批次或时间窗口轮换，重点控制每个出口的请求速率。
- 登录态任务：通常更需要粘性会话，不适合每次请求换 IP。
- 搜索、本地化验证：地区一致性比极高频轮换更重要，要避免短时间跨国家或跨城市跳动。
- API 请求：先读目标 API 的速率限制、配额和重试建议，再决定是否需要多账号、多队列或更低频率。
如果目标站返回 Retry-After，应当把它当成调度输入，而不是忽略后继续重试。RFC 6585 对 429 的定义也提到响应可以包含 Retry-After，这说明等待和退避本来就是处理 429 的一部分。
第五步：什么时候才需要扩大 IP 池或换代理类型
在以下条件同时出现时，再重点怀疑代理池或代理类型：
- 单线程、低频、无重试时仍然很快 429。
- 不同账号、不同 Cookie、不同目标路径都出现相似限制。
- 多个出口段或地区表现明显不同，且差异稳定可复现。
- 目标站对数据中心 ASN、公开代理段或特定地区更敏感。
- 同样节奏下，住宅代理、移动代理、数据中心代理表现差异明显。
如果是公开网页采集，动态住宅代理通常比固定少量数据中心出口更适合分散请求，但仍然需要限速、退避和失败队列。对于账号相关任务，移动或静态住宅出口可能更适合保持会话连续性。对于稳定接口或低敏感度任务，数据中心代理的成本和速度可能更合适。
这里的判断目标不是盲目买更大的池，而是确认瓶颈到底在请求节奏、账号配额、目标站策略，还是出口资源本身。
发布前的自检清单
把 429 排查收口到这几个问题：
- 429 来源已经确认了吗：目标站、CDN、API 网关还是中间层？
- 是否读取并遵守了
Retry-After或目标站公开的速率限制？ - 单线程低频测试是否通过？
- 自动重试是否有退避，还是失败后立即补请求？
- 账号、Cookie、指纹和 IP 的关系是否稳定？
- 轮换粒度是否符合任务类型，而不是每个请求机械换 IP？
- 产品类型、地区和池规模是否与目标站敏感度匹配？
技术边界可以参考 MDN 对 429 Too Many Requests 的说明 和 RFC 6585 中对 429 的定义。实际处理时，先让请求节奏可控，再让代理轮换服务于业务目标；429 消失后，再继续评估速度、成功率、地区稳定性和成本。