代理IP请求返回 429 Too Many Requests，含义通常是某个限流器暂时拒绝继续处理，而不是代理入口一定失效。限流维度可能是目标站看到的出口IP，也可能是账号、Token、接口路径、并发连接、请求体或代理套餐配额。排查时应先确认限制来自哪一层，再按服务方规则降低速率；不要把频繁更换IP当作绕过限制的方案。
先记录响应，而不是立即重试
在自有系统或已获授权的接口上保存状态码、响应头、请求路径、客户端标识和时间戳，响应体只保留必要的脱敏片段：
curl -sS -D /tmp/headers.txt -o /tmp/body.txt --proxy http://user:password@proxy.example:port https://api.example.test/v1/resource
sed -n '1,40p' /tmp/headers.txt
重点查看 Retry-After、服务自定义的限流头、请求ID和缓存相关头。Retry-After可能是秒数，也可能是HTTP日期；如果没有该字段，不要自行假定固定等待时间。
把429与相邻状态码分开
- 429：服务明确表示请求频率或配额暂时超限，通常应减速并等待。
- 403：更常见于权限、策略或风控拒绝，继续重试通常没有帮助。
- 503：可能是服务端暂时不可用，是否重试要看服务文档和响应头。
- 407：代理认证失败，应先检查代理账号、密码、端口和协议格式。
如果同一请求在直连和代理下都返回429，限制可能绑定账号、Token或接口配额；如果只有某个代理出口返回，才有必要把出口IP作为一个待验证变量，并向代理服务商核对配额和共享情况。
按四个维度做最小对照
固定请求方法、URL、请求体和客户端版本，只改变一个变量：
- 同一账号、同一出口，降低并发和频率，观察429是否消失。
- 同一账号、不同合规出口，判断限制是否与出口IP相关。
- 同一出口、不同接口路径，区分全局配额和单路由限流。
- 同一路径、不同授权范围，确认是否触发账号或Token配额。
每组测试都要记录开始和结束时间、请求数量、并发度和响应头。没有这些上下文，单看“换IP后恢复”无法证明根因。
重试必须满足等待、退避和幂等
收到 Retry-After 时，优先遵守服务端给出的等待窗口；没有窗口时，使用带随机抖动的指数退避，并设置最大重试次数和总超时。GET、HEAD等幂等请求通常更适合自动重试；创建订单、提交表单或触发任务的POST必须依赖业务幂等键或服务端明确支持，否则重试可能造成重复操作。
第1次失败：等待服务端给出的窗口
后续重试：min(上限, 基础等待 × 2^n + 随机抖动)
达到次数或总时长上限：停止并转人工/队列处理
重试队列应按账号、接口和出口分别设置预算，避免一个热点任务拖垮整个代理池。日志记录请求ID和幂等键即可，不要记录完整Cookie、Token或代理密码。
检查代理服务自身的限制
代理服务可能对并发连接、每分钟请求数、带宽、账期配额或单个出口设置上限。对照代理控制台的用量、返回头和服务日志；如果只有通过代理的请求出现429，且目标接口确认未触发限流，应向服务商提交脱敏的时间线和请求ID，而不是连续刷新或批量换节点。
修正后的验收清单
- 确认状态码来自目标服务还是代理入口，并记录响应头。
- 解析Retry-After，验证等待后单次请求能否成功。
- 在固定变量的对照实验中区分IP、账号、路径和并发维度。
- 为幂等请求启用带抖动退避，为非幂等操作设置幂等键或人工确认。
- 观察一段时间的429比例、成功率和队列长度，确认没有反复触发。
429的正确处理是尊重限流、降低请求压力并让服务恢复，而不是追求“换一个IP继续冲”。只有在授权范围内完成维度对照，才能判断是目标接口策略、账号配额还是代理服务限制。
