HTTP状态码实战排查手册：从400到504的定位思路与案例

平时排查接口问题，你是不是也这样：看到一个 400，条件反射打开搜索引擎输入"HTTP 状态码 400"，得到一句"请求错误"，然后关掉页面继续懵。状态码单拎出来每个都不复杂，但一旦放进真实的请求链路里，细节多到足以让人翻车。我最近帮几个朋友排查线上问题，从 Nginx 返回的 502、到服务端日志里的 400、再到前端接口 200 但页面死活没数据，每个问题背后都绕不开对 HTTP 状态码的理解。看完这篇，你不需要背下所有代码，但你会知道每个状态码背后到底在表达什么、排查时该往哪个方向下手。

这篇更像个"状态码排查手册"，我会从实际场景出发，把 1xx 到 5xx 拆开讲清楚，每个大类里挑高频和坑多的状态码做深入分析，最后给你一套我平时实际在用的排查命令和日志分析思路。适合刚接触 HTTP 协议的开发者，也适合被各种网关状态码折磨过的运维和全栈同学，即使你已经有几年经验，里面的几个反向代理案例也值得看一眼。

1. 状态码先别急着背，你得先知道它藏在哪一层

1.1 状态码只是响应报文第一行的一串数字

先看一个最简单的 HTTP 响应长什么样：

http复制HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123

{"code":0,"data":[]}

第一行叫状态行，200 OK 就是服务端给客户端的"处理结论"。这里最关键的一点是：状态码不是客户端算出来的，而是服务端返回的。你发出去的请求可能经过浏览器、CDN、Nginx 反向代理、网关、应用服务等多个环节，每一层都可能自己生成状态码。所以当你看到 502 时，第一件事不是搜"502 什么意思"，而是先搞清楚这个 502 是哪一层返回的。

举个我实际遇到的例子。一个本地开发环境里，前端请求 http://127.0.0.1:1572，抓包看到 502，但后端服务日志里什么都没有。最后定位到是本地多了一个代理转发层，请求先打到代理，代理再转发给真正的应用端口，真正的问题其实是代理端口后面的服务没起来。这个案例里，浏览器拿到的 502 是代理生成的，跟后端应用一点关系都没有。你如果抱着"502=后端挂了"的思路去重启应用，重启十次也没用。

1.2 五大类的底层分工，看第一位数字就够了

HTTP 状态码的标准定义在 RFC 9110 里，核心分类逻辑极其简单，只看百位数字：

这个分类对排查来说是决定性的。很多新人排查 403 时拼命改服务端代码，实际上 403 通常是你的请求没有权限或者被网关拦截了，属于客户端侧的问题；反而看到 200 时容易放松警惕，结果响应体里装着一个业务异常。判断大方向永远比背具体数字重要。

1.3 每个状态码背后都是"协商结果"

HTTP 是无状态的请求-响应协议，每次交互都是客户端发起请求、服务端返回响应。状态码就是这个协商过程里服务端给出的"结论"。但要注意，现代系统里客户端和服务端之间往往隔着多层代理，每一层都是独立的 HTTP 服务，也都有自己的"判断权"。

比如浏览器访问一个 HTTPS 站点，浏览器先和 Nginx 建立 TLS 连接，Nginx 再作为客户端去请求后面的 Java 应用。如果应用返回 500，Nginx 可以把 500 原样透传给浏览器，也可能因为配置了 proxy_intercept_errors 而改写成一个自定义错误页，甚至改成 200。这就会形成一个很经典的迷惑场景：浏览器看到 200，页面却显示"系统繁忙"；后端明明报错，前端却毫无感知。理解状态码的产生链路，比背一百个状态码都实用。

2. 没人关心的 1xx 和 2xx，反而藏着不少隐蔽故障

2.1 100 Continue：一个容易被客户端忽略的"握手"

先说 1xx。这类状态码平时不会直接出现在浏览器 Network 面板里，但它在底层经常发生。最典型的是 100 Continue。

当客户端要上传一个比较大的请求体时，客户端会先发一个带 Expect: 100-continue 头的请求头部分，问服务端"我要发一大段数据，你收不收"。服务端如果同意，就回 100 Continue，客户端才继续发送请求体；如果不同意，直接回 417 Expectation Failed 或者 413 Payload Too Large。

