文字与生活
遇到 429 或 503 要立刻重试吗？看懂 Retry-After
遇到 429 或 503 要立刻重试吗？看懂 Retry-After
订阅更新或网页请求失败后，连续点击重试并不总是正确。HTTP 429 通常表示请求过多，503 表示服务当前无法处理请求；服务器还可能通过 Retry-After 告诉客户端至少等待多久。代理链路中的快速连点，会把临时限流放大成更长的失败窗口。
Retry-After 有两种写法
RFC 9110 定义的值可以是一个 HTTP 日期，也可以是等待秒数：
Retry-After: 120
Retry-After: Wed, 30 Sep 2026 01:30:00 GMT
第一种表示收到响应后等待 120 秒，第二种表示等到指定时间。日期使用 GMT，不能直接把它当成本地北京时间。RFC 对 503 的说明是临时过载或维护可能在一段时间后缓解，并允许服务端给出该字段。
先保存响应头，不要循环刷新
对你有权访问的地址，可只查看响应头：
curl.exe -sS -D headers.txt -o NUL "https://example.com/"
检查最终状态码、Retry-After、Date，以及是否经历重定向。响应头可能含会话标识，分享前先脱敏。没有 Retry-After 也不等于应该高频重试；客户端仍应采用有限次数、逐步增加间隔的退避方式。
区分三类故障
- 429 且有等待时间： 按字段等待，暂停订阅自动刷新和手动连点。
- 503 且有等待时间： 更像服务端暂时不可用；在等待期内换本地端口通常没有意义。
- 连接超时或 502/504： 可能是代理、网关或上游路径问题，先做一次直连与代理对照，再决定是否重试。
curl 的 --retry 会把 429、500、502、503、504 等若干响应视为可重试的临时错误，并在重试之间等待。自动化脚本仍要同时设置总时限，避免在故障时长期占用任务：
curl.exe --retry 3 --retry-max-time 90 --max-time 20 "https://example.com/"
这里的次数和秒数只是演示，应按任务容忍度调整。不要对登录、付款或其他可能产生副作用的请求盲目自动重放。
机场排障里怎样记录
记录北京时间、节点、最终状态码、Retry-After 原值、实际等待时间和下一次结果。同一目标直连也返回 503，证据更偏向目标服务；只有代理路径持续失败，才进一步检查节点或网关。一个状态码描述的是这次 HTTP 结果，并不能单独证明整个机场服务失效。
验收方法
等待指定时间后只重试一次：若恢复，标记为临时限流或维护；若仍返回相同响应，保留新响应头并延长间隔；若不同节点结果一致，不要反复切换制造更多请求。最终应能说明“何时重试、为何重试、最多几次”。
评论