爬虫报429 Too Many Requests怎么办？2026年限流来源、重试退避与动态IP排查

摘要：429 Too Many Requests 表示给定时间内请求过多，不等于 IP 被封；关键是定位谁返回的，按等待与额度处理。

• 429 只说明请求过多，不规定按什么计数。
• 目标站、CDN 与代理网关都可能返回 429。
• 有 Retry-After 按规定等待，缺失则指数退避。

适用人群：被限流打断的采集开发者。

采集任务把并发从 5 提到 30 之后，日志里开始成片出现 429 Too Many Requests；换一批代理出口再跑，429 依旧——这是采集团队常见的示意场景，非实测记录。看到 429 就加重试往往更糟：限流方看到的压力不降反升。处理顺序是暂停密集重试、保存完整响应、定位产生方、按等待与额度规则处理、用小流量验证恢复。很多人上来就问 429怎么解决，答案取决于状态码是谁返回的：目标站点、CDN、代理网关，含义和处理完全不同。误判产生方的代价很高：对网关限流只降速没用，对目标限流只换出口也没用。下文按定位、降压、退避、网关额度与动态IP的关系逐层展开。

目录

• 一、429快速判断：先定位是谁返回的
• 二、目标限流先降总压力
• 三、Retry-After与退避落地
• 四、代理网关429为什么换IP没用
• 五、动态IP与429什么关系
• 常见问题 FAQ
• 相关文章推荐
• 总结

一、429快速判断：定位是谁返回的

同一个 HTTP 429 状态码，来自不同环节含义不同。对照下表逐行操作，每次只改一项。

能产生 429 的有三层：目标站点或其前方的 CDN、代理网关与客户端包装层。Cloudflare 文档说明边缘节点可生成 429；urllib3 的 Retry 会把 429 纳入自动重试。RFC 6585 第 4 节只定义「给定时间内请求过多」，不规定如何识别与计数，不等于 IP 被封。

定位靠完整证据，保存这些字段：

1. 时间与脱敏 URL；
2. 状态码与 Retry-After 响应头；
3. 请求 ID 与正文 error.code；
4. 客户端版本与代理端点；
5. 并发、速率与已重试次数。

二、目标限流先降总压力

确认 429 来自目标站或 CDN，方向只有一个：降总请求压力。零散的「慢一点」不够，要成体系地改：

1. 停掉重复失败的任务，避免继续消耗额度。
2. 核对目标官方政策与 robots 约定，确认被允许的频率范围。
3. 同时限制速率与在途并发，只限其一容易留缺口。
4. 多个 worker 共用同一个限速队列：各自低速不等于全局低速，要按凭证汇总统计。
5. 做缓存与去重，用增量采集代替全量重抓，这是典型的爬虫限流应对思路。

恢复判定不能看单次结果：低负载观察窗口内 429 比例明显下降，且持续拿到有效业务数据才算恢复；单次 200、空白页、验证码页都不算数。降下来的速率要覆盖所有入口，包括定时任务、手动补跑与其他环境的副本。

排查需要可对照的出口环境，IPdodo 动态住宅IP面向采集场景。

三、Retry-After与退避落地

目标返回 429 时可能带 Retry-After 头，格式有两种：整数秒，或一个 HTTP 日期。

Retry-After: 120
Retry-After: Wed, 04 Nov 2026 08:00:00 GMT

头部有效就按秒数或日期等待，超过任务总预算就终止或重新排队。头部缺失才用有限指数退避：时长按倍数递增、叠加随机抖动，设最大尝试次数与总预算。多个实例要共享冷却状态，避免同一时刻集体重试形成重试风暴。

一个基于 requests 的示意实现，仅演示读操作：

import random
import time

import requests

MAX_ATTEMPTS = 5
BUDGET_SECONDS = 300

def get_with_backoff(url):
    deadline = time.monotonic() + BUDGET_SECONDS
    delay = 1.0
    with requests.Session() as session:
        for _ in range(MAX_ATTEMPTS):
            resp = session.get(url, timeout=(5, 20))
            if resp.status_code != 429:
                return resp
            retry_after = resp.headers.get("Retry-After", "")
            if retry_after.isdigit():
                wait = int(retry_after)
            else:
                wait = delay + random.uniform(0, delay)
                delay = min(delay * 2, 60)
            if time.monotonic() + wait > deadline:
                raise RuntimeError("超出总预算，终止或重新排队")
            time.sleep(wait)
    raise RuntimeError("达到最大尝试次数")

