代理IP 429解决：先判断限频来源，再做退避、配额和调度治理

程序接入代理后出现 429 Too Many Requests，很多人会立刻换 IP，但这往往不是有效的“代理IP 429解决”方法。429 的含义是某一层认为请求过多：可能来自目标服务，也可能来自代理提取接口、代理网关或企业自己的任务调度器。来源没分清就连续换出口、叠加重试，只会放大请求量和费用。

本文只讨论自有系统、开放接口、公开许可数据和已获书面授权的访问任务。代理 IP 不会增加第三方服务授予的调用额度，也不能用来绕过限流、验证码或访问控制。遇到 429 时，应遵循服务方规则，优先暂停、降频并核对授权配额。

第一步：确认 429 是谁返回的

先保留发生时间、请求阶段、HTTP 状态码、响应头和脱敏后的错误摘要，不要记录 Token、Cookie、完整代理账号或个人信息。然后用“请求走到哪一步”定位来源。

还要注意：同一业务可能同时经过多层限流。代理提取成功不代表目标请求有额度，目标端返回 429 也不等于代理质量差。可使用请求 ID 和分段耗时，把“取代理、建连、业务响应”三段日志关联起来。

第二步：读取 Retry-After，而不是立即重试

如果服务返回 Retry-After，应以其指定的秒数或时间点作为最早恢复参考，并给多台 Worker 加入少量随机抖动，避免冷却结束后同时唤醒。没有该响应头时，也应采用有上限的指数退避，例如 2 秒、4 秒、8 秒，并设置最大等待、最大尝试次数和任务总时限。

重试必须占用原有请求预算。假设一分钟额度为 60 次，正常任务已经发出 55 次，5 个失败任务各重试两次，就会把实际请求推到 65 次。此时增加代理数量不能改变目标端的 60 次额度，反而可能让更多 Worker 同时触发限流。

建议为每个任务设置“重试预算”，而不是只设置 maxRetries：

• 连接超时可在预算内退避重试，并记录是否已到达目标服务；
• 407 转入代理鉴权或白名单检查，不要当成 429 处理；
• 429、验证码和权限提示进入冷却队列，等待规则核对；
• 达到预算后停止自动处理，保留证据并交由负责人判断。

第三步：按限流维度设置配额桶

429 可能按账号、应用、接口、目标域名、出口、时间窗或它们的组合计算。排查时应先阅读官方文档和响应提示，再为已确认的维度建立令牌桶或漏桶。至少设置单接口、单项目和全局三层上限，让低优先级批处理为实时任务让出额度。

例如，一个获授权的库存接口允许每分钟 120 次调用，两个 Worker 各自限制为每分钟 100 次仍会超额。正确做法是让它们共享一个全局 120 次的配额桶，并预留约 10% 给重试和人工验证；批量任务从队列领取令牌，没有令牌就等待，不继续创建请求。

如果 429 来自代理提取接口，应减少“每个请求都取一次新 IP”的做法，按产品允许的有效期管理租约和连接池。统一入口的场景可参考隧道代理 IP的公开接入说明；需要核对代理是否真正可用，可按代理IP验证方法分别验证认证、出口、地区和业务内容。具体能力与限制以当前产品文档和订单约定为准。

第四步：用四个指标验证修复是否有效

不要只看“429 是否消失”。调整后应在相同授权范围、URL 样本和时间窗口内小流量复测，并对比：429 占比、每个有效结果的实际请求数、P95 排队时间、最终有效结果率。若 429 降低但排队无限增长，说明入口流量仍超过可持续额度；若请求数下降而有效结果率不变，说明此前存在重试放大。

上线前再演练三条停止路径：服务返回 Retry-After 时任务能进入冷却；全局额度耗尽时 Worker 不再发请求；配置错误造成连续 429 时熔断器能暂停相关项目。所有阈值和变更都应有负责人、版本号和回滚方式。

代理IP 429解决的核心不是更快换地址，而是定位限频发生在哪一层，尊重服务方给出的恢复条件，再用共享配额、退避、重试预算和熔断控制请求总量。若证据指向代理接入层，可整理发生时间、接入方式、并发、脱敏错误摘要和订单约定，通过悟空代理官网核对当前产品说明或提交协查。