我们平时排查接口问题，十有八九都要跟HTTP状态码打交道。之前有位同事排查一个问题，整整一下午都在数据库里翻SQL，结果最后发现是Nginx反代那边配置超时，把上游请求切断了，前端看到的图标一直是“服务异常”。这事给我的触动挺大：如果你对一次HTTP请求的完整生命周期没有一个清晰的整体概念，遇到问题时很容易在错误的方向上折腾半天。反过来，当你心里有一张“从URL输入到页面渲染”的完整地图，再去看状态码，基本一眼就能定位到是网络层、服务端、代理层还是客户端的问题。
这篇文章就把“一次HTTP请求从发起到结束到底经历了什么”按真实发生的顺序完整串一遍，然后把最常见的HTTP状态码按“使用场景”而不是“数字顺序”拆开讲透。对于刚入门的同学，这是一篇能把零散知识串成体系的文章；对于已经写了不少接口的开发来说，也可以当一份排查问题时的查漏补缺清单。
1. 从按下回车到页面渲染：一次HTTP请求的完整生命周期
很多人以为一次请求就是“浏览器发个东西给服务器，服务器还回来，完事”。实际上这里面至少经历了五个阶段，每一阶段都可能出错，而且每个阶段的错误体现到状态码上是不一样的。
1.1 第一步不是建连接，而是“问路”：DNS解析
你在浏览器地址栏输入域名并回车，浏览器首先要回答一个问题：这个域名对应的服务器IP地址是多少？这个过程就是DNS解析。
DNS解析的查找顺序不是直接去公共DNS服务器问一次那么简单，而是逐级查缓存：
- 浏览器自身DNS缓存
- 操作系统层面的DNS缓存（hosts文件也会在这里生效）
- 本地网络设备（比如路由器）的DNS缓存
- 运营商或企业指定的递归DNS服务器
- 根DNS服务器、顶级域服务器、权威DNS服务器的逐级迭代
这里最容易踩的坑是：很多性能问题其实不是后端慢，而是DNS解析慢。我见过一个内部系统，每次打开都要卡两三秒，抓包一看，耗时全在DNS查询上，原因是内部服务用了公网域名解析，绕了一大圈才解析到内网IP。解决方式很简单，内网资源用内网域名或直接配 hosts，解析耗时就没了。
TTL（Time To Live）是DNS记录里一个特别重要的参数，它决定了一条域名解析结果能在缓存里存活多久。做过CDN切换或者服务器迁移的同学应该深有体会：改了DNS记录不生效，多半就是TTL没调小。所以调整解析前，最好提前一天把TTL从3600降到60，等切换完成后再调回去。
如果是拿IP直连的接口，这一步就省了。但一般生产环境都建议用域名而不是写死IP，因为IP背后可能是负载均衡集群，今天这个IP能用，明天可能就被摘掉了。
1.2 建立连接：TCP三次握手和TLS握手
拿到服务器IP之后，客户端开始建立TCP连接。三次握手的顺序是：
- 客户端发送SYN报文，表示“我想建立连接”
- 服务端回复SYN+ACK，表示“收到，我也愿意”
- 客户端发送ACK，表示“确认收到”，连接建立
看到这里可能有人会问：现在访问的网站基本都是HTTPS，那中间还多了一步TLS握手。具体流程是TCP三次握手完成后，客户端和服务端还要通过证书校验、密钥协商等步骤建立加密通道。这也是为什么HTTPS接口比HTTP接口“感觉慢一点”的原因，但这部分耗时是值得的，换来的是传输内容不被明文窃取。
这里我特别想提醒一个容易被忽略的点：TCP连接是有成本的，所以浏览器和操作系统不会每次请求都重新握手。HTTP/1.1的Keep-Alive机制允许同一个TCP连接上连续发送多个请求，而浏览器侧也会维护一个连接池。如果代码里每次请求都新建一个HTTP客户端、用完就关，性能会非常难看。连接复用是后端接口优化里见效最快、最容易被忽略的一项。
1.3 发出请求报文本体：Method、Headers、Body
连接建立后，客户端开始发送HTTP请求报文。一个完整请求报文由三部分组成：
- 请求行：方法 + 路径 + 协议版本，比如
GET /api/user/1 HTTP/1.1 - 请求头：一堆键值对，比如Host、User-Agent、Accept、Content-Type、Authorization
- 请求体：通常GET请求没有，POST/PUT/PATCH等会携带
请求方法里最常用的是GET和POST。这里聊一个很多年后端工程师都还在纠结的问题：GET和POST到底有什么区别？从协议设计角度，GET应当是“只读”的，不改变服务端状态；POST则允许携带请求体，可以做创建操作。但真正落实到工程里，给GET带上Body在规范上是不被推荐的，很多网关、代理层会直接丢弃GET的Body。所以不要把复杂查询参数全塞到GET的Body里，老老实实用query参数，或者改用POST。
头部字段里，有几个对后端排查问题特别关键：
Content-Type：告诉服务端Body是什么格式，JSON还是表单。服务端解析失败很多时候就是这里没对齐。Authorization：携带认证凭证，常见的是Bearer <token>。跨域请求时，这个头也会触发预检请求。Accept：希望服务端返回什么格式，比如application/json。X-Request-ID（或类似的自定义追踪ID）：虽然不是标准字段，但在生产环境里强烈建议让客户端生成一个唯一ID透传到后端，这样日志排查时能把一次请求的全链路串联起来。我所在的项目里有一个不成文的规定：所有接口的响应头里必须回传这个ID，前端报问题时直接甩一个ID过来，后端按ID筛日志，效率高很多。
1.4 服务器处理请求并构建响应
请求报文到了服务器之后，会经过一条典型的链路：负载均衡（比如Nginx） → Web应用容器（比如Tomcat或者框架内置的服务器） → 应用代码 → 缓存/数据库/第三方服务。
这个阶段是后端开发日常打交道最多的部分。请求能不能进入应用逻辑、返回什么状态码，受几层因素影响：
- 如果负载均衡层发现上游应用没有存活，直接返回502或503。
- 如果应用入口处的鉴权中间件校验失败，返回401或403。
- 如果路由匹配不上，返回404。
- 如果应用内部抛了未捕获异常，通常返回500。
服务端处理完业务逻辑后，会构建响应报文。响应报文结构同样三部分：
- 状态行：协议版本 + 状态码 + 原因短语，比如
HTTP/1.1 200 OK - 响应头：
Content-Type、Content-Length、Cache-Control、Set-Cookie等 - 响应体：实际返回给客户端的数据
响应体的格式一般由Content-Type声明。如果是网页请求，通常是HTML；如果是前后端分离，通常是JSON。要注意的是，无论响应体是什么格式，HTTP层都只是把它当成字节流传输，格式化解析是客户端的事情。
1.5 浏览器接收响应并渲染
客户端收到响应后，浏览器会根据Content-Type决定如何处理。HTML会进入解析渲染流程，CSS和JavaScript的资源会继续触发新的HTTP请求。JSON则会交给前端代码做逻辑处理。
这个过程里有一个特别常见的误解：页面打开慢，控制台里却只看到一两个红色报错，于是认为是后端接口慢。实际上页面加载是一个瀑布流，可能包含几十上百个请求，其中某几个JS或图片资源请求慢，或者因为并发限制在排队，都会拖慢整体时间。用浏览器开发者工具里的Network面板看瀑布图，能很直观地看到到底是哪个环节慢，以及请求是不是在“排队等待”阶段就卡住了。
从这一整条链路回头看：你看到的每一个状态码，其实都对应着这条链路上某个环节的反馈。理解了生命周期，看状态码就不会再是死记硬背了。
2. 拆开报文看本质：请求行、响应行与常见头部字段
很多接口联调出问题，表面上是状态码不对，实际上是对报文本身的结构理解不透。这一章把报文里最核心的几个构成部分拆开讲，配合开发者工具里的信息对照看，很快就能建立感觉。
2.1 请求报文的关键部分：请求行与请求头
请求行的格式非常固定，就一段文本，用空格隔开三部分。例如：
POST /api/v2/orders HTTP/1.1- 方法：POST
- 路径：/api/v2/orders
- 协议版本：HTTP/1.1
注意这里的路径是不包含域名部分的。很多新手抓包时看到一个绝对URL（比如https://example.com/api/v2/orders）会疑惑，这是因为浏览器在代理或抓包工具里展示时会把完整地址拼出来，但实际发出去的请求行里只有路径和查询字符串。
请求头里，我按“排障优先级”列几个实际开发中经常出问题的字段：
| 字段 | 常见问题 | 排查建议 |
|---|---|---|
| Content-Type | 上传JSON却写成了form-urlencoded，后端解析不到参数 | 确认前后端使用的是同一种序列化格式 |
| Authorization | token过期或缺失，导致401 | 先看请求头里是否真的带上了凭证 |
| Origin / Referer | 跨域请求被浏览器CORS策略拦截 | 确认响应头是否允许该来源 |
| Cookie | 登录态失效，接口返回未登录 | 检查请求是否带上了预期的Cookie域 |
我遇到过最经典的案例是：前端说“我明明传了参数，后端说没收到”。后来抓包一看，参数在POST请求体里确实是JSON格式，但Content-Type被框架默认设成了text/plain，后端路由没匹配到JSON解析器，直接把它当成普通文本处理了。这种问题在前后端分离项目里特别容易发生，联调前对齐Content-Type是第一步。
2.2 响应报文的关键部分：状态行与响应头
响应报文里最显眼的就是状态行，例如：
HTTP/1.1 200 OK状态码后面的“OK”叫原因短语，不同服务器实现可能略有差异，比如200后面可以是OK，204可能是No Content。原因短语在HTTP/2里已经被移除了，但状态码本身保留。所以在写代码时千万不要依赖原因短语做逻辑判断，只应该依赖状态码数字。
响应头里有几个字段对排障很重要：
Content-Length：响应体字节数。如果服务端返回的Content-Length和实际body长度不一致，客户端会一直等待或者解析出错。Transfer-Encoding: chunked：响应体分块传输，无法提前知道总长度。SSE流式推送经常用这个。Cache-Control：决定浏览器能不能缓存这个响应，缓存多久。很多接口频繁被请求，其实可以通过合理设置Cache-Control减轻后端压力。Set-Cookie：服务端要求客户端种Cookie，多用于会话管理。Location：配合3xx重定向状态码使用，告诉客户端“你要的资源现在在这个新地址”。
一般我在排查问题时会先看响应头里的Content-Type，再看Cache-Control，这两个字段能解释掉一半“为什么我改了代码没生效”和“为什么接口返回了乱码”的诡异问题。
2.3 用开发者工具实际验证一遍报文的完整链路
纸上得来终觉浅。这里建议你随手打开一个网站，在浏览器开发者工具的Network面板里操作几步验证上面的内容：
- 随便点开一个请求，看Headers标签页，找到Request Headers和Response Headers，对照上面提到的字段逐一确认。
- 看Timing标签页，里面会详细分解出
DNS Lookup、TCP Connection、TLS Handshake、Request Sent、Waiting (TTFB)、Content Download这几个阶段。这里的Waiting (TTFB)表示从请求发出到收到第一个字节的时间，是一个非常重要的性能指标。TTFB高说明瓶颈在服务端处理，而不是网络传输。 - 找到
Response Headers里的Content-Encoding，如果值是gzip或br，说明传输前做了压缩。
这组操作只需要几分钟，但能帮你在真正遇到线上问题时，不再懵懵懂懂地到处猜。排查接口问题就像医生看病，望闻问切先做一轮，抓包工具和开发者工具就是你的听诊器。
3. 状态码不用背，按“成功/跳转/客户端错/服务端错”四个场景去用
大部分常见状态码完全不需要死记硬背，它们背后的逻辑就一条：这个请求到底是谁的问题。基于这个原则，状态码可以分为四大类：
| 类别 | 范围 | 含义 | 代表状态码 |
|---|---|---|---|
| 信息响应 | 1xx | 临时响应，协议层面中间消息 | 100、101、103 |
| 成功 | 2xx | 请求已经被服务器正确理解和处理 | 200、201、204、206 |
| 重定向 | 3xx | 需要额外操作才能完成请求 | 301、302、304、307、308 |
| 客户端错误 | 4xx | 请求有问题，是客户端（调用方）的错 | 400、401、403、404、405、408、409、413、429 |
| 服务端错误 | 5xx | 请求本身没问题，是服务器出错了 | 500、501、502、503、504 |
下面按这个分类把高频状态码逐一讲透，同时附带实际排查经验。
3.1 2xx：不只是200，还有202、204、206这些容易忽略的“成功”
200是最常见的成功状态码，表示请求成功，响应体里携带了完整结果。绝大多数接口文档只定义200为成功返回，这个习惯可以理解，但在一些特殊场景里，用不同的2xx状态码语义更准确。
201 Created表示资源创建成功。用HTTP语义来说，POST请求创建一个新资源时，应该返回201，并在Location头里给出新资源的访问地址。很多系统图省事一律返回200，这不算错误，但会让接口语义变得模糊。
202 Accepted表示“我已接受到这个请求，但还没处理完成”。这个状态码在异步任务场景中非常合适。比如用户上传了一个文件，后端需要转码，耗时较长，接口先返回202，再附带一个任务ID，前端轮询任务状态。如果这时候强行同步返回200，接口耗时会十分感人，前端体验也差。
204 No Content表示请求成功但没有响应体。比如DELETE删除资源，删除成功时返回204就非常干净。有些团队习惯DELETE也返回200给一个JSON，这也没问题，但204在语义上更准确，还能省一点流量。
206 Partial Content表示部分内容，常用于断点续传和视频流播放。客户端通过请求头里的Range指定想要哪一段字节，服务器返回206并带上Content-Range。音频视频拖动进度条时，你看到的请求基本都是206。
实际项目里最需要注意的一个反模式是：把所有业务错误都包装在200里。比如：
{ "code": 50001, "message": "余额不足", "data": null }业务层自定义code这种做法本身不算错，但如果你连参数校验失败、资源不存在、服务器内部逻辑异常全都返回HTTP 200，那么网关监控、日志告警、客户端拦截器统统都看不到真实的错误分布。排查问题时，你得一个个翻业务日志，效率极低。我的建议是：HTTP状态码表达“请求有没有成功被处理”，业务code表达“业务上到底发生了什么”。两者是不同维度，不要把它们混成一个。遇到鉴权失败，该401就401；遇到参数非法，该400就400；遇到内部异常，该500就500。
3.2 3xx：重定向的学问，301和302的区别被很多人搞混
3xx状态码表示：你要的东西不在原地址了，客户端需要“再走一步”才能完成这个请求。它们几乎都要配合Location响应头一起使用。
301 Moved Permanently是永久重定向。搜索引擎看到301会把旧地址的权重全部转移给新地址。域名换成新域名、HTTP永久跳转HTTPS，这种场景用301。
302 Found是临时重定向。临时跳转常见的场景有：未登录用户访问页面时跳到登录页、A/B实验分流到不同版本页面、支付成功后回跳。但要注意，搜索引擎对302的处理是“只是临时过去”，不会把权重转移。
细心的同学会发现，现在很多网站跳转用的是303、307和308。这几个状态码的出现，是因为302在历史上有一个行为不统一的问题：浏览器把POST请求重定向时，有的会改造成GET请求，有的保留POST。于是规范里做了更清晰的区分：
- 303 See Other：重定向后一律用GET请求访问新地址，哪怕原来方法是POST。
- 307 Temporary Redirect：重定向保留原来的方法和请求体。
- 308 Permanent Redirect：307的永久版，要求保留方法和请求体。
还有一个不能忽略的是304 Not Modified。它不算错误，而是一种基于缓存的优化机制。流程是这样的：
客户端第一次请求资源时，响应头里会带上ETag（资源标识）或Last-Modified（最后修改时间），浏览器把这些存下来。下一次请求时，客户端通过If-None-Match或If-Modified-Since把这些信息带回服务器。服务器一看，资源没有变化，就不用返回整个资源了，直接回一个304，响应体为空。浏览器收到304后，直接用本地缓存的资源。
实际体验上，304几乎是不消耗下载流量的。我们上线静态资源配置时，通常会给静态资源设置ETag和Cache-Control，这样用户二次访问时大量请求会走304，体感上加载速度会明显提升。不过，如果你在调试接口时发现“我的接口返回304，前端口口声声说没拿到最新数据”，那不是接口有问题，而是缓存策略导致的预期内行为。排查思路是去看请求头里是不是带了If-None-Match，以及确认服务端有没有真的把ETag算对。
3.3 4xx：客户端错误的排查顺序
4xx是排障时最容易出问题的大类。收到4xx，说明服务器“听懂”了请求，但认为这个请求不合法、不被允许或者找不到目标。注意，服务器不会明确告诉你“你是哪里的问题”，它只告诉你“你这次请求有问题”，具体哪里还得自己查。
400 Bad Request：请求报文本身格式错误。最常见的场景是JSON解析失败，比如多了一个逗号、字符串引号没闭合、Content-Type写错。排查时优先看请求体是不是有效的JSON格式。
401 Unauthorized：未认证。意思是“我不知道你是谁”。token没传、token过期、token格式不对，都会触发401。前端遇到401的标准动作是跳登录页或者静默刷新凭证。
403 Forbidden：已认证但没有权限。服务器知道你是谁，但你的权限不够。比如普通用户调管理员接口、白名单之外的IP访问内部系统，返回403。401和403的区别建议用门禁来理解：401是你没带工牌，403是你带了工牌但公司不让你进这间机房。
404 Not Found：资源不存在。路由写错、接口未发布、请求路径大小写不匹配，都会导致404。还有一种隐蔽情况：服务端配置了路由前缀，比如所有接口都在/api前缀下，客户端漏写前缀，也会404。
405 Method Not Allowed：路径存在，但这个HTTP方法不允许。例如接口只支持POST，你用GET去调，就算路径对了也会405。排查方法是看响应头里的Allow字段，它会明确告诉你这个路径支持哪些方法。
408 Request Timeout：请求超时。这个状态码实际使用频率比想象中低，因为多数服务器处理超时直接断开连接而不返回408。真正排查客户端上传超时问题，重点要看客户端设置的超时时间和服务端的读取超时时间。
409 Conflict：资源冲突。最典型的是两个并发请求同时尝试修改同一个资源，或者创建了重复的唯一键数据。接口如果设计成幂等了，这个状态码基本可以避免。
413 Payload Too Large：请求体太大。上传文件超过服务器限制时会出现。排查时关注服务器上传大小限制的配置，以及客户端是否开启了分片上传。
429 Too Many Requests：请求太频繁，被限流了。这个状态码在网关限流场景非常常见。正确做法是：服务端在响应头里写入Retry-After，告诉客户端“你要等多少秒再重试”；客户端要做的是尊重这个头，而不是立即疯狂重试，否则会陷入“越限流越重试，越重试越限流”的恶性循环。
4xx排障我推荐一个顺序：先用开发者工具或抓包工具看真实请求的URL、Method和Headers，确认没有拼写错误；再看请求体格式，确认Content-Type和序列化方式一致；再看认证信息，确认token有效且未过期；最后联系服务端查Request日志，看请求有没有到达应用层。按这个顺序走，大多数4xx问题都能在五分钟内定位。
3.4 5xx：服务端错误的真实含义
5xx意味着请求到达了服务器，但服务器在处理过程中出了问题。这属于服务端的责任，但对调用方来说，最怕的就是5xx，因为这意味着你的请求不知道是被处理了还是没被处理，后续重试还要小心能不能重复执行。
500 Internal Server Error：服务端内部异常，未捕获的错误。代码空指针、数据库连接池耗尽、配置错误，都会表现为500。只要应用层好好打印异常日志，这个问题通常一查一个准。
501 Not Implemented：服务器不支持这个请求方法。这种情况出现在服务器网关或者代理层没有对后端应用能力做适配的时候，类比一下就是“你点的菜，这个餐厅压根不做这道菜”。
502 Bad Gateway：网关或代理层收到了上游服务器的无效响应。最常见的场景是：应用服务崩溃，Nginx没有办法把请求转给任何存活的应用实例。还有一种是应用服务连上去了但立即主动断开连接，Nginx读不到完整响应，也会502。排查时，先去看应用服务进程是否存活、有没有OOM、有没有启动失败。
503 Service Unavailable：服务不可用。这个状态码通常表示服务器“暂时过载或正在维护”，客户端收到503时，合理的做法是稍后重试。网关层做熔断时，也常常会主动返回503，表示“这个后端服务我这边已经判定为不可用了，先别打了”。
504 Gateway Timeout：网关在指定时间内没有收到上游的响应。这是后端排查里非常高频的状态码。需要特别注意的是，504并不一定代表服务端真的执行了5秒才响应，也可能应用服务根本没有成功建立连接，等待连接超时了。排查504时，需要看清楚超时发生在“等待连接”还是“等待响应”，这两个阶段的含义完全不同。
实际生产环境里，502和504是最常见的“嘿，后端又挂了”信号。处理线上告警时，我的习惯是先看状态码分布趋势，是突然直线上升还是缓慢爬坡；再根据网关日志定位是哪个上游节点、哪个API路径；然后看应用日志里这个路径有没有对应的异常堆栈。正常情况下，五分钟内就能从状态码推导出大致根因。
4. Keep-Alive、HTTP/2与HTTP/3：连接模型如何改写请求流程
上面讲的请求流程，默认建立在HTTP/1.1之上。到今天，HTTP/2已经在绝大多数网站普及，HTTP/3也正在快速铺开。这三种协议版本的“请求流程”差异很大，如果你只是用HTTP/1.1时代的经验去理解问题，会遇到一些让人困惑的现象。
4.1 HTTP/1.1的队头阻塞与Keep-Alive
HTTP/1.1最初的设计是“一发一收”：同一个TCP连接上，前一个请求的响应没返回完，后一个请求就不能发出。这被称为队头阻塞。
为了缓解这个问题，浏览器对同一个域名会建立多个TCP连接，通常是6个左右并发。这也是为什么HTTP/1.1时代，把静态资源拆到多个域名可以提升加载速度，本质是绕开连接数限制。
Keep-Alive机制允许TCP连接在一次请求结束后不立即关闭，可以继续发送下一个请求。但这个“下一个请求”必须等前一个响应完整返回才能开始。所以，在HTTP/1.1下，如果你发起了一堆互相无关的小请求，它们大概率不会同时进行，而是排着队一条条地干。
这也是我在实际项目中常跟前端同学说的：HTTP/1.1时代，“把接口拆细”并不总是好主意。如果页面首屏依赖二三十个细粒度接口，反而会受并发连接数限制，加载时间被拉长。HTTP/1.1时代合理的做法是把关键数据合并成大接口，减少请求数量；或者用域名分片来提高并发。
4.2 HTTP/2如何用多路复用解决问题
HTTP/2最大的变化是引入了二进制分帧层，在一个TCP连接上可以同时交错传输多个请求和响应，不再需要排队等。这就是多路复用。
此外，HTTP/2还有几个重要特性：
- 头部压缩：请求和响应里的重复字段会被压缩，减少传输体积。
- 服务端推送：服务器可以主动把客户端“接下来可能要的资源”推过去（实际使用较少，而且存在缓存误判风险，很多站点反而关闭了这个特性）。
- 请求优先级：高优先级的请求可以插队。
从使用角度讲，启用HTTP/2之后，原来“拆域名、合并接口”这类优化手段变得没那么关键了。同一个TCP连接上可以并行跑多个请求，首屏加载性能往往比HTTP/1.1有明显提升。
但这里要说一个HTTP/2的局限：它仍然依赖TCP。TCP丢包时，接收方必须严格等待丢失的报文重组，即使后面的数据已经到了也只能排队。所以，在弱网高丢包环境下，HTTP/2的多路复用优势会被TCP的队头阻塞削弱。
4.3 HTTP/3与QUIC：把传输层换成UDP
HTTP/3把传输层从TCP换成了基于UDP的QUIC协议。QUIC解决的问题主要有三个：
- 连接建立更快：QUIC将TCP握手和TLS握手合并到一轮握手里，减少了往返时间。
- 彻底解决队头阻塞：因为QUIC在一条连接上支持多个独立的流，一个流丢包不影响其他流的传输。
- 连接迁移：手机从WiFi切到移动网络时，TCP连接通常会断开，需要重新握手；QUIC的连接ID机制可以让连接在IP变化后继续保持。
从实际排障视角看，HTTP/3的普及会带来一个变化：以前我们拿TCP的SYN来排查“请求到底有没有到达服务器”，在QUIC下就不一样了，QUIC没有传统意义上的三次握手SYN报文。排查时要看UDP 443端口的流量，而不能只看TCP连接状态。
但不管协议版本怎么演进，上面讲的“DNS解析 → 建立连接 → 发送请求报文 → 服务端处理 → 返回响应”这个宏观流程始终成立。状态码的语义基本也是跨版本一致的。真正变化的是地下层的传输效率，而不是上层的状态语义。
5. 实战演示：一次“接口偶发502”的完整排障链路
理论知识讲了不少，最后用一个虚拟案例把整条排障链路串起来。某天线上监控突然报警：模拟项目X的部分用户请求返回502 Bad Gateway，持续时间不固定，有时几分钟自动恢复。
5.1 现象与初步判断
502在三层架构里通常出现在负载均衡和应用服务之间。所以第一反应不是改业务代码，而是确认“请求到底有没有到应用服务”。
我先打开网关的访问日志，筛选502的请求，看到返回502的请求都有一个共同特征：集中在某几个应用实例上，分布到其他实例的请求都正常。这个特征非常关键。如果502均匀分布到所有实例，说明问题可能是全局性的，比如数据库故障或公共依赖异常；如果集中在某几个实例，那就是局部实例异常。
顺着这个思路，我看了一下那几台实例的监控指标，CPU和内存看起来都正常，但连接数有一点异常：实例的当前活跃TCP连接数一直在一个高位徘徊，且不断有新连接接入。
5.2 逐步排查：从连接数到线程池
为了搞清楚连接数为什么高，我抓了一小段时期的netstat输出，发现大量处于ESTABLISHED状态的连接长时间不释放，也没有出现预期的TIME_WAIT递进。这说明应用层的HTTP客户端可能没有正确释放连接，或者是服务的线程池处理速度跟不上，导致请求在应用层堆积。
接着看应用日志，发现对应时段有一批异常日志，内容大致是“获取数据库连接超时”。这就串起来了：数据库连接池被打满 → 处理请求的线程都在等数据库连接 → 应用线程全部阻塞 → 新请求无法被及时处理 → 网关等不到响应或发现进程无法接受新请求，于是返回502。
为什么数据库连接池会打满？继续往下查，发现项目里有一个消息消费者在某个时段批量处理任务，每个任务处理时都从连接池获取连接但不主动释放，要等整个任务处理完才归还。当批量任务一上来，连接池瞬间被全部占用，正常业务请求就得不到连接了。
这里还要提醒一点：如果代码里用的是ORM框架的默认配置，连接池大小往往不大，而且连接获取超时时间如果设置得过于保守，比如30秒，就会出现“请求卡住很久才返回502”的现象。体验上非常像是服务挂了，但其实是连接池饥饿。
5.3 修复与验证
定位到根因后修复方向就很清晰了：
- 修改数据库连接池配置，扩大最大连接数，并设置合理的获取连接超时时间，比如3秒内快速失败。
- 在批量任务代码里，把数据库连接的使用范围缩小到最小必要区间，用完立即释放。
- 在网关层将502的告警阈值加严，一旦某个实例连续返回502超过一定数量，自动摘除该实例。
上线后观察一周，502告警完全消失。这次排障看起来简单，但整个过程走的都是“状态码 → 链路定位 → 日志分析 → 根因修复”的短路径。如果你对一次HTTP请求的完整链路没有整体感知，看到502可能第一反应就是“网关和业务谁对谁错”，而不是像上面这样层层缩小范围。
6. 日常排障的小习惯：给每个请求留一个追踪ID
最后分享一个我个人的习惯，也是被很多项目验证有效的做法：从入口到出口，给每个HTTP请求带一个唯一的追踪ID（也叫Trace ID或者Request ID）。
做法很简单：客户端发起请求时，生成一个UUID放进自定义请求头里；服务端中间件读取这个值，不存在就自己生成一个；日志框架把这个ID打印到每一行日志中；响应头里再把这个ID回传给客户端。这样前端反馈问题，后端输入ID一查，一次请求在网关、应用、数据库、第三方服务中的完整足迹都能串起来。
有人会说，公司里已经有全链路追踪系统了，不用自己做。但对中小型项目或者正在成长中的团队来说，一个简单的追踪ID成本极低，收益却立竿见影。它可以让你在排查线上问题时，从“猜谜模式”切换到“定位模式”，省下的时间远超实现它的那点成本。
HTTP状态码和请求流程这些内容，看起来基础，但真正在排障时能把这些知识用得熟练，靠的不是背诵，而是反复的实际操作。下一次再遇到未知的接口错误，别急着改代码，先打开开发者工具，把请求从头到尾看一遍。流程清楚了，问题往往就藏不住了。