这个机制本意是避免浪费带宽，但在实际开发里很容易变成"隐形杀手"。我遇到过用 Nginx 做反向代理时，后端接口动不动就 408 超时，排查半天发现客户端等 100 Continue 等不到。原因是我在 Nginx 里配置了 client_body_buffer_size，但代理层对上游请求没有把 Expect 头处理好，导致客户端一直等，最终触发超时。用 curl 发大请求时，如果加了 -H "Expect:"，就是在告诉服务端"别跟我搞这套，我直接发"，很多调试问题会立刻消失。

2.2 200、201、202、204，成功也分三六九等

2xx 里每个具体代码代表的语义完全不同，这是很多接口设计混乱的根源。

• 200 OK：请求成功，响应体里带了结果。
• 201 Created：请求成功，并且创建了一个新资源，响应头里通常带 Location 指向新资源。
• 202 Accepted：服务端已经接受请求，但还没处理完，常用于异步任务。你把任务丢进消息队列后返回 202，前端轮询另一个接口拿结果。
• 204 No Content：请求成功，但没有响应体。比如删除资源的接口，删除成功后用 204 最合适，因为客户端根本不需要拿到任何返回内容。
• 206 Partial Content：服务端只返回了资源的一部分，配合 Range 头实现断点续传和视频拖动播放。

实际开发里最常见的错误有两个。第一个是用 200 表示"业务失败"，比如查询余额失败也回 200，只是在 JSON 里放一个 error_code。从 HTTP 协议角度这是完全不合规的，但很多老系统都这么干。第二个是前端把 204 当成异常，因为平时接口都是 200，突然某个删除接口返回 204，前端判断 res.code !== 0 就报错，其实状态码压根不是业务码。

2.3 206 Partial Content：视频拖拽和断点下载的基石

206 Partial Content 值得单独拿出来讲，因为很多人在视频点播和文件下载场景里栽过跟头。

客户端在请求视频文件时，通常会带上：

http复制Range: bytes=0-1023

服务端如果支持分段，就返回：

http复制HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/102400

这样浏览器才能实现拖拽进度条，下载工具也才能做断点续传。如果你发现一个下载接口在断点续传时总是从头开始，大概率是服务端忽略了 Range 头，直接回了 200 加完整文件。表面上功能没问题，但用户体验很差，尤其是大文件场景，网络一抖动就全量重新下载。

2.4 实操心得：200 不是"没问题"的同义词

我在排查接口问题时，见过最坑的一种故障是：页面请求返回 200，但响应内容是一个 HTML 登录页。原因是这个请求被网关拦截，网关返回了自己写的 200 状态登录提示页，而不是标准 401。前端判断 HTTP 200 后直接进入数据处理逻辑，解析 HTML 报错，页面白屏。后来我习惯在调试里多看一眼 Content-Type 和实际响应体，不能只看网络面板里的绿色 200 就认为万事大吉。

另一个心得是：204 和 200 空 body 是两回事。204 明确告诉客户端没有内容可返回，浏览器不会尝试解析 body；200 空 body 则让客户端代码里 response.json() 直接抛异常。接口设计时该用 204 就用 204，能省掉客户端一堆判断。

3. 3xx 不只是"跳转"，它背后是一套完整的自动导航逻辑

3.1 301、302、303、307、308：带不带请求体，区别大了

3xx 的状态码最容易让后端同学记混，尤其是涉及 POST 请求时。先给个结论表：

这里最容易被坑的是 POST 请求的重定向。如果你写了一个登录表单，提交到 http://example.com/login，这个地址返回 302 跳转到首页，按标准语义客户端应该重新 POST 到新地址。但很多老浏览器和代理看到 302 会直接把 POST 改成 GET，导致新地址收到一个没有 body 的 GET 请求。因此现在做 API 设计，临时重定向推荐用 307，永久重定向推荐用 308，语义明确、不会丢方法。

我还见过一个跳转死循环的案例：应用强制 HTTPS，但 Nginx 收到 HTTP 请求后返回 301 到 HTTPS 地址，应用内又有代码判断如果请求不是 HTTP 就再跳回 HTTP，两边来回跳，浏览器最后报"重定向次数过多"。这类问题用 curl 看响应头最容易暴露，因为 curl 默认不跟随重定向，你能看到每一次的 Location。

3.2 304 Not Modified：不是错误，是缓存命中的暗号

304 Not Modified 在浏览器里非常常见，但它经常引发误解，尤其被刚接触前端性能优化的人当成"缓存失败"。

