订阅更新被限流：429、频繁刷新与缓存策略

补充更新：429、Retry-After 与缓存判读

更新于 2026-10-20 · netcli.net

简答：刚连点几次订阅更新就出现 429？先别删订阅、别清缓存，也不要继续自动刷新。429 通常表示请求频率触发了服务端限流：有 Retry-After 就按它等待，没有就停止重试并采用逐次延长的保守退避；之后只复测一次，再根据响应头判断是限流、缓存、授权还是网络问题。

定义：HTTP 429 Too Many Requests 表示服务端认为客户端在一段时间内发起了过多请求，Retry-After 可告知客户端下一次请求前应等待的秒数或时间点。

30 秒速查卡：先看状态码，再决定是否等待

先做这一步：停止客户端自动更新和手动连点；如果已经处于 429 窗口期，不要为了“检查一下”立即再发起 curl 或 HEAD 请求，因为检查请求本身也可能计入服务端的请求次数。

HTTP 429 的含义和限流范围并不固定，服务端可能按 IP、资源、用户或授权应用区分请求；因此单凭一次 429，不能推断订阅失效或账号被封。可参考 MDN 对 429 Too Many Requests 的说明。

用 curl.exe 查看状态码、Retry-After 和缓存字段

Windows PowerShell 5.1 中，直接输入 curl 可能调用 Invoke-WebRequest 别名；本文命令统一使用 curl.exe。macOS 和 Linux 通常可直接使用 curl。如果刚收到 429，应先按 Retry-After 等待，再只执行一次检查。

把示例地址替换为自己的订阅地址，不要把完整令牌复制到工单、截图或公开日志：

curl.exe --dump-header headers.txt --output subscription.txt --location --silent --show-error "https://example.com/your-subscription"

curl 官方 man page说明，--dump-header 用于保存响应头，--output 保存正文，--location 跟随重定向。检查 headers.txt 时按以下顺序读取：

• 状态行：确认是 429、401、403、5xx 还是 200。
• Retry-After：纯数字按秒数处理；HTTP 日期则等到该时间后再请求。该字段的两种格式由 RFC 9110 的 Retry-After 定义说明。
• Cache-Control：记录是否出现 no-store、no-cache、private、max-age 或 must-revalidate。
• Age：如果出现，说明响应可能经过缓存，并给出缓存估算的响应年龄；缺少 Age 不能单独证明请求直达源站。
• ETag 与 Last-Modified：它们可用于后续条件请求，帮助确认资源是否变化。
• Date：记录本地发生时间及时区，并与响应中的 Date 字段对照，避免把本地日志时间误当成服务端时间。

只查看响应头可使用 curl.exe --head --location "https://example.com/your-subscription"。但 HEAD 也是一次请求，而且部分服务端对 HEAD 的处理与 GET 不同；如果已经收到 429，应先等待，不要用 HEAD 立即重复探测。curl 官方文档说明，--head 会发起 HEAD 请求，--dump-header 可保存收到的协议头，可参考 curl HTTP 请求说明。

Retry-After 缺失时：使用有限次数的退避

有 Retry-After 时，优先采用服务端给出的等待时间；没有该字段时，不要连续点击刷新。下面的伪代码只表达排查逻辑，base、cap 和随机抖动属于经验参数，不是 HTTP 标准阈值。

stop_auto_refresh(); attempt = 0; max_attempts = 2; while attempt < max_attempts: if response_has_retry_after: wait_until_retry_after(); else: wait(min(cap, base * 2**attempt + random(0, jitter))); response = retry_once(); if response.status != 429: break; attempt += 1; stop_auto_refresh()

• 第一次出现 429 后，先停止自动更新和手动连点。
• 有 Retry-After 时，等待时间不得短于服务端提示。
• 没有 Retry-After 时，采用逐次延长的等待，并设置最大尝试次数。
• 再次收到 429 后停止循环，保存时间、状态码和响应头，不继续试探。
• 成功取得响应后，先确认正文确实是预期格式，再恢复较低频率的更新。

服务端可能按 IP、账号、令牌、资源路径或授权应用实施限流。假如系统代理、客户端代理或其他网络出口改变了请求的公网 IP，那么它可能影响“按 IP 限流”的观察结果；但这只能用于比较故障范围，不能据此规避服务端策略。多台设备共用同一出口或同一授权账号时，也应把并发更新纳入排查。

条件请求怎么做：用 ETag 或 Last-Modified 判断内容是否变化

如果上一次响应中有 ETag，可以在等待限流窗口结束后做一次条件 GET：

curl.exe --dump-header revalidate-headers.txt --output revalidated.txt --header "If-None-Match: <上次响应中的ETag>" "https://example.com/your-subscription"

如果没有 ETag 但有 Last-Modified，可以使用：

curl.exe --dump-header revalidate-headers.txt --output revalidated.txt --header "If-Modified-Since: <上次响应中的Last-Modified>" "https://example.com/your-subscription"

