429 Too Many Requests：请求频率超限的正确应对
429 Too Many Requests严重程度 Low服务器认为请求来得太频繁，暂时拒绝继续处理。最常见的触发者不是你手动的几次点击，而是设置过密的自动刷新或失败后的自动重试；第一步是停止重试，检查客户端里所有自动化的请求频率设置。
结论
429 是所有 HTTP 错误里最"讲道理"的一个：服务器明确告诉你原因（太频繁）、通常还告诉你解决办法（等多久，见 Retry-After 头）。它的正确应对是做减法而不是做加法——减少请求，等待冷却。而人类面对失败的本能恰恰是加法：多点几次、让脚本再跑一轮。这条页面的一半篇幅在讲为什么那个本能是错的。
适用环境
- 全部平台
- 订阅更新、API 调用、自动化脚本场景
一分钟快速判断
- 停手：立刻停止一切手动重试和自动任务，这是唯一正确的第一步；
- 找计数器：谁在替你发请求？客户端的订阅自动更新间隔、节点延迟自动测试频率、脚本的循环、多设备的同一账号——挨个检查它们的频率设置；
- 看 Retry-After：运行下方检测，报告若含 Retry-After 证据，按它给出的秒数（或时间点）等待后再试一次，通常直接恢复。
这条错误代表什么
限流器在服务端按某个维度计数：每 IP、每账号/token、每接口全局。你需要粗略判断自己撞的是哪个维度，因为对策不同：
- 按出口 IP：共享出口（同一节点的其他用户、同一公司出口的同事）会共享同一个计数器——"我什么都没做也 429"的谜底通常在这里。换出口立即恢复是其特征；
- 按账号/token：多设备共用同一订阅或 API key，各自的自动任务叠加超限。换出口无效、换账号有效；
- 全局限流：服务端在高负载时收紧阈值，所有人一起 429。等待是唯一解，通常伴随服务方公告。
ConnProof 如何判断
connproof subscription "https://目标地址"证据要点：429 状态码本身、Retry-After 响应头的值（如果服务端提供）、以及各层网络证据正常（限流不是网络问题的又一实证）。检测本身只发一个请求，不会加重限流。
最常见原因
- 自动更新间隔过短：订阅每几分钟刷一次是常见的错误配置，12～24 小时才是合理值；
- 失败重试风暴：脚本没有退避逻辑，失败即重试，请求曲线指数上升；
- 多设备叠加：同一账号在手机、电脑、路由器插件上同时自动更新；
- 共享出口的连坐：计数器按 IP 时的无辜中枪。
Windows / macOS / Linux 排查步骤
- 客户端设置里把订阅自动更新调到 12 小时以上、关闭不必要的定时测速；
- 自查脚本：任何请求循环必须有指数退避（失败后等 1、2、4、8……分钟再试）和最大重试次数；
- 等待 Retry-After 指示的时长（没有该头就等 10～15 分钟）后单次重试验证；
- 恢复后不要立刻把频率调回去——429 的阈值不会因为你刚被限过而放宽。
手机端排查步骤
- 手机 + 电脑 + 路由器三处的自动更新叠加是家庭场景的高频组合，挑一处保留自动更新、其余改手动；
- 手机客户端的"启动时自动更新订阅"选项在反复开关应用时也会累积请求，可考虑关闭。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 换出口后恢复 | 按 IP 限流 + 共享出口连坐 |
| 换出口无效 | 按账号/token 限流（查自己的自动化） |
| 大量用户同时 429 | 服务端全局收紧 |
| Retry-After 后恢复 | 正常限流，调整频率即可 |
| 持续 429 超过一天 | 可能被列入更长期的限制，联系服务方 |
给脚本作者：一个够用的退避实现
如果 429 来自你自己写的自动化，与其调参不如把退避逻辑一次写对。要点四条：初始等待从秒级开始（比如 2 秒）；指数增长每次失败翻倍（2、4、8、16……）；上限封顶（比如 10 分钟，避免退避到天荒地老）；抖动在等待时长上加随机浮动（避免多个实例同步苏醒形成新一轮风暴）。伪代码只有几行：
wait = 2
loop:
resp = request()
if resp.status != 429: break
sleep(min(wait, 600) * random(0.5, 1.5))
wait = wait * 22
3
4
5
6
另外优先尊重服务端的 Retry-After 头——它存在时直接用它的值代替你的计算。这些约定不是繁文缛节：一个带退避的客户端在服务端眼里是"守规矩的重试"，一个裸循环则是"正在进行的攻击"，两者在风控系统里的待遇天差地别，最终决定的是你的出口还能不能继续用。
仍未解决时收集什么信息
- ConnProof 错误码（HTTP-002）与脱敏报告；
- Retry-After 值与实际等待后的结果；
- 你所有自动化请求源的清单与频率（客户端、脚本、设备数）；
- 问题开始时间。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
限流不是惩罚，是保护
最后校正一个心态：429 不代表服务方"针对你"，它是服务端保护自身容量、保证所有用户公平使用的标准机制。一个没有限流的服务反而值得担忧——它在真正的流量洪峰面前会直接倒下，那时你收到的就不是 429 而是 5xx 甚至彻底无响应。理解这一点后，"配合限流"就从憋屈变成了理性选择：把自动化频率降到真实需求水平（订阅一天更新一次绰绰有余）、给脚本加上退避、多设备错峰，绝大多数人从此再也见不到这个状态码。
重新运行检测
等待冷却期结束后：
connproof subscription "https://目标地址" --format markdown --output http-report.md恢复后应得到 2xx 与正常内容类型。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立三维度限流判断与退避原则。