实际流程是这样的：浏览器第一次请求一个 JS 文件，服务端返回 200，并且响应头里带了 ETag: "abc123" 或 Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT。浏览器再次请求时，会自动带上：

http复制If-None-Match: "abc123"
If-Modified-Since: Wed, 21 Oct 2024 07:28:00 GMT

服务端一比较，发现文件没变，就返回 304 Not Modified，没有响应体。浏览器收到 304 后，会直接用本地缓存的内容。所以 304 的意思是"你本地缓存还有效，接着用吧"，它既不是错误，也不是真的从服务端拉取了一次完整资源。

但在排查接口问题时，304 确实会带来困扰。如果你用浏览器开发者工具调试一个 GET 接口，发现刷新后请求显示 304，那代表这次请求没有拿到最新响应体。你需要在 Network 面板里勾选 Disable cache，或者强制刷新。如果是 POST 之外的接口被 304，先检查是不是网关或浏览器缓存策略配置得太激进，把不该缓存的动态数据也缓存了。

3.3 重定向循环怎么查：抓住 Location 和方法的组合

排查任何 3xx 问题，我的建议永远是先"手动跟一遍"，用 curl 来复现：

bash复制curl -I http://example.com/path

-I 只发 HEAD 请求看响应头，这样你能看到完整的 HTTP/1.1 301 Moved Permanently 和 Location: https://example.com/path。如果发现 Location 指向的地址再请求又跳回原地址，基本就是重定向循环。

另一个容易忽略的点：Location 可以是相对路径，也可以是绝对 URL。标准允许相对路径，但很多老客户端处理不好。如果你在写服务端重定向逻辑，最稳妥的做法是返回完整的绝对 URL，包括 scheme 和 host，不然到某些代理环境里可能跳错。

4. 4xx 排查主战场：一半的"状态码焦虑"都发生在这里

4.1 400 Bad Request：不只是"请求格式错"

400 Bad Request 的字面含义是服务端无法理解这个请求，但实际触发它的原因五花八门。我平时见的最高频几种：

• 请求头太大，超过 Nginx 的 large_client_header_buffers 限制。
• Cookie 太大，单个头超过服务端限制。
• 请求体不是合法 JSON，服务端解析失败。
• 上传文件的 multipart 格式缺少 boundary。
• 请求 URL 里带了非法字符，比如中文没有做 URL 编码。
• 把明文 HTTP 请求发到了 HTTPS 端口。

最后一种是很多初学者容易懵的。报错文案往往长这样：

text复制400 Bad Request
The plain HTTP request was sent to HTTPS port

这句话翻译过来是：客户端用 http:// 访问了一个只监听 https:// 的端口。比如 Nginx 只开了 443 的 SSL 监听，你访问 http://example.com，Nginx 收到的是明文 HTTP，但它预期的是 TLS 加密数据，于是干脆回 400。解决办法很直接——把地址改成 https://example.com。如果是在本地测试，也可能是你服务只监听了 HTTPS 端口，但代码里写死了 http://127.0.0.1。

排查 400 时，不要只盯着"请求格式"想，先用抓包或 curl 看看自己实际发出去的内容长什么样。我常用这个命令：

bash复制curl -v http://example.com/api -d '{"name":"test"}' -H "Content-Type: application/json"

-v 会把请求头和响应头全部打印出来，任何畸形格式都会暴露得很明显。

4.2 401 和 403 的本质差别：认不认识你 vs 让不让你进

这两个状态码经常被混用，但语义完全不同。

401 Unauthorized 代表"我没认出你是谁"。服务端会通过 WWW-Authenticate 响应头告诉客户端应该用哪种方式认证。常见场景是 Basic Auth、Bearer Token 过期或缺失。比如 Git 推送时提示：

text复制remote: HTTP Basic: Access denied
The provided password or token is incorrect

这说明你用的账号密码或 token 不对，对应的就是 401，而不是 403。

403 Forbidden 代表"我认识你，但你不许动这个资源"。可能是权限不够、IP 被限制、被 Web 应用防火墙拦截，也可能是文件系统权限导致 Nginx 无法读取文件。

排查时有个通用方法：先看响应头里有没有 WWW-Authenticate，有就是 401 类问题，先解决认证；没有再考虑权限配置。我见过一个很顽固的 403，应用日志里什么都没有，后来发现是 Nginx 层做了 IP 白名单，用户的出口 IP 一直在变化，被误拦了。这种问题从后端日志根本看不出来，必须在代理层排查。

