HTTP 状态码速查表 - HTTP 响应状态码大全

现象浏览器控制台只显示网络错误，实际后端返回的是 4xx。

原因跨域场景下浏览器拿不到响应体与状态，失败被折叠成一条泛化的网络错误信息。

处置先用 curl 直连后端确认真实状态码，再回头检查 CORS 响应头，不要按浏览器看到的现象定位。

现象排查 5xx 时改了应用代码却毫无变化。

原因502 与 504 多由网关到上游的连接或等待超时引起，响应根本没到应用层，改应用自然没有效果。

处置先确认应用是否真的在监听，再看网关的健康检查与超时配置，定位顺序不要倒过来。

现象客户端把 301 当临时跳转处理，缓存里留着旧地址。

原因301 会被浏览器与各类客户端缓存，权重也一并转移；服务端改成 301 后旧跳转仍会一直生效。

处置改回源地址前先清掉缓存，或改用 302 作为临时跳转，确认生效后再决定是否固化。

现象网关日志里的状态码和后端实际返回的对不上。

原因反向代理的错误页会用自己的状态码替换上游的真实状态，最终响应里看到的是代理层的结果。

处置调试时绕过代理错误页，或用 curl 直连后端确认它自己返回的状态码。

现象文件上传偶发 413，改小文件又正常。

原因请求体超过代理层的上限，小文件未触发该阈值；限制来自网关配置而不是应用自身。

处置调大 Nginx 侧的 client_max_body_size，并确认应用自身的大小限制同步放宽。

现象限流误伤正常用户，429 出现在完全正常的流量上。

原因限流键的取值维度选错（如按 IP 统计时大量用户共用同一出口 IP），健康流量被算进同一个桶。

处置核对限流键的维度并改成按用户或按接口路径区分，排查前先看 Retry-After 确认真是限流而非其它 4xx。

现象重试逻辑写死固定等待，服务端明确要求等更久。

原因429 与 503 的真实退避时长写在 Retry-After 响应头里，固定 sleep 忽略了服务端给出的节奏。

处置重试逻辑改为读取 Retry-After 后再等待，不要用固定值覆盖它。

现象接口返回 200，但业务上分明是失败。

原因用 200 包业务错误码，HTTP 层无法区分成败，监控与前端只能靠解析响应体才知道结果。

处置把失败映射到对应状态码（认证用 401、权限用 403、参数用 400 或 422），状态码与业务码各管一层。

现象表单提交后浏览器又发了一次 GET，服务端收到的字段全变。

原因302 在重定向时可能把 POST 改写成 GET，表单数据因此丢失；而 303 明确要求改用 GET。

处置需要保持请求方法就用 307；表单提交后跳转这一 PRG 模式按约定改用 303。