HTTP状态码是服务器针对客户端所发出的请求, 而给出的一种标准化的响应标识, 它完整地覆盖了从数字100到数字599的所有情况, 并且这总共分为五个不同的类别。

借助一些专门用来查询HTTP状态码的工具, 开发人员、运维人员以及测试人员, 可以在短短的数秒之内, 快速定位出这些响应的具体含义, 以及找出导致故障的根本原因, 这样就完全不用再去一条条地翻阅那些非常专业的RFC 9110文档了。

下面这里提供了一份全量的分类对照表, 还有具体的排查路径, 大家可以把它直接当作一个标准参考, 用于日常的开发调试工作, 也可以用于接口测试环节, 当然在线上出现故障需要定位问题时, 也同样可以直接拿来使用作为参考依据。

一、五类状态码概览

1xx是信息性响应, 在100到199这个范围里面, 它的含义就是请求已经被接收了, 但是处理还在进行中, 还没有完成。

结果是成功的情况, 具体的情况归类为2xx这个范围, 数字方面是从200一直到299这一段的区间, 意思是请求已经被正确地处理了, 并且返回来了相应的结果内容。

当状态码落在3xx范围里面, 也就是说在300到399之间的时候, 这代表重定向, 客户端接下来需要去执行额外的操作, 只有这样才能够把请求给完成掉。

4xx这个状态码的范围是从400到499, 它表示的是客户端错误, 意思就是说, 你发过来的那个请求啊, 本身是有一些缺漏或者有问题的。

出现了服务端错误, 这个错误的类别是5xx, 具体的数值范围是从500到599, 造成这种情况的原因是服务器没办法去处理本来属于合法状态的请求。

上述的分类定义, 是依据RFC 9110这个关于HTTP语义的标准文档里的第15节制定的。所以, 所有状态码的语义解释, 都要以该标准文档为准。

二、高频状态码对照表的这个表格。

在日常做开发以及日常做运维的时候, 会碰到很多种状态码, 下面把这些出现频率最高的状态码列出来, 并且把它们经常遇到的那些典型场景也同时说一下。

200 OK: 表示请求成功, 然后返回的是一个正常的响应体。

返回201 Created这个状态码, 代表资源创建成功了, 这种情况通常都会在POST请求完毕之后才会出现。

204 No Content：请求成功但无响应体HTTP状态码查询工具龙南市就业服务平台，常用于DELETE操作。

这个错误代码是301, 它的意思是资源已经永久迁移到了一个新的URL地址去, 所以现在大家应该把之前所有的引用都更新一下。

这个状态码是302 Found, 它的含义是临时重定向, 客户端虽然会跟随跳转HTTP状态码查询工具，但是它不会缓存该映射。

返回的HTTP状态码是304 Not Modified, 这个情况代表资源没有变更, 客户端可以使用本地的缓存副本。

出现了四百, 也就是坏请求这样的状况, 意思就是所发出的请求存在语法方面的错误, 或者是其中的参数没有办法被服务端进行解析。

出现了401 Unauthorized这种状况, 意思就是缺少认证凭据, 或者是现有的认证凭据已经失效, 所以需要重新登录系统, 或者尝试刷新一下Token令牌。

这个响应的状态码是403, 它的意思是禁止访问。你的身份已经通过认证了, 也就是你已经登录成功了。但是你的权限不够, 所以你还无法访问那个你试图去接触的目标资源。

出现了404 Not Found这种情况, 这基本上意味着你请求的那个URL路径在服务器上面并不存在。

405 Method Not Allowed, 这个HTTP的方法是被当前这个资源所支持的类型给拒绝掉的。

这个409冲突的意思是, 请求和资源当前的状态存在矛盾, 比如说就是版本上出现了冲突的问题。

出现了 429 Too Many Requests这个错误提示, 它的含义是触发了限流策略, 需要降低请求频率。

出现了500Internal Server Error这个状况, 这表示服务端抛出了一个未预期的异常, 你需要去查看应用日志。

502错误表示Bad Gateway, 也就是网关或者代理服务器收到了来自上游服务那边发过来的内容里存在不对头的地方, 导致响应无效。

这个503状态表示服务暂时不可用, 响应头里通常会带着Retry-After这个信息。

504 Gateway Timeout , 也就是网关等待上游服务返回结果的时间已经超过了预设的限制, 于是出现了超时这种情况。

三、快速排查路径

遇到异常状态码时，建议按以下三步定位：

第一步, 我们要先把这个类别归属的问题先判断清楚, 如果是4xx这种问题, 我们就要优先去检查一下请求参数、认证Token以及URL的拼写和HTTP方法是否正确, 而如果是5xx这样的问题的话, 我们就得优先去看一下服务端日志、数据库连接池的状态以及上游依赖能不能用。

在第二步的时候, 我们要把响应头和响应体这两个东西结合起来一起分析。当看到401或者403错误代码的时侯, 要特别关注一下WWW-Authenticate这个响应头还有权限策略的情况出现与否。

如果是遇到404错误代码的话, 需要去核对一下路由注册的内容以及静态资源的路径设置对不对。要是碰到了502或者是504这种比较严重的错误状况的话, 必须得检查一下Nginx或者网关那边上游部分的配置有没有问题, 同时还要查看一下健康检查机制是否正常运作着。

第三步, 我们要对日志进行复现并做关联分析, 操作方式是使用相同请求在测试环境里面去执行一遍流程, 然后把Nginx访问日志和错误日志拿去与应用框架日志以及分布式链路追踪记录一一做比对工作, 最终目的就是能够准确地圈出异常抛出事件所在的特定模块名称以及对应的具体代码行号。

四、交互式查询工具

除了咱们这篇文章里头摆出的那个静态对照表以外, 团队在日常进行调试以及代码审查工作的时候, 是可以去使用HTTP状态码查询工具来进行交互式的检索的, gz88.cn 这个网站的开发者工具板块里面是内置了全量状态下码检索功能的, 它支持按照类别来进行筛选, 也支持关键字搜索, 同时还会附带针对常见的组合场景所给出的排查建议。

如果您想要去弄明白某个状态码, 在特定的框架里面, 比如是像Spring、Express、还有Django这类框架, 存在什么样的默认行为上的差别。

您可以在这个工具里面, 把状态码和框架名称放在一起。进行一个组合查询的操作。这样做的目的呢。是为了能够让开发团队快速地查阅这些信息。方便在内部分享的时候使用。