4.3 404 不一定代表"没有"，也可能只是路由没匹配上

404 Not Found 是最常见的状态码，但它经常给人误导。接口文档说这个 URL 存在，但一请求就 404，这时候我一般按优先级检查：

1. 是不是请求打到了错误的服务上（比如测试环境域名指到了别的集群）。
2. 反向代理的 location 规则是否匹配了该路径。
3. 应用框架的路由是否真的注册了这个路径。
4. 资源是否真的被删除或迁移走了。

有一种情况特别隐蔽：Nginx 把 /api 反代到后端，但 proxy_pass 后面有没有带 URI 会导致路径拼接不同。比如：

nginx复制location /api/ {
    proxy_pass http://backend/;
}

请求 /api/users 会被转发成 /users；但如果写成：

nginx复制location /api/ {
    proxy_pass http://backend;
}

请求 /api/users 会被原样转发成 /api/users。后端如果没有注册 /api/users，就会返回 404。这类问题从浏览器看到的就是一个干干净净的 404，你怎么查后端日志都查不到，因为请求根本没到后端预期的路由上。

4.4 其他高频 4xx：405、408、409、413、415、422、429

再挑几个开发中经常遇到的 4xx 快速过一遍，每个背后的处理方法都不一样。

405 Method Not Allowed 出现在你用错误的 HTTP 方法访问接口。比如接口只支持 POST，你发了 GET，服务端会回 405，并且应该在 Allow 响应头里列出允许的方法。

408 Request Timeout 表示服务端等待客户端发送请求的时间过长。常见于客户端发了请求头但迟迟没发完请求体，或者某个代理层读超时设置太短。如果服务端日志里看到 408，先看客户端是不是真的把完整 body 发完了。

409 Conflict 表示请求与当前资源状态冲突。最常见的场景是版本冲突，比如你基于旧版本数据更新，但服务端已经被别人改过了。

413 Payload Too Large 表示请求体太大。上传文件接口很容易遇到，Nginx 默认 client_max_body_size 是 1m，超过就返回 413。修改配置后要记得 nginx -t 再 reload。

415 Unsupported Media Type 是 Content-Type 不对。比如服务端只接收 application/json，你传了 text/plain，就可能返回 415。

422 Unprocessable Entity 不是标准 HTTP 语义里的"格式解析失败"，而是请求能解析、但业务校验不通过。比如注册接口收到一个格式合法的 JSON，但邮箱字段为空，返回 422 非常合适。很多框架遵循 WebDAV 扩展把校验错误定义成 422，它是 REST API 设计里的高频状态码。

429 Too Many Requests 代表限流了。服务端通常会在 Retry-After 头里告诉客户端多久后重试。客户端收到 429 后不能无脑立即重试，否则会加剧问题；配合指数退避才是正解。

为了方便查，我列一个速查表：

4.5 418 和 451：那些"彩蛋"状态码

418 I'm a teapot 来自 1998 年的愚人节 RFC 2324，定义是"我是一个茶壶，不能泡咖啡"。虽然它是个玩笑，但很多开发者在服务里专门用 418 做测试标记，或者用来拒绝某些自动化请求。看到 418 不用慌，多半是对方故意设置的。

451 Unavailable For Legal Reasons 是真实存在但很少见的状态码，表示资源因法律原因不可用。这个一般不归开发者管，但遇到了要知道它为什么存在。

5. 5xx 错误排查，拼的不是记忆而是链路顺序

5.1 500 不是终点，是起点

500 Internal Server Error 是最笼统的服务端错误，它的信息量几乎为零——服务端只知道"出错了"，但不知道错在哪。我见过很多人看到 500 就到处重启，实际上 500 的排查起点一定是后端日志，而不是进程。

如果你用的 Nginx 做反代，后端应用抛了异常，Nginx 日志里可能只记录一行：

text复制upstream prematurely closed connection while reading response header from upstream

应用日志则可能显示 SQL 语法错误、空指针、内存溢出等具体信息。先打开应用日志，再回来看 Nginx 日志，把两边时间对上，才能还原现场。这里有个实用技巧：把自定义错误码写进响应头，比如 X-Request-Id，然后把请求 ID 贯穿到日志里，出问题时一个 ID 就能串起所有环节。

5.2 502 Bad Gateway：代理说"我没拿到有效响应"，但锅不一定在上游

502 Bad Gateway 的意思是网关或代理从上游服务器收到了无效响应。这里"无效"范围很广：上游连接被重置、上游返回了空响应、上游返回的响应头不合法、甚至上游进程在发送响应到一半时崩溃。

