过密的判断依据是 429，不是更新次数好不好看
Clash 自动更新过密，指的是在服务端认定的「给定时间」内，对同一订阅资源发出了过多请求。MDN 对 429 的定义正是：用户在给定时间内发送了过多请求（rate limiting）。因此，是否过密，应以更新请求是否开始稳定返回 429 为准，而不是以「自动更新开着」或「偶尔失败一次」为准。若自动更新返回 200，表示 GET 已取回资源；304 表示可继续用缓存，这两种都不支持「再加密会更准」。
适用条件：自动更新的失败码是 429，或在缩短间隔后由成功变为 429。若失败码是 500、502、504，那是服务端或网关未能完成处理；503 是未就绪（维护或过载），属于临时条件。这些都不能单靠「再设密一点」来验证，也不应当成间隔调好的证据。
调整方式：拉长间隔、取消连打、用一次成功来验证
具体操作应围绕降低给定时间内的请求次数。第一步，停止在 429 出现后立即补发自动更新——立刻补发会继续占用限流窗口。第二步，把自动更新的间隔调整到明显宽于当前仍触发 429 的密度，使相邻两次请求落在不同时间窗口。第三步，只保留一轮自动更新做验证，避免多路同时拉同一 URL，把合计速率再次抬回去。
判断调整是否够：间隔拉宽后，同一订阅的更新回到 200–299，或出现 304（用缓存即可），说明当前密度已被服务端接受。若响应带 Retry-After（MDN 在 503 中要求尽量给出恢复时间，在 413 中也提到可能返回该头），下一次自动更新不应早于该头给出的时间。没有 Retry-After 的 429，不要假设存在统一的「安全分钟数」，只能用「不再出现 429」作为间隔是否足够的判据。
503 若与过密同时出现，仍要分开看：503 可能是维护或过载，临时响应通常还不应缓存；此时即使拉开间隔，也要等 Retry-After 或服务重新就绪，不能把 503 解释成「再密一次就能抢到」。
调宽后仍失败：停止继续加密，改按状态码分流
若间隔已经明显放宽仍是 429，下一步不是把自动更新改得更勤，而是检查是否还有其他来源在同一窗口访问同一资源，使合计仍然过多。继续加密与 429 的定义相反。若状态码变成 401、403、404，应停止用间隔试验定位，改核认证、权限和 URL。变成 500/502/504，按服务端或网关故障处理。变成 503，按临时不可用并读取 Retry-After。未列出的非标准码可能是自定义响应，不能当作调间隔的反馈。自动更新时间的调整，只对「请求过多」这一类失败有意义。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status