响应码是证据，不是整个事件
HTTP 错误码描述特定请求的结果。4xx 响应指向请求或访问问题；5xx 响应表示服务器在处理该请求时发生服务端故障。准确的状态码、响应头、响应正文和请求上下文决定下一步应做什么。
先将 HTTP 响应与 DNS、连接或 TLS 故障区分开。如果客户端根本没有收到 HTTP 状态码，HTTP 状态码表无法解释整个问题。保留错误消息，并排查实际失败的阶段。
捕获一份可检查的小型响应
curl --silent --show-error --max-time 20 --dump-header response-headers.txt --output response-body.html https://example.com/
这个公共示例会分别保存响应头和正文。请使用获准目标并检查文件，不要把非空正文视为成功。在 Windows 上，如有需要请使用 curl.exe，以避免 shell 别名造成影响。
对于需要身份验证的 API，在分享跟踪记录前，先删去凭据、Cookie、令牌、个人数据和敏感查询参数。保留方法、端点路径、时间戳和安全的关联标识符。绝不要把完整的 Authorization 请求头粘贴到公开支持帖中。
将常见状态码对应到具体检查
| 状态码 | 典型含义 | 下一步行动 |
|---|---|---|
| 400 / 422 | 请求数据格式错误或不可接受 | 检查架构、字段值和响应详情 |
| 401 | 需要身份验证，或身份验证未被接受 | 检查文档规定的身份验证流程 |
| 403 | 服务器拒绝请求 | 检查权限和策略；不要规避控制 |
| 404 | 资源不存在或未公开 | 检查准确路径、方法和资源标识符 |
| 405 / 415 | 方法或媒体类型不合适 | 比较 API 方法和 Content-Type 要求 |
| 429 | 请求过多 | 遵守适用的 Retry-After 和提供方速率限制 |
| 500 | 服务器遇到意外情况 | 使用关联 ID，并升级提供可复现的证据 |
| 502 / 504 | 网关收到错误响应或发生超时 | 检查上游路径和有界重试策略 |
| 503 | 服务不可用 | 检查服务状态和任何重试指引 |
状态码可能由中间层生成，而不是你希望访问的应用生成。读取响应头和正文来了解上下文。不要仅凭带有品牌标识的错误页面推断故障的确切来源。
不要用同一种方式重试所有失败
重新发送前先修正格式错误的请求。按照文档规定的流程恢复有效授权，不要通过轮换身份或路径来处理。遇到速率限制时，降低请求速率并遵循提供方的延迟指引，不要试图绕过限制。
如果第一次尝试已经成功但响应丢失，重试可能会重复一个改变状态的操作。在重试 POST 之前，检查 API 的幂等性保证和支持的幂等键。只有适合重试的情况才使用有界的尝试次数和退避。
区分已受理的工作与已完成的工作
并非每个 2xx 响应都表示请求的业务任务已经完成。HTTP 202 表示已接受处理，但最终任务仍可能失败。请跟随文档规定的任务或状态资源，而不要立即收集尚不存在的输出。
HTTP 202 指南会单独介绍任务状态的跟踪过程。应把 HTTP 层成功、任务完成和可用输出作为不同检查项。在抓取和数据处理流程中，这种区分尤其重要。
通过受控修正处理问题
设想一个获准的 API 请求返回 415，因为客户端发送了 JSON 正文，却没有使用文档规定的媒体类型。保存响应，将请求与当前 API 契约进行比较，修正请求头和正文的匹配关系，然后重新发送一次有界请求。
如果请求已被接受，在扩大工作量前检查实际响应和任何任务状态。记录发生变化的字段及结果。一份清晰的事件记录应说明哪里出错、改了什么，以及如何验证原始任务。
常见问题与下一步
200 响应可能包含错误页面吗？可以。应用可能在 HTTP 状态成功时返回意外的页面或内容。请验证所需字段和正文。
我应该从哪里继续？请求正文设置可使用现有的 curl POST 指南，文件验证可使用下载指南。Arcvenza 的文档化流程仅适用于受支持的操作和获准目标。
技术参考
MDN: HTTP response status codes · RFC 9110: HTTP semantics · curl command manual
MDN：HTTP 响应状态码 · RFC 9110：HTTP 语义 · curl 命令手册