排查 502 的第一步永远是"确认返回 502 的那一层是谁"。如果你的浏览器直接连 Nginx，Nginx 连接后端 Tomcat，那 502 大概率来自 Nginx。第二步是看 Nginx 错误日志：

bash复制tail -f /var/log/nginx/error.log

常见错误包括：

• connect() failed (111: Connection refused) while connecting to upstream：后端端口没监听，或者监听地址不是 127.0.0.1。
• upstream sent too big header while reading response header from upstream：上游响应头太大，超过 proxy_buffer_size。
• no live upstreams while connecting to upstream：上游所有节点都被标记为不可用。

我在本地调试时经常碰到一个场景：启动了一个监听 127.0.0.1:15721 的服务，但进程没起来或者启动失败，代理层直接返回 502，报错 URL 还是 http://127.0.0.1:15721/v1/responses。这种问题不需要分析复杂的协议，先去确认端口有没有进程在监听：

bash复制lsof -i :15721

还有一种更隐蔽的：某些 API 网关会调用大模型接口，如果上游大模型返回 400，网关把异常包装成 502 返回给调用方。这时查网关日志能看到类似 upstream_status: 400 的记录，真正的根因是发给大模型的请求格式有问题，而不是大模型服务宕机。所以看 502 时不要只看外层，把 upstream_status 一起捞出来，它能告诉你上游真实返回的状态码是什么。

5.3 503 Service Unavailable：服务在，但暂时没法干活

503 通常表示服务端暂时无法处理请求。常见场景包括：

• 应用正在启动，健康检查还没通过。
• 服务过载，主动拒绝新请求。
• 维护模式被打开。
• 注册中心把某个节点下线了。

503 跟 502 的关键区别是：502 通常是连接层面的问题，503 更偏向"服务活着但我不接客"。Nginx 配置了多个 upstream 节点时，如果健康检查发现所有节点都挂了，也会返回 503。

我在 Docker 环境里还见过一个很有意思的 503：容器启动瞬间，应用还没就绪，但 Nginx 已经开始转发请求，于是前几秒的请求全部 503。等容器完全就绪后一切正常。解决办法是在 Compose 或 K8s 里配置就绪探针，或者让网关在上游启动时自动摘除节点。

5.4 504 Gateway Timeout：不是服务没响应，是响应时间超过阈值

504 Gateway Timeout 代表网关等待上游响应超时。排查时，先要分清超时发生在哪个阶段，是连接超时还是读响应超时。

Nginx 里有几个易混淆的配置：

nginx复制proxy_connect_timeout 5s;   # 与上游建立 TCP 连接的超时
proxy_send_timeout 5s;      # 向上游发送请求体的超时
proxy_read_timeout 5s;      # 等待上游响应体的超时

如果后端是一个慢接口，但逻辑正常，通常需要调大 proxy_read_timeout。但盲目调大只会掩盖问题，更推荐从根上解决：慢 SQL、外部 API 调用、大量计算、线程池阻塞，都可能导致响应慢。我自己的排查顺序是：

1. 用 curl 直接请求上游服务，带上 -w 看耗时分布。
2. 确认是连接建立慢、首字节慢还是完整下载慢。
3. 看应用日志有没有慢日志或超时配置。

一个工程化的解法是：把耗时长的任务改异步，接口先返回 202 Accepted，任务完成后通过回调或轮询通知客户端。这样网关不会因为长时间占用连接而超时。

5.5 其他 5xx：501、505、507

501 Not Implemented 表示服务端不支持请求所需的功能，通常出现在服务端还没实现某个 HTTP 方法时。

505 HTTP Version Not Supported 表示客户端用的 HTTP 协议版本服务端不支持。比如服务端只支持 HTTP/1.1，但客户端用 HTTP/2 的特定特性发了请求，老版本 Nginx 或某些中间件可能处理不了。

507 Insufficient Storage 是 WebDAV 扩展里的状态码，表示服务端存储空间不足，不常见但确实偶尔会在文件上传服务里遇到。如果返回 507，先检查磁盘是不是满了，不要一头扎进代码里找 bug。

5.6 网关日志里的 upstream_status 才是破案关键

最后强调一个特别重要的日志字段：upstream_status。Nginx 的 access log 默认不记录它，可以手动加上：

