并发开到 50 目标站回 429 Retry-After 写着 60 秒怎么排

并发从 10 提到 50 后，10 秒内出现 187 个 429，响应头 Retry-After: 60，脚本没看这个头，继续按原速重试，429 比例涨到 62%。碰到这种情况，我一般先确认改动有没有真的生效。

原因不复杂，目标站按时间窗口计数限流，超限后给出明确的冷却时间，客户端不看这个头就会在冷却期内反复撞墙。并发高只是触发条件，让情况变糟的是重试策略。

「429 并发限流」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。报错里带路径的，先去看那个路径在不在、权限对不对。

if r.status_code == 429:
    wait = int(r.headers.get('Retry-After', 30))
    time.sleep(wait)

同一份配置存在多处的，先确认改的是被加载的那一份。新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。

备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。

具体做法是，先读 Retry-After 再决定等多久；等待期间暂停整个任务而不是单条重试；并发回落到 10 观察一轮；用令牌桶把速率压到限流阈值以下。

最后用这个标准收尾，按 Retry-After 等待后，429 比例从 62% 降到 1% 以下，整个任务只多花 3 分钟。