HTTP 状态码排查指南：看到 4xx/5xx 先看哪里
2026-08-06
调接口时看到返回 500，或者线上告警说某接口 502 比例飙升，第一反应应该是：这个状态码到底把锅指向了谁？HTTP 状态码本质上是服务器给客户端的”责任划分书”——4xx 是客户端的问题，5xx 是服务端的问题。看懂这个数字，排查就完成了一半。这篇文章把五大类状态码的含义、最常见的十几个状态码的成因与排查方向系统讲一遍，并厘清两组最容易混淆的状态码：301/302 和 502/504。
五大类状态码：先定位责任方
状态码的第一位数字决定了它的类别：
| 类别 | 含义 | 责任方 |
|---|---|---|
| 1xx | 信息响应，请求已接收，继续处理 | 协议本身 |
| 2xx | 成功，请求已被正确处理 | 无问题 |
| 3xx | 重定向，需要客户端进一步操作 | 看具体配置 |
| 4xx | 客户端错误，请求本身有问题 | 调用方 |
| 5xx | 服务器错误，服务端处理失败 | 服务方 |
实际排查中最有用的一条经验：4xx 不要去翻服务端日志找 bug，5xx 不要怀疑自己的请求参数——当然这只是起点，个别状态码（比如 404 和 502）的责任归属并没有看上去那么绝对，下文会细说。
2xx：成功也有讲究
200 OK：请求成功的通用应答。注意”200 但业务失败”的陷阱——很多接口把业务错误塞进 200 的响应体里（{"code": 4001, "msg": "余额不足"}），监控只盯状态码就会漏报。设计接口时，业务失败应该返回对应的 4xx。
201 Created：资源创建成功，典型场景是 POST 创建订单或用户。规范的实现会在 Location 响应头里带上新资源的地址。如果你的 POST 接口一直返回 200，改成 201 语义更准确。
204 No Content：请求成功但没有响应体，常用于 DELETE 或”提交后不需要回数据”的操作。注意 204 响应不能带 body，有些框架强行塞内容会导致客户端解析异常。
3xx：重定向与缓存
301 Moved Permanently：永久重定向。搜索引擎会把原 URL 的权重（PageRank、收录记录）几乎全部转移到新 URL，浏览器也会缓存这个跳转。
302 Found：临时重定向。搜索引擎认为原 URL 仍然是”正主”，会继续索引原地址，权重不转移。
两者的 SEO 差异是真实的运维事故来源：网站改版换域名时误用 302，旧域名的搜索权重迟迟不迁移，流量暴跌；反过来，A/B 测试、活动页这种短期跳转误用 301，浏览器和 CDN 把”永久”跳转缓存下来，活动结束后用户还在被重定向。一句话原则：永久迁移用 301，临时跳转用 302。
304 Not Modified：不是错误，而是缓存生效的标志。客户端带着 If-Modified-Since 或 If-None-Match 发起条件请求，服务器确认资源没变，回一个 304 让客户端用本地缓存。排查”资源不更新”问题时，先检查是不是缓存头配置过激进；反之，静态资源该 304 却每次都 200，说明缓存策略没配好，白白浪费带宽。
4xx：问题出在请求这一侧
400 Bad Request：请求报文本身不合法——JSON 语法错误、缺必填字段、参数类型不对。排查时先原样打印请求体，对着接口文档逐字段核对。
401 Unauthorized：未认证。名字里有”授权”，实际含义是”我不知道你是谁”——token 缺失、过期或签名错误。检查 Authorization 头有没有带、token 是否过期。
403 Forbidden：已认证但无权限。“我知道你是谁，但你不能访问”。和 401 的区分是排查权限问题的第一步：401 去查登录态，403 去查权限配置、IP 白名单或资源归属。
404 Not Found：资源不存在。注意两种特殊情况：一是网关 404，域名或路由没配对，请求根本没到应用；二是出于安全考虑，有些系统用 404 代替 403 隐藏资源存在性，这时”明明存在却 404”其实是权限问题。
405 Method Not Allowed：方法不对，比如该用 POST 的接口发了 GET。响应里的 Allow 头会列出允许的方法。常见于接口改成 REST 风格后，老代码还在用旧方法调用。
429 Too Many Requests：触发限流。响应通常带 Retry-After 头告诉你多久后重试。客户端要做的是指数退避重试，而不是立刻重发——立刻重发只会让限流更久。如果自己就是服务方，429 飙升说明限流阈值或配额需要重新评估。
5xx：服务端出了问题
500 Internal Server Error：服务端的通用兜底错误，代码抛了未捕获的异常基本都归到这类。排查路径很明确：看应用日志里的堆栈。500 没有更多语义，日志才是答案。
502 Bad Gateway：网关（Nginx、负载均衡、API 网关）向上游服务请求时，收到了无效响应——上游进程挂了、连接被拒绝、或者返回了无法解析的数据。本质是”上游根本没给出像样的回答”。
503 Service Unavailable：服务暂时不可用，常见于主动限流、熔断或停机维护，通常带 Retry-After。和 502 的区别在于 503 往往是有意的自我保护，而 502 是意外的上游故障。503 出现时先检查是不是容量或熔断配置在起作用。
504 Gateway Timeout：网关等上游响应等到超时。上游还活着，只是慢——慢查询、死锁、下游依赖卡死都可能。502 和 504 的区分直接决定排查方向：
- 502：上游挂了或拒绝了连接 → 查上游进程状态、端口、健康检查；
- 504：上游活着但处理太慢 → 查慢日志、数据库查询、下游调用链。
排查时的实用建议
养成一个习惯：看到任何错误状态码，先确认它是哪一跳返回的——是应用服务器、网关、CDN 还是浏览器自己编造的。用 curl -v 看完整响应头，CDN 和网关通常会在头里留下指纹（Server、Via、自定义错误页），这能帮你避免在错误的层级上浪费时间。
遇到不熟悉的状态码，查 HTTP 状态码速查表 比翻 RFC 快得多：它按 1xx 到 5xx 分类列出了所有标准状态码的含义，浏览器里就能直接检索。把这篇文章的排查思路和 HTTP Status Reference 配合着用——状态码告诉你责任在哪一方，排查路径带你找到根因。