先锁定“这是一次 5xx 响应”，再开始采集
Clash 订阅更新报失败时，不要先写成“服务器挂了”，而要确认本次请求是否真的收到了 服务器错误响应（500–599）。MDN 把 HTTP 响应分成五类：信息性 100–199、成功 200–299、重定向 300–399、客户端错误 400–499、服务器错误 500–599。只有状态码落在 500–599，采集口径才能叫 5xx。若实际是 404、401、429，或只有超时、连接被重置而没有任何状态码，应改记真实结果，不能补写成 500。
适用条件：你已经能读到这次订阅更新对应的 HTTP 状态码（或等价响应行）。若完全看不到状态码，第一步应记录“无 HTTP 状态码”，而不是假设内部错误。若数字不在 MDN 列出的标准码中，文档写明这是非标准响应，可能由服务器软件自定义——保留原始数字，不要改成“最像的”标准码。
5xx 场景下要逐项记下的信息
状态码必须记精确值。500 表示服务器遇到不知如何处理的情况，且找不到更合适的 5xx，属于泛化内部错误。502 表示当前服务器作为网关去取处理请求所需的响应时，得到了无效响应。503 表示服务器尚未准备好处理请求，常见原因是维护或过载，并被定义为临时状况。504 表示作为网关未能及时从上游取得响应。四者都记成“5xx 失败”会丢掉后续判断所需的分层信息。
对 503，MDN 要求在可能时用 Retry-After 给出预计恢复时间，并提醒注意同响应中的缓存相关头：临时状况通常不应被缓存。因此遇到 503，除数字外必须记下：是否出现 Retry-After、其取值、以及缓存相关头，避免把一次临时不可用当成可长期复用的结果。
对照成功语义一并记录方法与消息体。对 GET，200 的含义是资源已获取并在消息体中传送。订阅更新通常是获取一份配置资源，所以还要记下：请求方法是否为 GET、响应是否带消息体、体是否为空。没有体的 5xx 与“已传回一段内容但状态仍是 5xx”不是同一条证据。时间戳、请求目标 URI、是否同一资源上的连续多次尝试，也应与状态码绑在一起，否则无法判断是单次还是持续。
如何根据采集结果判断，以及缺信息时的下一步
判断依据可以固定为三条。第一，数字是否确实落在 500–599；否则停止按 5xx 处理。第二，若是 503 且带 Retry-After，按临时不可用记录恢复窗口，不要当成配置永久失效。第三，502/504 指向网关与上游，500 指向当前服务器自身未能给出更具体的 5xx——采集时应分开，而不是合并成一条“源站错误”。
若只能看到“更新失败”而看不到状态码，下一步是让这次 HTTP 响应行可被读取（状态码、必要头、是否有体），而不是连续重试把现场冲掉。若有状态码但头缺失，至少固定状态码与发生时间；对 503 优先补 Retry-After 与缓存相关头。此前若已有 200 且消息体已传送，不要用一次 5xx 覆盖那份已成功获取的表示；文档对临时 503 明确提醒通常不应缓存失败响应。把“失败响应”和“本地已有配置”分成两条记录，后续对照才有意义。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status