Retry-After 是什么
Retry-After 告诉客户端「多久之后再来」：值可以是秒数，也可以是完整的 HTTP 日期。它最常与 503（服务暂时不可用）和 429（请求过多）一起出现，也用于 3xx 的延迟跳转。对爬虫、SDK 重试逻辑和网关限流来说，这是服务端给出的权威退避时长，比自己拍一个固定间隔更准确。
基本信息
| 方向 | 响应头 |
|---|---|
| 取值形式 | 秒数（如 120）或 HTTP 日期（如 Fri, 31 Oct 2026 07:28:00 GMT） |
| 常见搭配 | 503 服务不可用、429 请求过多、301/302 延迟跳转 |
| 规范 | RFC 9110 §10.2.3 |
| 缺失时 | 客户端自行按指数退避估算 |
| 缓存影响 | 503 上的 Retry-After 会影响缓存如何暂存该响应 |
典型使用场景
- 限流场景：接口返回 429 并给出建议等待秒数，防止客户端持续冲击
- 发布或维护窗口：服务端返回 503 + Retry-After，客户端与爬虫据此挂起
- 批量任务编排：任务队列按该值安排下一轮拉取，避免无效轮询
- 搜索引擎抓取节流：站长侧的限流策略会通过它影响抓取节奏
- 延迟跳转：用 301/302 + Retry-After 让客户端稍后再跳，减轻瞬时压力
读取并按其退避
读取并按其退避
# 从响应中取出等待秒数
curl -si https://api.example.com/expensive \
| awk 'tolower($1)=="retry-after:"{print "wait", $2, "seconds"}'
# 响应示例：HTTP/1.1 429 Too Many Requests + Retry-After: 30
# 失败重试时叠加随机抖动，避免所有客户端同一时刻重来
# sleep $(( RETRY_AFTER + RANDOM % 5 ))搭配状态码
| 状态码 | 含义 | Retry-After 的作用 |
|---|---|---|
| 429 | 请求过多，触发限流 | 告知配额恢复所需时间 |
| 503 | 服务暂时不可用 | 告知维护或过载恢复时间 |
| 500 / 502 | 服务端错误 | 规范未强制，但给出可减少重试风暴 |
| 301 / 302 | 重定向 | 让客户端延迟发起跳转 |
| 200 | 正常响应 | 无意义，客户端应忽略 |
重试逻辑应把 Retry-After 当权威指令：有它就按它等，没有才退回自己的指数退避；同时叠加随机抖动，否则大量客户端会在同一秒集中重试，形成新的尖峰。
两种取值形式（秒数、HTTP 日期）必须都解析：服务端若返回日期而客户端只 parseInt 秒数，解析会失败并静默退化成「立即重试」，反而加重限流。