遇到 429 要等多久？Retry-After、共享出口与重试排查
遇到 HTTP 429，先停止连续刷新，查看响应里的等待提示和服务方的限额说明。存在有效的 Retry-After 时，至少按它给出的时间等待，再做一次正常请求；没有这个字段时，也不能据此认定可以立即重试。使用 VPN、代理或机场共享出口，并不意味着 429 一定由出口 IP 引起。
本文解决三个问题：怎么读等待时间、怎样判断共享出口只是线索，以及如何避免自动重试让故障扩大。限流规则由具体服务决定，不能用一套固定分钟数解释所有站点。
先确认真的收到 HTTP 429
在浏览器中，优先查看已经记录的失败请求。尚无记录时，先按页面提示等待，再打开开发者工具的 Network 面板进行一次正常操作。选中失败请求，查看 Headers 中的 HTTP 状态和响应头，并记录实际目标主机。Chrome 官方文档说明了这些字段的查看位置。依据：DevTools 请求与响应头
注意区分三种情况：
- HTTP 状态确实是 429：继续按限流响应排查。
- 网页正文或应用弹窗出现数字“429”：还要核对实际请求，可能只是业务提示。
- 名称解析失败、连接超时或 TLS 错误：尚不能按 429 的等待规则解释。
主页能打开、某个接口失败时，记录的是失败接口，不是只记网站首页。订阅更新中的下载、解析与应用阶段，可另看订阅更新失败排查。
429 能说明什么，不能说明什么
RFC 6585 将 429 定义为给定时间内请求过多，响应可以附带 Retry-After。规范没有规定服务端必须怎样识别用户或计数，也可能依据认证凭据、Cookie，按单个资源或更大范围统计。因此，一次 429 不足以证明账号被封、套餐欠费或 IP 信誉差。依据：RFC 6585
把它理解为“需要核对本次请求触发的限制”，比直接判定节点坏了更准确。若实际表现是验证码反复出现，应使用验证码与共享出口排查，两种现象不能相互替代。
Retry-After 的两种写法
这个字段可以表示收到响应后应等待的秒数，也可以给出一个 HTTP 日期。秒数是非负十进制整数，不是毫秒；HTTP 日期需要按其时区解释。依据：RFC 9110 的 Retry-After 定义
| 响应中的形式 | 怎样理解 | 容易看错的地方 |
|---|---|---|
Retry-After: 120 |
收到后等待 120 秒，即两分钟 | 不是 120 毫秒，也不是 120 次重试 |
| HTTP 日期形式 | 等待到字段指定的时刻 | 不要把 GMT 时间直接当作北京时间 |
| 没有该字段 | 按服务文档和错误说明处理 | 不能推导出“没有等待要求” |
秒数例子仅用于解释字段，不是对任何站点的实测。若收到的是日期，记录原值、接收时间与时区；北京时间比 UTC 快八小时。电脑时钟明显不准时，先核对时间，避免把尚未到达的时刻误判为已经过去。
若日期已过去、值无法解析，或正文与响应头要求不同，保留原始信息并核对服务方说明，不把这些异常自动解释为零等待。等待结束只说明可以按提示再次尝试，不保证下一次一定成功。
共享出口什么时候值得检查
共享代理可能让多个请求呈现相同的来源地址。如果站点明确按 IP 限额，这条信息才有助于解释现象；但服务也可能按账号或令牌统计，单看出口类型无法确定规则。
先核对同一账号是否同时在多个标签页、设备或工具中自动请求。只关闭自己能够确认的重复刷新任务，保持一个正常操作窗口，等待后再观察。不要一边更换节点，一边重新登录、清除 Cookie 并改客户端，否则无法分辨是时间、身份还是路径改变了结果。
| 对照结果 | 可以继续检查 | 不能直接宣布 |
|---|---|---|
| 停止重复请求、等待后恢复 | 原来的请求频率和并发来源 | 不能证明原节点永久正常 |
| 换路径后仍然 429 | 账号、令牌或资源对应的规则 | 不能只认定所有节点都坏了 |
| 只在某条路径出现 | 实际出口、会话及对应时间记录 | 不能仅凭一次差异确认按 IP 限流 |
需要服务方判断时，提供发生时间、目标主机和响应给出的请求编号。以 Cloudflare 托管的站点为例，其官方说明指出，站长可在限流分析中查看相关 429 事件；访客应把记录交给站点维护者核对，而非仅凭页面样式猜测规则。依据：Cloudflare 429 说明
自动重试要同时限制频率与次数
脚本或客户端有自动重试时，先查看它已经发送了多少次、是否有外层定时任务再次启动它。浏览器、客户端和后台任务一起刷新，可能让实际请求数超出你眼前的一次点击。
对于允许重试的暂时性失败，可以逐步延长等待，并加入随机间隔，避免多个任务同时重试；还应设置最多尝试次数或总耗时。AWS 的架构指南同时强调退避、随机间隔、重试上限，以及避免多层重试相互放大。依据：控制并限制重试
“退避”就是失败后逐渐等久一点，并非越失败越快。它不能取代服务给出的等待要求，也不能解除账号或资源配额。没有统一适用于所有平台的等待序列，应优先采用该服务或工具已有的重试设置。
提交表单、创建订单或修改资源等操作，还要确认能否安全重复。幂等意味着重复调用不会额外产生预期之外的状态变化；不能确认是否已受理时，应先查询结果，而不是把重复提交当成普通网页刷新。依据：重试与幂等性
等待后仍失败，保留哪些信息
完成一次等待和受控重试后，仍持续 429，就整理记录并查看服务公告、账号限额或联系支持。不要用无限循环请求来判断何时恢复。
| 记录项 | 填写内容 |
|---|---|
| 时间 | 首次失败、收到响应、再次尝试的时间及各自时区 |
| 请求 | 应用、目标主机、方法与实际 HTTP 状态 |
| 等待提示 | Retry-After 原值；缺失则明确写“未提供” |
| 身份与路径 | 是否登录、代理接入方式、出站名称；不填写密码或令牌 |
| 请求来源 | 标签页、设备、客户端和定时任务中的已知并发 |
| 结果 | 等待了多久、只改变了哪个条件、响应有何变化 |
日志分享前隐藏 Cookie、认证头和带凭据的完整链接。请求编号只在响应确实提供时记录，不自行编造。
常见问题
没有 Retry-After，就统一等一分钟吗？
没有这个通用规则。先读服务说明，暂停重复任务；若缺少可核实的恢复条件，就有限次观察并提交记录，不把猜测的分钟数写成服务承诺。
503 也带这个字段，等同于 429 吗？
不等同。Retry-After 也可用于 503，表示预计服务暂不可用的时间；判断时要同时看状态、正文和服务公告，不能只看到字段就认定按用户限流。依据：RFC 9110
资料核对日期：2026-10-18。本文说明协议和排查方法，未对任何站点或节点进行限流实测。
评论