先确认失败码是 429，再谈重试
Clash 订阅更新是一次 HTTP 请求。MDN 把响应分成五类：100–199 信息、200–299 成功、300–399 重定向、400–499 客户端错误、500–599 服务端错误。429 Too Many Requests 属于客户端错误，含义是用户在给定时间内发送了过多请求（rate limiting）。因此，只有状态码确实是 429 时，才按「离开限流窗口后再请求」来安排；把所有更新失败都当成限流，会套错等待逻辑。
判断依据是状态码及其类别，而不是失败次数。200 表示 GET 已取回资源；304 表示可以继续使用缓存副本。401、403、404 分别指向未认证、无权限、资源找不到，对同一请求立刻重试通常无效。500 是服务端无法归到更具体 5xx 的通用错误；502 表示网关拿到无效响应；503 表示服务尚未就绪（维护或过载）；504 表示网关超时。这些与 429 的「时间窗口内过多」不是同一类安排。
重试安排：停掉连打，等待窗口，只验证一次
适用条件：订阅更新被明确回了 429。此时应先停止对该地址的连续刷新。立刻再发会继续满足「给定时间内过多」的条件，不能当作修复。429 要处理的是速率，不是把同一次请求重复提交到成功为止。
等待时长优先看响应是否带 Retry-After。MDN 在 503 中写明：临时条件应尽量用该头给出预计恢复时间；在 413 中也写明服务端可能返回 Retry-After。若本次 429 响应带有该头，到期后再发出一次更新，而不是按很短的固定间隔轮询。若没有该头，则按 429 的定义离开当前时间窗口：做一次明显长于原更新间隔的等待，然后只重试一次，再读新的状态码。
重试结果要重新分类：落到 200–299，可视为这次更新完成；304 应使用缓存，不必当成失败；仍为 429，说明窗口估计不足，应再拉长空窗，而不是加密集。若变成 503，改按临时不可用处理，并读取 Retry-After。未在 MDN 列出的状态码可能是服务端自定义，不能沿用 429 的等待规则。
仍是 429 时改为降频，套错类别则停止按限流重试
第二次仍 429，应把问题定义为请求频率高于服务端允许的速率。下一步是降低该订阅的更新密度，并避免同一时段对同一资源叠加更多更新。不要在 429 期间改用更短间隔探测，这与限流定义相反。
若状态码已经离开 429：400、401、403、404、408 等应按各自语义停止盲目重试；500、502、503、504 应按服务端故障或临时不可用处理，而不是继续套用限流窗口。安排重试的前提始终是：先读状态码，再决定是否等待、等多久、以及最多试几次。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status