我先把结论放在最前面HTTP 状态码这套三位数字是你在排查接口报错时最不该跳过的第一现场。你可能会觉得 404 是“页面没了”502 是“服务器挂了”这些说法不算错但太粗糙了。状态码真正的作用是让客户端、网关、CDN、源站这些不同角色在同一个协议会话里用一套机器可读的语义快速对齐“刚才那笔请求到底经历了什么”。公众号、技术社区里讲状态码的文章不少但大多数是搬了 RFC 文档的表格顶多解释一下 200 和 404。实际排查里你遇到的往往是 499、502、504、431、500.19 这些“看似懂又不完全懂”的数字背表格解决不了问题你得知道它是谁在什么环节、因为什么原因返回的。这篇文章我从一线排查的角度把 1xx 到 5xx 拆开讲一遍会穿插一些我在真实环境里踩过的坑适合后端开发、运维、测试以及每天要跟接口打交道的前端同学。1. 状态码不是报错编号它是一套链路各角色都要遵守的机器协议1.1 为什么需要三位数字而不是一段文字HTTP 是文本协议服务器返回响应的第一行看起来像这样HTTP/1.1 200 OK其中 200 是状态码OK 是原因短语Reason Phrase。理论上原因短语可以随便写比如你把OK改成All Good老一点的客户端也认因为真正决定客户端行为的只有三位数字原因短语只是给人看的注释。RFC 7230 里也明确说了原因短语是参考性的客户端不该依赖它做判断。所以你可以把状态码理解成“机器之间约定的暗号”它比任何文字描述都更可靠也比任何文字描述更“无情”——一旦某个中间层把状态码改写了后续所有看到它的人都会信以为真。我早年吃过一次亏客户端请求一个接口Nginx 返回 502前端跑来问我是不是后端服务崩了。我查了一圈后端日志发现服务进程根本没收到本次请求Nginx 报 502 的原因是 upstream 连接池里的一个 keep-alive 连接被源端关闭了Nginx 用了这个失效连接去转发请求握手阶段就失败了。这其实是 Nginx 对 upstream 返回结果的一种“转述”不是后端应用的真实响应。所以排查状态码第一步永远是问这个数字是谁写的是客户端收到的原始响应还是中间层转述的结果中间层会改写状态码这件事后面还会反复提到。1.2 状态码的五类分法但分类不等于追责五位状态码按首位数字分成五类范围语义典型场景1xx临时应答请求还在处理100 Continue、101 Switching Protocols2xx请求已成功处理200 OK、201 Created、204 No Content3xx需要客户端进一步操作301/302 重定向、304 Not Modified4xx客户端请求有问题400 Bad Request、401 Unauthorized、404 Not Found5xx服务端处理失败500 Internal Server Error、502 Bad Gateway这套分类框架本身没什么争议但实际排查时别被“分类即结论”给骗了。比如 4xx 全是客户端问题吗不一定。我见过不少团队把参数校验失败统一返回 500反而把真正服务端异常藏在了 200 的业务码里反过来IIS 的 500.19 是服务器配置文件出错本质是运维侧的问题但因为状态码是 5 开头照样会被误以为是后端程序崩溃。状态码的五类分法是“语义定位”不是“责任认定”。1.3 业务码、响应头和 body 一起看才能还原完整会话状态码本身只是“结论”支撑结论的是整个响应。我给你一个最典型的例子同样一个 401带了WWW-Authenticate: Basic realm...头和没带这个头一个是告诉客户端“你要用 Basic 方式补凭证”一个是“你这凭证就是不对”排查方向完全不同。所以我在团队里一直强调“读状态码三件套”状态码、响应头、body 里的错误信息缺一个都容易误判。这一节先把思维框架立起来下面从 1xx 开始逐个拆重点讲那些线上真正会遇到、而且容易被误解的状态码。2. 1xx 和 2xx平时看不见的“成功”藏着链路健康的大半真相很多人的 HTTP 状态码知识是从 200 开始的1xx 基本被无视。这很可惜1xx 最接近 TCP 层和 HTTP 层之间的握手地带很多性能优化和长连接问题就藏在这里。2.1 100 Continue大请求体上传前的“省流量开关”客户端准备上传一个很大的 body但它不确定服务器愿不愿意接收总不能先把几 MB 数据发过去、收到 413 再重来吧HTTP 为此设计了Expect: 100-continue机制客户端发送请求头并带上Expect: 100-continue。服务器先检查请求头如果愿意接收 body就返回HTTP/1.1 100 Continue。客户端收到 100 之后才开始发送请求体。服务器处理完再返回最终状态码如 200 或 201。这个机制最直接的价值是避免大流量浪费。很多 SDK 默认不会发Expect头所以你平时感觉不到它的存在。用 curl 可以手动触发观察curl -v -H Expect: 100-continue -d bigdata.bin http://example.com/api/upload-v参数下你能清晰看到先收到100 Continue再发送数据最后收到最终响应。如果你发现某次上传失败时服务器直接返回了 417 Expectation Failed那通常是服务器不支持或不接受这个Expect头的取值。我这个旧坑印象非常深有个网关层的老版本模块遇到带Expect头的请求直接返回 417客户端那边表现为“上传大文件必失败小文件正常”排查了很久才发现是网关把短连接请求转成长连接时没处理好Expect语义。2.2 101 Switching ProtocolsWebSocket 的那次握手升级101 几乎只出现在 WebSocket 场景中。客户端发一个带Upgrade: websocket和Connection: Upgrade的 HTTP 请求服务器同意后返回 101之后连接就从 HTTP 协议切换成 WebSocket 协议。注意101 是“协议升级成功”的确认它的存在本身就说明服务器支持这个机制。如果你在网关或负载均衡层看到大量 101 响应区分一下是不是有客户端在试图对非 WebSocket 端口发起 Upgrade 请求有时这会成为端口扫描的特征流量和业务异常是两码事。2.3 102 与 103告诉客户端“别急我还活着”102 Processing源自 WebDAV 场景表示服务器还在处理但暂时没有最终结果。现在用得极少。103 Early HintsHTTP 链路里比较新的成员。服务器可以在最终响应前先返回 103告诉客户端“你接下来大概率会用到这些资源”让浏览器提前建立连接或预加载关键资源比如提前推送 CSS/JS 的 preload 链接。这个状态码在慢速网络下的收益很明显但需要服务端框架和 CDN 都支持才行。2.4 200/201/202/204成功也分“给谁看”终于讲到 2xx。这组状态码看似最简单却是我在评审 API 设计时最常挑毛病的地方。200 OK 是最通用的成功响应但它也是最没有信息量的成功。如果一个写操作返回 200 且没有 body客户端只知道“没失败”但不知道是“创建了新资源”还是“更新了已有资源”。更麻烦的是很多团队喜欢“业务全 200”——不管成功失败HTTP 一律回 200错误信息写在 body 的 code 字段里。这样做好不好设计和联调时很省事前端只要判断业务码就行。但副作用会在链路中放大网关和日志系统无法按状态码区分错误比例监控告警捕捉不到“接口业务失败率”CDN 会把业务失败的响应也正常缓存重试策略也没法按状态码精细化设计。一旦出现“接口返回 200 但用户操作没生效”的投诉排查链条会非常长。所以后端同学设计接口时我建议优先让 HTTP 状态码表达“传输结果”让 body 里的业务码表达“业务结果”两者各司其职201 Created资源创建成功响应头必须带Location指向新资源的 URI。我见过大量团队创建接口返回 200 新 ID严格来说不算错但语义上确实差了一点。202 Accepted请求已被接收但处理是异步的后续结果靠回调或轮询。消息队列、任务系统特别适合用 202不过你需要通过文档明确告诉调用方“别指望同步拿到结果”。204 No Content服务器成功处理请求但没有内容返回。DELETE 操作最常用 204更新操作也可以。注意 204 响应不能带 body也不能有 Content-Length或必须为 0。还有一个容易被归到 2xx 但实际是“部分成功”的 206 Partial Content客户端发了Range头请求部分内容服务器只返回了一部分。断点续传、视频拖动、多线程下载都依赖它。你要是发现某个下载工具拿不到完整体积的文件先用它发的Range头和服务端返回的Content-Range头对一对通常能定位是源站不支持 Range 请求还是代理层把 206 吞成了 200。3. 3xx 不是“跳转”两个字能概括的语义、缓存和循环陷阱3xx 是我在面试里最喜欢问的一块因为它能暴露一个人是“背过状态码”还是“真处理过重定向”。3.1 301 和 302 最大的坑方法和报文体会不会被改写很多资料把 301 定义为“永久重定向”、302 定义为“临时重定向”然后就没有然后了。但真实线上最容易出事的是重定向发生时请求方法和请求体的处理。HTTP 规范里的 301/302 有个历史遗留问题早期浏览器收到 301/302 后无论原始方法是 GET 还是 POST都会把后续请求改成 GET 并丢弃 body。RFC 后来其实允许客户端在 307/308 才保留方法和 body但 301/302 到底改不改方法实际取决于客户端实现。现代浏览器面对 301/302 时只有原始方法是 GET/HEAD 时才能保持方法如果是 POST会改成 GET。这导致一个超级常见的线上坑前端把表单 POST 提交到一个返回 302 的接口浏览器自动改造成 GET 请求跟随重定向后端在 GET 里取不到数据。你以为重定向没生效实际上是方法被“静默改写”了。3.2 303、307、308三个“补丁”各自解决什么问题303 See Other服务器明说“结果请看另一个 URI用 GET 去取”。它主动告诉客户端把 POST 改成 GET适合表单提交后的“PRG 模式”Post/Redirect/Get能防止刷新页面时重复提交。307 Temporary Redirect语义和 302 类似但有明确约束必须保留原始请求方法和 body不允许改写。跨服务接口迁移时如果上游接口仍在使用旧地址且调用方发的是 POST用 307 能保证 body 完整透传。308 Permanent Redirect301 的“保方法”版本永久重定向且保留请求方法和 body。HTTP 明文升级到 HTTPS 时经常用的就是 308。我自己的经验是设计和排查重定向时不要只看状态码一定要看原始请求方法、跟随重定向后的请求方法、浏览器或 SDK 的类型三者组合。比如 curl 默认在 301/302 下也不会改写 POST 为 GET但浏览器会所以你“用 curl 测通了”不代表“用户浏览器里能跑通”。3.3 304 Not ModifiedHTTP 缓存里性价比最高的状态码304 不是错误它是“缓存验证通过”的成功响应。客户端带着If-None-Match对应 ETag或If-Modified-Since对应 Last-Modified去问服务器“我手上的版本还新鲜吗”服务器对比后认为客户端缓存仍然有效就返回 304且响应体为空。这个状态码的好处是省流量、省延迟。但实际环境里 304 经常“失灵”我排查过的几类原因服务端返回的 ETag 每次都变。比如有些人把 ETag 直接设成响应体 MD5但响应体里带了时间戳或随机数一看就是新的304 永远不会触发。响应头里没有正确的缓存校验字段。ETag 缺失或 Last-Modified 不更新客户端无从校验。中间层把 200 强制缓存了。CDN 或网关在源站返回 304 之前就自己回了 200源站的 304 策略根本没机会生效。这里补一句304 响应本身不能带 body但可以带Cache-Control头用来更新缓存的生命周期。很多同学不知道这个能力看到 304 就以为缓存策略不能变其实只要服务器想改完全可以在 304 里告诉客户端“往后缓存时间改成 24 小时”。3.4 重定向循环那种“打不开页面”到底是谁的锅浏览器里出现ERR_TOO_MANY_REDIRECTS时通常不是服务器宕机而是重定向逻辑在循环。最经典的复现方式curl -i -L http://example.com/login-L参数让 curl 自动跟随重定向你会看到一连串 301/302 请求。常见循环原因有几类URL 规范化逻辑写反http://example.com/a跳到http://example.com/b/b又跳到/a。登录态判断不一致未登录跳登录页登录页又因为“已经登录”跳回首页首页再说你未登录三者形成死循环。这种通常要看 Set-Cookie 的 Domain/Path 配置是否在多个跳转间被覆盖。强制 HTTPS 和强制 www 同时存在且各有各的判断条件两个规则互相踩。HSTS 头和重定向叠加浏览器本地已经有 HSTS 强制跳 HTTPS服务器又下发一个指向 HTTP 的 302行为会变得很拧巴。排查时不要一上来就猜先用curl -i -L --max-redirs 5看循环的完整请求链再从第一次跳转开始核对每个 Location 头是谁生成的很快就能定位。4. 4xx 的语义分层从“请求本身有问题”到“给你看但就是不给你”4xx 是线上出现频率最高的错误集合也是最容易被“一刀切”处理的一部分。很多团队的网关日志里 4xx 只分两类400 和 404其他都被归为“other”导致故障发生后只能翻后端日志。状态码语义分得越细你能从入口日志里判断出的信息就越多。4.1 401 和 403一个说“你是谁”一个说“你不配”401 Unauthorized 的字面意思是“未认证”语义是“服务器不知道你是谁或者你的凭证不合法”。它必须配合WWW-Authenticate响应头告诉客户端用哪种认证方式Basic、Bearer 等。如果客户端带着凭证再请求一次还是 401那就是凭证错误或过期。403 Forbidden 的字面意思是“服务器认识你但你不允许访问这个资源”。注意这里的“认识你”不一定是登录态也可能是 IP 白名单、Referer 校验、User-Agent 过滤。真实的坑在于很多团队把“未登录”返回 403把“没权限”也返回 403把 WAF 拦截也返回 403混在一起后用方没法区分。我的建议是未登录、token 缺失或失效用 401并提示重新登录。已登录但权限不足用 403。WAF/风控拦截用 403 没问题但响应体里要有明确的拦截原因和请求 ID方便用户反馈时定位。顺带一提浏览器里访问某些需要基本认证的接口时如果服务端返回 401浏览器可能会弹出认证框。这是处理敏感接口时的一个体验问题有的团队为了规避这个弹窗故意把未认证返回 403这属于“用语义换取体验”可以理解但要想清楚下游调用方能从 403 里判断出“该重新登录”吗如果不能就说明这个交换不合算。4.2 400 和 422语法错了和内容错了400 Bad Request 表示“请求本身是坏的”比如 JSON 解析失败、缺少必填字段、请求头格式错误。它的问题是“客户端请求语法或结构不合法服务器无法处理”。但很多时候服务器能解析请求只是内容上不符合业务规则比如年龄字段传了 -5。这时候再用 400 就会掩盖“参数校验失败”和“报文解析失败”的本质区别。422 Unprocessable Content 就是来解决这个问题的请求格式没问题但语义或业务规则校验失败。虽然 422 最初来自 WebDAV但现在已经广泛用于 REST API 的参数校验场景。我在接口规范文档里通常把两者划分得很清楚请求无法被解析、字段类型错误、JSON 结构错误 → 400。请求能被解析但字段取值不符合业务规则 → 422响应体里最好带字段级错误详情。4.3 404 和 410找不到和曾经有过但现在没了404 是大家最熟悉的状态码表示“服务器找不到你请求的资源”。但 404 在业务上有两种非常不同的场景一种是资源不存在用户查一个不存在的订单一种是路由本身就没配访问一个不存在的接口路径。前者往往需要在 body 里返回业务错误详情后者通常是网关统一的 404 页面。如果你把两者混在一个日志规则里接口排错会非常难受。410 Gone 在中文技术团队里用得很少但它很有用表示“这个资源曾经存在但现在被永久移除了”且服务器不想给重定向地址。比如下架的文档、已删除的商品详情页返回 410 比返回 404 更能让客户端/搜索引擎明白“这不是路径写错了是资源真没了”。4.4 405 与 406方法不对、格式不要405 Method Not Allowed请求方法不被允许比如只支持 POST 的接口收到了 GET。规范要求响应头带Allow字段列出该 URI 支持的所有方法。如果你排查时发现某接口“时好时坏”看一下是不是客户端用了 OPTIONS 或 HEAD 探测而服务端没配。406 Not Acceptable客户端通过Accept头声明自己只接受某些类型服务器无法满足。比如客户端要求application/xml服务端只支持application/json。这个状态码在内部系统间调用时更容易出现排查时先抓请求头里的Accept别盯半天响应体。4.5 408、413、414、429、431那批“看得懂但不知道怎么查”的高频问题这组状态码的共同特点是它们在网关层或中间件上比在应用层更常见而且经常被“包装”成别的样子。408 Request Timeout 表示服务器等待客户端请求时超时。弱网环境下客户端发了半个请求就停了服务器等不到完整头部就会返回 408。注意它和 504 的方向正好相反408 是服务器觉得“客户端太慢了”504 是网关觉得“上游太慢了”。413 Content Too Large 表示请求体超过服务器限制。上传文件被 Nginx 的client_max_body_size拦下来时最常见的响应就是 413。排查时除了看应用配置还要看中间有没有其他代理层每一层的 body 大小限制都可能触发它。414 URI Too Long 表示请求行里的 URI 超长。这种问题通常不是用户手动输入的而是某个客户端把大量参数拼接在 URL query 里或 Cookie 值被塞进了重定向 URL。429 Too Many Requests 表示限流了是最有“机器味”的一个状态码。它通常带Retry-After头告诉客户端多久之后再来。但很多客户端根本不读Retry-After导致用户那边表现为“一会儿好一会儿坏”。我在网关限流配置里会刻意把 429 的响应格式做得和业务错误格式一致方便调用方统一解析。431 Request Header Fields Too Large 和 414 很像但问题出在整体头部而不是 URL 上。我之前排查过一个特别典型的案例用户在某个系统里操作时浏览器端突然出现HTTP Error 400. The request header field is too long服务端其实返回的是 431 语义——请求头太大—但当时用的 Web 服务器把原因短语写得不够明确。翻看抓包才发现元凶是一个超大的 Cookie系统在某次升级后把一大串用户信息写进了 Cookie单个 Cookie 值到了十几 KB超过了 Web 服务器默认的请求头大小上限。解决方式也不复杂要么把用户信息从 Cookie 迁到服务端会话存储要么调大请求头上限但调大上限要慎重因为这会同时放大 Slowloris 类攻击的占用。4.6 冷门但真实存在的 416、417、425、426416 Range Not Satisfiable客户端发Range头请求某文件但请求的区间超出的文件大小。下载工具断点续传时如果本地文件和服务端文件大小不一致容易撞上。417 Expectation Failed前面提过的Expect: 100-continue的“拒绝回应”。425 Too Early与 HTTP 的早期数据机制相关当前端在 TLS 握手尚未完成时就发送 HTTP 数据服务器可以回 425 拒绝处理。426 Upgrade Required服务器要求客户端先升级协议配合Upgrade头使用。现在极罕见但可以知道。5. 5xx 不是“服务器挂了”四个字能打发的网关、源站、代理之间的责任归属5xx 的排查难点不是“识别故障”而是“定位故障发生在链路的哪一跳”。我见过最多的线上事故恰恰是 502 和 504 并发出现时研发、运维、前端各执一词最后发现各自监控采样的视角不同。5.1 500 和 501内部出错和“我不会”500 Internal Server Error 是最笼统的服务端错误表示“服务器遇到意外情况无法完成请求”。它可能是应用抛了未捕获的异常也可能是中间件配置写错。注意一点500 也可能是别的服务返回的比如网关把上游错误统一包装成 500 返回给客户端。我一直建议团队在网关层做状态码透传或明确标识不要让客户端去猜 500 到底是应用的问题还是网关的问题。501 Not Implemented 表示服务器不认识这个请求方法或者根本不支持该功能。这个状态码在实际业务里很少见但如果你的服务暴露了某些自定义 HTTP 方法代理层不支持时就会看到 501。还有一类特殊的“500 变体”IIS 的 500.19。它不是应用程序异常而是 IIS 配置错误比如站点配置文件中引用了不存在的模块。你会在浏览器看到一个类似HTTP Error 500.19 - Internal Server Error的页面。出现这种错误时别再去翻应用日志先去检查 IIS 的配置节和错误附带的具体 config 源信息。这类“带子编码”的状态码还有不少都是从 500 或 4xx 衍生出来的细分化标识排查时要认得它们是“平台特化”的状态码不是 RFC 标准里定义的。5.2 502、503、504网关链路里最容易被甩锅的三兄弟502 Bad Gateway 的准确定义是网关或代理从上游服务器收到了无效响应。比如上游返回的内容无法解析、连接被重置、上游直接关闭连接。注意502 的重点是“无效响应”不是“没响应”。503 Service Unavailable 的准确定义是服务器当前无法处理请求通常是临时的比如过载、维护中。它经常伴随Retry-After头表达“多久能好”。504 Gateway Timeout 的准确定义是网关在等待上游响应时超时了。这三个状态码最容易被搞混的场景如下状态码典型链路现象排查方向502网关发出请求后上游返回的内容无法被解析或连接被重置上游服务是否崩溃、连接是否被误杀、响应体是否被截断503服务本身在运行但没有能力处理更多请求过载保护、连接池耗尽、运维主动摘除节点504网关把请求转给上游后超过等待时间没收到结果上游接口慢、网关超时时间配置过短我处理过一个很典型的 504 案例新服务上线后手机端用户频繁报“接口超时”Web 端访问完全正常。后来对比两端请求路径才发现Web 端走的是新网关超时设置为 5 秒手机端走的是旧网关超时时间还是 2 秒。而新服务里有个列表接口因为关联查询需要 3 秒。解决方案是给手机端配更长超时并且推动新服务优化查询。这个案例的本质就是 504 出现在“网关等待上游”这一跳而不是应用本身崩溃。5.3 502 的元凶之一上游断开连接和 499 的连锁反应抓过包的人都见过 499这是 Nginx 自定义的状态码表示“客户端在服务器处理完之前就主动关闭了连接”。499 本身不属于 HTTP 标准但在 Nginx 日志里非常常见尤其是上游请求耗时长时客户端等得不耐烦直接断开Nginx 就会记录 499。而且 499 出现时上游服务可能已经收到请求只是响应发出时客户端已经不在了。所以你在源站日志里看到“请求成功了”但在 Nginx 日志里看到 499两者并不矛盾。更隐蔽的情况是客户端断开后Nginx 向源站转发请求时发现上游连接已经被客户端断开源站那边表现可能是连接中断、写响应失败最终你在源站日志里看到的反而可能是 500 或 502。这就是为什么我强调“看状态码要看是谁记的日志”同一个故障不同节点记录的“证据”完全不同。5.4 非标准 5xx 和“HTTP 000”这种伪状态码除了 Nginx 的 499还有一组常见的非标准 5xxNginx 和 Cloudflare 的 520–527 系列。比如 520 表示源站返回了未知内容521 表示源站拒绝连接522 表示 TCP 连接超时524 表示源站响应超时525 表示 TLS 握手失败。这些状态码的语义比通用 502/504 更精准但只适用于特定网关遇到时不要套 RFC 的解释要查对应网关的官方文档。还有一个更“伪”的数字HTTP 000。很多语言 SDK 和包管理工具在“根本没有收到 HTTP 响应”时会打印 000比如网络层连接失败、TLS 证书错误、DNS 解析失败、请求被取消。这不是服务器返回的状态码而是客户端侧的“无响应”标记。常见报错如CondaHTTPError: HTTP 000 CONNECTION FAILED for url https://...Docker 拉镜像时看到的net/http: request canceled也属于这类。遇到 000第一反应不应该是查服务端日志而是先在客户端机器上做网络连通性测试DNS 解析是否正常、目标端口是否可达、TLS 握手是否成功、是否有代理干扰。5.5 503 和过载保护主动降级和被动崩溃之间的选择503 经常被设计成“主动返回”的状态码比如限流器触发、服务进入降级模式时直接回 503。比起崩溃式的 500503 至少告诉调用方“服务还在但暂时没能力”配合Retry-After头调用方可以做更优雅的重试。这里有一个很容易被忽略的细节Retry-After可以是秒数也可以是一个 HTTP 日期。如果你只实现了一种解析方式遇到另一种格式的重试策略就会失效。6. 状态码排查速查三件套读法加一张表比背 RFC 有用得多到这你已经把 1xx 到 5xx 过了一遍但我知道你现在最想要的是“回头万一遇到问题该从哪里下手”。我整理了一套三个步骤的顺手流程。6.1 不管什么状态码先读三样东西不要只盯着状态码本身每次接到接口报错先看完整响应三件套响应头Server告诉你是谁返回的Via或X-Cache能暴露经过了哪些层WWW-Authenticate定位 401Retry-After定位 429/503。响应体标准状态码定位不了业务异常业务错误码和专业错误信息在 body 里。请求上下文同一个 URL 用 curl 复现一次对比自己手动请求和应用代码里请求的差异通常在 header 或 session 上。比如我之前排查过一次 403用户反馈“换了个网络环境就访问不了”我用自己的电脑 curl 完全正常一查发现用户那边走了公司代理代理出口 IP 被 WAF 的规则匹配了WAF 返回 403 而不是应用返回 403。这里如果不看Server头很难区分到底是哪个角色做的拦截。6.2 一张够用的状态码速查表以下是我自己整理的最常用速查表不是 RFC 全量列表但覆盖了 95% 的线上场景状态码含义排查第一落点100继续发送请求体大请求上传时关注200请求成功正常但注意 body 里的业务码201创建成功检查 Location 头204无内容DELETE/更新接口常见206部分内容Range 请求、断点续传301永久重定向方法是否被改写、缓存是否生效302临时重定向方法是否被改写303用 GET 访问另一个 URIPRG 模式常用304缓存未修改ETag/Last-Modified 是否正确307临时重定向保留方法表单 POST 迁移时用308永久重定向保留方法HTTP 升 HTTPS400请求语法错误JSON 解析、缺少字段、请求头过大401未认证是否带正确的凭证头403无权限被拒绝区分权限、WAF、IP 封禁404资源不存在区分路由缺失和业务资源缺失405方法不被允许检查 Allow 头408请求超时客户端发送不全409资源冲突并发写、版本冲突410资源永久删除资源下架语义413请求体过大检查每层上传限制414URI 过长检查 query 参数和 Cookie 拼接415媒体类型不支持检查 Content-Type/Accept416Range 范围不满足对比文件大小422请求语义/业务校验失败检查业务参数规则425请求过早TLS 握手时序异常426需要升级协议检查 Upgrade 头429限流检查 Retry-After、所在网关的限流策略431请求头过大检查超大 Cookie500服务端内部错误查应用异常日志501未实现方法或功能不支持502网关收到无效响应查上游连接、上游响应完整性503服务不可用查过载、维护、降级策略504网关超时查上游接口耗时、网关超时配置505HTTP 版本不支持升级服务端或协议507存储空间不足查磁盘499客户端断开Nginx 自定义查客户端超时与请求耗时6.3 一个“分角色定位”的通用套路前端或客户端同学报来一个问题时我通常会按下面的顺序问下去谁发的请求浏览器、App、服务端 SDK、还是 curl不同客户端对 3xx 和 4xx 的处理方式差异很大。状态码是从哪一层返回的直接看Server头或者问运维在 Nginx/CDN 日志里看到什么。请求有没有到达应用查应用访问日志如果应用里根本没有这条请求记录问题大概率在网关或上游路由。如果请求到达了但报 5xx拿应用异常日志、数据库慢查询、下游调用耗时三段对齐。如果请求没到达但报 4xx大概率是网关拦截、参数校验在网关提前失败、URL 格式不合法。这套流程跑下来大部分状态码问题能在十分钟内定位出责任节点剩下的小部分要么是链路太长要么是日志缺失那就得靠链路追踪才能继续了。我个人在实际操作中还有一个小习惯把公司的接口响应规范附上“何时返回哪个状态码”的说明而不是只写“200 成功500 失败”。比如创建订单接口返回 201、校验失败返回 422、限流返回 429、依赖下游超时返回 504。这样前端、测试、运维、乃至客服同学都能拿同一套语义对齐比任何“状态码大全”都管用。很多团队的排障效率上不去不是缺工具是大家心里对“这个状态码代表什么”没有统一的标准先把这套共识立起来后面所有排查链路都会顺很多。