HTTP 429 是机场断线吗？先读 Retry-After 再决定何时重试

网页或订阅接口返回 HTTP 429 时，服务器已经给了一个 HTTP 响应。按 RFC 6585 的定义，它表示请求在某段时间内过多；这与 DNS 失败、代理完全断线不是同一种现象。具体是谁在限流、按什么范围计数，需要看响应正文和服务方规则，不能仅凭 429 断言节点故障。

第一眼要保存什么

先记录访问的是哪个域名、操作类型、响应时间、状态码 429、错误正文中的说明，以及有无 Retry-After 响应头。截图和日志要遮掉订阅 Token、Cookie、账号和完整带参数 URL。若浏览器页面有“稍后再试”的文案，以实际页面说明为准；不要用脚本持续刷新来“测试恢复”。

示意图：单次请求收到 429 后读取提示、等待、再做一次有记录的复查；下方打叉的连续重试并非解决办法。

正确理解 Retry-After

RFC 6585 说明，429 响应可以带 Retry-After，并非一定存在。RFC 9110 规定该字段可以写成一个 HTTP 日期，也可以写成收到响应后需要等待的秒数。因此先认清字段格式，再安排下一次请求；不要把日期误读成倒计时，或把秒数误读成流量余额。没有该字段时，只能遵循服务方公告或适当放慢操作，不能自行推出固定等待时长。

观察到的情况	下一步
429 且有 Retry-After	记录其原值，按格式等待；到时只做一次复查
429 但没有该字段	查看响应正文和服务条款，停止密集重试
登录或订阅刷新连续 429	先检查客户端是否在后台反复自动刷新，避免多个设备同时触发
等待后仍 429	带脱敏证据联系站点方，确认限制范围与恢复条件

对于创建订单、更新资料等可能产生副作用的请求，响应不明确时先查操作是否已生效，不要自动原样重复提交。更换机场节点也不等于获得新的服务端配额；这只能改变一部分连接路径，不能替代服务方给出的限流规则。机场推荐或协议知识文章谈到 429 时，应把“服务器返回响应”和“网络链路能否连上”分开判断。

验收方法

按提示停止请求，在允许的时间后用同一账号、同一操作只尝试一次，记录新状态码和正文。若恢复正常，再检查后台自动刷新间隔；若继续 429，则停止测试，向服务方提交脱敏时间线。判断依据是实际响应与规则说明，而不是不断换节点后的偶然成功。

可核验来源

• RFC 6585，第 4 节：429 Too Many Requests。核验日期：2026-10-14。
• RFC 9110：Retry-After 字段。核验日期：2026-10-14。