nginx复制log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" '
                'upstream_status=$upstream_status '
                'request_time=$request_time '
                'upstream_response_time=$upstream_response_time';

一旦你看到页面返回 500 但 upstream_status=200，说明是 Nginx 内部环节出错了，比如 rewrite 或内部跳转阶段抛错；如果页面返回 200 但 upstream_status=500，说明上游确实是 500，但 Nginx 把它改写了。这个字段能把"浏览器看得到的状态码"和"上游真实状态码"区分开，排查效率翻倍。

6. 状态码排查工具箱：从 curl 到日志的实战套路

6.1 用 curl 快速复现状态码和耗时

我自己调试接口时最常用的命令是组合 -o、-s、-w：

bash复制curl -s -o /dev/null -w "HTTP状态码: %{http_code}\n"
     -w "DNS耗时: %{time_namelookup}s\n"
     -w "连接耗时: %{time_connect}s\n"
     -w "首字节耗时: %{time_starttransfer}s\n"
     -w "总耗时: %{time_total}s\n"
     https://example.com/api

-o /dev/null 表示丢弃响应体，因为我们只关心状态码和耗时。-w 里的变量能告诉你耗时到底消耗在哪一步。如果 time_connect 很高，可能是网络层有问题；如果 time_starttransfer 很高，大概率是上游业务逻辑慢。

查看完整响应头用 curl -i，只看响应头用 curl -I。遇到重定向想看完整跳转链，可以用：

bash复制curl -I -L https://example.com/path

-L 会自动跟随重定向，但注意默认只跟随到 301/302 等，如果要严格保留请求方法，需要额外配置。调试时我更喜欢不加 -L，一步步手动跟，状态码变化看得更清楚。

6.2 浏览器开发者工具：状态码颜色不是重点

打开 Chrome 开发者工具的 Network 面板，不同状态码会有不同颜色，但这只是浏览器的视觉提示，不代表业务对错。我更关注的是：

• Name 列对应的请求 URL 是否真的发到了预期服务。
• Status 列显示的代码是不是被 Service Worker 拦截后伪造的。
• Size 列显示 from disk cache 还是 from memory cache，能区分是缓存命中还是真的从网络请求。
• Time 列的时间分布，能初步判断耗时在请求发送还是等待响应。

如果你发现某个接口刷新后经常 304，但业务上需要最新数据，可以临时勾选 Disable cache。不过这只能解决本地调试，线上环境还是要从缓存策略入手。

6.3 接口出问题时，先分清"状态码层"还是"业务码层"

现在很多公司内部 API 都有一套自己的业务码。比如 HTTP 状态码永远返回 200，但 JSON 结构是：

json复制{
  "code": 10001,
  "message": "用户不存在",
  "data": null
}

这不是绝对错误，但会带来调试成本。我的经验是：HTTP 状态码负责描述"请求本身处理得怎么样"，业务码负责描述"业务逻辑是否成功"，两者最好分开。RESTful 设计里，创建失败、参数校验不通过这类问题完全可以用 4xx 表达，没必要全部包装成 200。真出了问题，至少能从状态码第一眼判断大方向，而不是每个接口都要解析 body 才能知道失败没有。

6.4 建立你自己的"状态码速查习惯"

无论你多熟悉状态码，总有些冷门代码会忘。我自己的做法是在项目里维护一份速查表，记录这个项目里真正出现过的高频状态码，以及对应的排查入口。表格不追求齐全，追求"一看就知道下一步干嘛"。

这个方法比收藏一堆网上的"状态码大全"有用得多。因为你自己项目里的状态码一定是最常见的，记下来以后，每次看到同一个状态码直接翻自己的表，半小时的排查能压缩到五分钟。

6.5 面对 5xx 的最后一个习惯：永远先看 Log，再动进程

最后再分享一个我踩过多次坑之后养成的原则：不管遇到 500、502 还是 504，先别急着重启、也别急着改代码，先看日志。日志在哪一层写，就去哪一层看。

• 如果 502 是 Nginx 返回的，先看 Nginx error log。
• 如果 500 来自应用，先看应用日志和异常堆栈。
• 如果 504 是网关超时，先看上游应用有没有慢请求日志。

日志优先的好处是能保留现场。一旦你重启了进程，很多证据就消失了，比如线程池堆积、文件句柄泄漏、内存状态。等你知道真相时，可能已经错过了最好的定位时机。状态码只是问题的一扇门，门后是日志、配置、网络、代码这四间房，别在门口站太久。