检查 Clash 订阅响应类型时，应优先使用不下载、不转发正文的信息。MDN 将状态码定义为请求是否成功完成的标志，并按五类分组。类型判断可以停在「类别、具体数字、是否有正文、是否重定向」，而不需要把订阅正文粘贴出来。对 GET，200 才会在正文中传输资源；HEAD 成功时包含表示头、不含正文，适合用来看状态而不取出配置内容。
适用条件
适用于需要向他人说明「这次响应是成功、重定向、客户端错误还是服务器错误」，或需要自己留档，但订阅内容不能外传的情况。已经把正文保存到聊天记录里的，不属于本方法。请求未完成、没有状态码时，只能记录「无状态码」，不能编造类型。
检查步骤与判断依据
- 记录三位状态码和所属区间：100–199 信息性，200–299 成功，300–399 重定向，400–499 客户端错误，500–599 服务器错误。这已经能区分「拿到资源表示」和「被要求跳转、认证或稍后重试」。
- 能使用 HEAD 时，先看 HEAD 的状态码。HEAD 的 200 只带表示头、没有消息正文，因此不会把订阅内容带出。若 HEAD 得到 405，表示目标资源不支持该方法，再改用 GET，但不要把 GET 正文写入记录。
- 标注有没有正文。204 明确无内容。206 是部分内容，类型是「不完整表示」而不是完整订阅。200 的 GET 才有完整消息正文。不要为了证明类型而复制正文片段。
- 标注重定向。301、302、303、307、308 都应记下「发生了跳转」以及最终状态码，不要把中间码和最终码写混。303 的后续必须是 GET。最终若为 401、403、404、503，类型分别是未认证、已知身份但禁止、找不到资源、服务未就绪；503 还可能带有说明页，仍不要保存该页。
- 对外只提供类别、数字、是否无正文、是否跳转、方法是 HEAD 还是 GET。能够据此复现分类，却无法据此重建订阅，即满足不泄露。若数字未出现在标准列表中，按非标准响应记下原值，不要改写成邻近的标准码。
失败时下一步
HEAD 与 GET 状态码不一致时，以实际拉取订阅的那次 GET 为准，同时记下差异，不要猜测。406 表示内容协商后没有符合客户端条件的内容，可记录「协商失败」，仍不要附正文。415 反映的是请求里的媒体格式不被接受，与「响应是不是网页」不是同一问题，应分开记录。需要提供者协助时，只发送上述脱敏字段。
资料来源： https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status