成功下载在 HTTP 里长什么样
要确认 Clash 订阅更新的失败发生在 配置内容被取回之前，先要有一条“下载已完成”的对照定义。MDN 对 200 且方法为 GET 的说明是：资源已获取，并在消息体中传送。也就是说，只有状态属于成功类（200–299），并且对 GET 而言出现了承载资源的消息体，才能说新的配置表示已经从 HTTP 层下来。204 表示请求成功但没有要发送的内容；206 只返回范围请求的部分内容。这两种即使算成功类，也不等于“完整配置已下载”。
适用条件：你能看到该次更新的状态码，并能判断响应有没有消息体。若连 HTTP 响应都没有，失败更早发生在连接或传输阶段，同样属于“未下载到配置”，但证据类型不同，应单独标注“无状态码”，不要写成 5xx。
用状态类判断：还没拿到可替换的配置表示
服务器错误 500–599 的总语义是：该 HTTP 请求 没有成功完成。因此一旦订阅更新返回 5xx，就可以判断：这次没有按 GET 成功语义把资源放进消息体。500 是处理者内部不知如何应对且无更精确 5xx；502 是作为网关拿到无效上游响应；503 是本跳未就绪（维护或过载）；504 是网关等上游超时。它们都能证明“新配置没有作为成功 GET 结果传来”，从而把失败钉在下载完成之前。
客户端错误 400–499 同样不是成功完成，例如 404 找不到资源、401 需要认证、403 没有权限、429 短时间请求过多。它们也表示没有按 200 GET 取回资源，失败同样在得到可用配置体之前。与 5xx 的差别只在责任侧，不在“有没有下载到配置”。重定向 300–399 则表示还要跟到另一个 URI 才可能取资源，当前这一跳也尚未完成下载。
需要刻意排除的是 304：它用于缓存，表示响应未修改，客户端可以继续使用原来的缓存副本。304 不是下载失败，而是本次没有传送新的消息体。若把 304 当成“失败在下载之前”，会误伤缓存命中。203 表示返回的元数据并非与源站完全一致、可能来自本地或第三方副本，也不能当成一次对源站的完整新下载。
判断步骤、反向排除与失败时下一步
可按三步确认。第一步：有无 HTTP 状态码？无 → 失败在发出成功请求/收到响应之前，配置体未到达。第二步：状态是否落在 200–299，且为 GET 并带完整消息体？否 → 新配置表示未按 200 语义传送，失败在下载完成之前。第三步：若是 304，结论改为“未重新下载、沿用缓存”，不是失败。若是 204/206，结论改为“没有完整实体”，仍不能视为配置已更新到新版本。
反向排除：一旦出现 200 GET 且消息体非空，HTTP 层已经完成资源获取。此后若 Clash 仍提示配置不可用，问题转到对已下载内容的理解或校验，超出“下载之前”，不能再用 5xx 模型解释。
若状态码读不到，下一步是先让响应行可见，再分类。若只有 5xx 而无体，即可确认没有新的成功表示，不必等待本地出现残缺文件。若 503 带 Retry-After，按临时未就绪处理，窗口内同样视为尚未下载成功，到期后再看是否变为 200 带体。不要把缓存里的旧配置误认为这次已经下载成功。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status