恢复之后，什么叫“更新成功”
Clash 在源站或网关从 5xx 恢复后，要验证配置 确实更新成功，不能只看“现在能连上”，而要看这次 HTTP 是否按成功语义取回了资源。MDN 规定：响应是否成功完成，要看状态码所属类；对 GET，200 表示资源已获取并在消息体中传送。因此验证的最低标准是：恢复后的订阅更新请求落在 200–299，并且对 GET 而言消息体里出现了配置资源本身。
适用条件：此前失败是服务器错误（500–599），尤其是 503 这类被定义为临时状况、可能带 Retry-After 的不可用。验证应发生在该临时窗口结束之后的一次新请求上，而不是复用失败当时的响应。文档明确：临时 503 通常不应被缓存，验证时必须发新的获取，不能把旧的 5xx 缓存当成“还没好”或“已经好了”的依据。
用状态码和消息体做正向验证，并用 304/203/206 做反向排除
正向验证分三步。第一步，新请求的状态码离开 5xx。若仍是 500（内部无法处理且无更精确码）、502（网关拿到无效上游响应）、503（仍未就绪）或 504（网关超时），则服务未恢复到可完成请求的程度，谈不上配置已更新。第二步，状态进入 200–299。第三步，确认是 GET 且 200 带消息体——这才对应“资源已获取并传送”。缺少第三步，只说明服务器开始回成功码，不说明新配置文本已经到达。
反向排除同样必要。304 告诉客户端响应未修改，可以继续使用原来的缓存副本：它证明的是“不必换体”，不是“这次拉到了新配置”。若恢复后只看到 304，只能验证缓存仍有效，不能声称配置已更新。203 表示元数据并非与源站完全一致、可能来自本地或第三方副本，用来宣称“已与源站同步”依据不足。206 只传送资源的一部分，不能当作整份配置更新完成。204 成功但无内容，更没有可替换的配置体。202 表示已接受但尚未处理，HTTP 无法稍后异步告知最终结果，因此也不能当作更新已落地。
若恢复前是 503，还应核对本次是否仍携带把临时错误长期留下的缓存头。文档要求管理员谨慎处理 503 的缓存相关头；验证侧则应避免把那次临时响应当作可复用结果。带 Retry-After 时，在该时间之前得到的任何成功以外的结果，都不应记为“恢复后验证通过”。
判断依据与验证失败时的下一步
判断依据可以写成一句：恢复后的那次 GET 是 200，且消息体中出现了资源，才算配置更新成功。仍是 5xx → 未恢复。304 → 未获取新表示。204/206/203/202 → 未满足“完整源站表示已传送”。401/403/404/429 等 4xx 表示请求已不再按服务器错误处理，但同样没有 200 GET 的资源体，不能记为更新成功。
验证失败时：若仍 503，读取 Retry-After 后再发一次新的 GET，不要在窗口内连续冲刷。若变为 502 或 504，说明就绪问题可能已过，但网关与上游仍未给出有效及时响应，应停止宣称配置已更新。若变为 200 却无体，按“成功码但未传送资源”处理，不能当作订阅已替换。只有状态类、GET 语义和消息体三者同时满足，才关闭这次恢复验证。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status