根据 RFC 9111《HTTP Caching》，条件请求得到 304 Not Modified 时，表示已有的缓存表示仍可复用，通常不需要重新传输完整正文；如果得到完整的 200 响应，则应以新的响应和响应头为准。不要把 ETag 值、订阅令牌和完整正文公开分享。

缓存字段怎么读：不要一遇到 429 就清缓存

本地客户端缓存、系统代理缓存、中间缓存和服务端限流解决的是不同问题。缓存可能让你看到旧内容，限流则是服务端拒绝过密请求；清除本地缓存不会自动解除服务端限流，反而可能触发新的订阅请求。

因此，遇到 429 时的第一步不是清缓存、删订阅、重装客户端、换 DNS 或重新生成链接。只有在确认状态码不是 429、确认客户端本地确实读取了错误副本，并且已经备份当前配置后，才考虑清理本地缓存。

安全恢复顺序：等待、单变量、确认内容后再恢复更新

1. 停止自动刷新：关闭客户端中的自动更新任务，或暂时退出会周期性拉取订阅的程序。
2. 保留旧配置：不要先删除当前配置，记录最近一次成功更新时间和客户端版本。
3. 脱敏保存信息：保留状态码、Retry-After、Cache-Control、Age、ETag、Last-Modified、Date 和错误时间；删除完整订阅地址、令牌及正文中的敏感内容。
4. 按提示等待：有 Retry-After 就按秒数或日期等待；没有则使用有限次数的保守退避。
5. 单变量复测：保持客户端和订阅地址不变，只比较当前网络与另一网络，或只检查一次响应头，不要同时换链接、清缓存、改 DNS 和重装客户端。
6. 确认响应内容：状态码为 200 不代表客户端已经载入新配置，还要确认正文格式和更新时间符合预期。
7. 恢复更新周期：确认成功后再恢复较低频率的自动更新；只有配置确实发生变化时才手动更新。

如果持续是超时、证书错误或 5xx，应转到订阅地址更新失败的链接、网络与证书排查；如果响应成功但导入后为空或内容异常，可继续查看订阅导入失败的格式与链接检查。如果你需要检查已经脱敏的订阅文本格式，可使用订阅文本检查器，不要上传包含令牌的原始地址或完整配置。

本文只说明 HTTP 请求、缓存和客户端排查方法，不能仅凭一次响应判断账号状态或服务端限流的具体维度。

提交给服务方前的自查清单

• 记录本地发生时间及时区，并与响应头中的 Date 字段对照。
• 记录 HTTP 状态码，以及是否存在 Retry-After。
• 说明 Retry-After 是秒数还是 HTTP 日期。
• 保存 Cache-Control、Age、ETag、Last-Modified、Date 和 Location。
• 记录客户端名称、系统类型、是否开启自动更新，以及最近一次成功更新时间。
• 说明问题是否只在某个网络、出口、多设备或某个配置下出现。
• 分享错误文本前删除完整订阅地址、令牌、Cookie 和配置正文。

常见问题

订阅更新出现 429，是不是订阅失效或账号被封？

不能仅凭 429 得出这个结论。429 表示请求频率触发了服务端限流，限流可能按 IP、资源、用户或授权应用实施。先停止刷新，按 Retry-After 等待，再进行一次脱敏复测。

Retry-After 是数字和日期时，分别怎么处理？

纯数字按秒数处理；HTTP 日期按该时间等待后再请求。两种格式可参考 RFC 9110。没有 Retry-After 时，不要连续点击，采用有限次数的逐次退避，再次收到 429 就停止。

Windows PowerShell 里为什么不能直接使用 curl --dump-header？

Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的别名。本文命令使用 curl.exe，避免参数被 PowerShell 命令解析。也可以先运行 Get-Command curl 确认实际调用的程序。

遇到 429，清缓存或换 DNS 有用吗？

不应作为第一步。清缓存可能触发新的拉取请求，换 DNS 也不能直接改变按 IP、账号或令牌实施的服务端限流。先记录状态码和响应头，再判断是否确实存在本地旧副本或 DNS、线路问题。

条件请求返回 304，说明订阅更新成功了吗？

304 表示资源验证后没有变化，缓存中的表示可以继续复用；它不等于订阅正文发生了更新。如果需要新内容，应等源内容确实变化后再按正常流程确认客户端是否重新载入。

返回 200 但客户端仍显示旧订阅，算不算限流？

不一定。可能是 HTTP 缓存复用、源内容尚未变化、客户端未重新载入或导入格式异常。检查 Age、ETag、Last-Modified、Cache-Control，并确认响应正文格式。

相关阅读

• 订阅地址更新失败的链接、网络与证书排查
• 订阅导入失败的格式与链接检查
• 订阅文本检查器

参考资料

1. RFC 9110: HTTP Semantics
2. RFC 9111: HTTP Caching
3. MDN: 429 Too Many Requests
4. curl 官方 man page
5. curl HTTP 请求说明