# 仅演示 GET/HEAD；POST 要确认接口幂等方可重试

POST 请求要确认接口幂等性，否则重试可能产生重复数据；退避参数按目标官方政策与自身任务预算设定，不要无限重试。

四、代理网关429为什么换IP没用

429 也可能由代理服务主动返回，并附带供应商自己的细分码。sr_rate_limit 表示按目标 host 动态节流，repeat_query_rejected 表示短时间内的重复查询被拒、要求至少等待 15 秒；同类还有按 zone 限速的 bucket_rate_limit 与账户层的 client_10110。状态码相同，细分码不同，含义与处理方式就不同。

网关侧 429 的处理按四步走：

1. 读响应里的细分码与专有响应头，确认限制类型；
2. 核对账户与 zone 的剩余额度和总速率；
3. 按规定时长等待并降低请求速率；
4. 额度确实不够，再向供应商申请扩容。

为什么换 IP 常常没用：账户或 zone 级别的共享限制不会因为换出口而增加。有过明确反例——同一账号下共享额度，换多少个出口节点，429 依旧。这类限制的出路只有等待、降速或扩容；申请扩容也要附上细分码、速率与等待记录，才能判断是峰值还是常态不足。

五、动态IP与429什么关系

动态IP是出口管理能力，不是通用的 429 修复手段，解决的是出口层问题：节点失效替换、出口故障定位、授权多出口任务的调度。只有证据表明 429 与特定出口相关时，换节点才是对症分支；目标按账号计数时换出口没有意义。

在明确的网络分支里，值得核对节点可用性、会话保持、生命周期与全局调度；「轮换即可突破限制」不成立。

选择这类服务时，该核对接入配置、会话保持需求、节点可用性与额度文档，而非「高信誉出口即可修复」的宣传；固定IP同样不是通用修复。做长期采集前，可参考海外静态IP选购的避坑要点核对参数口径。

降速之后仍然 429，按清单继续查：

1. 是否有其他 worker 共用同一凭证，绕过了本进程限速；
2. 重试是否层层叠加，实际速率远高于配置值；
3. Cookie 会话是否不一致，被目标判定为异常；
4. 客户端版本是否过旧、与网关不兼容；
5. 要求的等待时间是否真的结束了。

常见问题 FAQ

429 是不是 IP 被封了？

不是。429 只表示请求过多，可能按 IP、账号或会话计数；封禁更常表现为 403 或连接失败。

为什么换成动态IP之后还是 429？

换出口只改变来源 IP；限额记在账号或 zone 上时，共享额度不随换出口增加。

没有 Retry-After 要等多久？

没有统一标准。惯例是有限指数退避：起步翻倍、加随机抖动，设最大尝试与总预算，超预算就终止或重新排队。

降了并发为什么还报 429？

常见原因是多 worker 各自限速、全局超标，重试叠加抬高实际速率，或其他任务共用同一凭证。按全局总速率核对。

收到 200 就算恢复了吗？

不算。200 可能是登录页、验证码页或空白页；要看窗口内 429 比例下降且持续拿到预期字段。

相关文章推荐

	动态住宅IP和静态住宅IP的区别：2026年6维度对比与4步选型指南
	如何购买高质量的住宅IP服务？2026年5大硬指标与5步购买流程
	如何选择稳定的住宅IP供应商？2026年稳定住宅IP的5大硬指标与4步验证指南

总结

回到开头的问题：429 Too Many Requests 不是 IP 被封的同义词，而是「请求过多」的限流信号，可能来自其中任何一层。处理主线是暂停密集重试、保存响应、定位产生方、按等待规则退避、小流量验证。目标限流就降总压力，速率与在途并发一起限，多 worker 共享限速队列；网关限流就读细分码、核账户与 zone 额度，共享限制不会随换出口消失。动态IP是出口管理能力而非通用修复，只在出口相关的分支里讨论节点可用性与会话保持。需要稳定对照环境排查限流的团队，可以了解IPdodo 动态住宅IP方案，把节点管理与全局调度交给服务端，排查精力留给真正的限流来源。