HTTP状态码速查表

按 RFC 9110 的五大类收录 62 个常用状态码，用「码 / 短语 / 语义 / 常见触发场景」四列逐条对照，并把 301 与 302 与 307 与 308、401 与 403、502 与 504 这些最容易记混的码单独拆开讲。

搜索（码、短语或中文关键词）

状态码大类

按码定位（100～599）

共 62 行，默认显示前 12 行，点「加载更多」展开
码	短语	语义	常见触发场景
100	Continue	服务器已收到请求头，客户端可以继续发送请求体	客户端带 Expect: 100-continue 的分块上传
101	Switching Protocols	按 Upgrade 头把连接切换到另一种协议	WebSocket 握手升级
102	Processing	请求已收到、正在处理，但还没有结果	WebDAV 里的长事务
103	Early Hints	最终响应之前先送回一部分响应头	提前下发 Link: rel=preload 让浏览器先预加载
200	OK	请求成功，是否带响应体由方法和场景决定	常规 GET / POST 成功返回
201	Created	资源已被创建，Location 指向新资源	REST 接口 POST 新建资源
202	Accepted	请求已接受，但尚未处理完成	把任务投递到异步队列
203	Non-Authoritative Information	响应头来自中间转换代理，并非源站原样	代理重写了响应头
204	No Content	处理成功、但没有响应体	DELETE 成功、表单提交后不回内容
205	Reset Content	处理成功，并要求客户端重置文档视图	表单提交后清空输入框
206	Partial Content	只返回了请求的字节范围	视频拖动进度条、断点续传
207	Multi-Status	一次请求里多个子操作各有各的状态	WebDAV 批量操作
208	Already Reported	同一集合成员已在前面的响应里报过	WebDAV 绑定循环
226	IM Used	响应是实例操作的增量结果	Delta 编码占位
300	Multiple Choices	同一资源有多个可选表示	同内容的多语言、多格式
301	Moved Permanently	资源已永久迁移，Location 指向新地址	域名改版、http 全站跳 https
302	Found	临时重定向；历史上会被改写成 GET	登录后跳回原页、灰度切流
303	See Other	请改用 GET 去取另一个地址	POST 之后重定向到结果页
304	Not Modified	缓存仍然新鲜，不必返回响应体	带 If-None-Match 的协商缓存
305	Use Proxy	必须经指定代理访问（已废弃）	只在历史实现中出现
307	Temporary Redirect	临时重定向，且必须保持原方法	要保方法的临时切流
308	Permanent Redirect	永久重定向，且必须保持原方法	要保方法的永久迁移
400	Bad Request	请求语法或参数有问题	请求体不是合法 JSON
401	Unauthorized	缺少有效身份凭证，须带 WWW-Authenticate	未登录就访问受保护接口
402	Payment Required	保留状态码，留给将来的计费场景	个别网关拿来提示欠费
403	Forbidden	身份已识别，但没有权限访问	普通账号访问管理员接口
404	Not Found	找不到目标资源	URL 拼错、资源已被删除
405	Method Not Allowed	该方法不被该资源支持，须带 Allow	对只读接口发 POST
406	Not Acceptable	做不出符合 Accept 头的表示	只支持 JSON，客户端却只要 XML
407	Proxy Authentication Required	必须先向代理完成认证	企业内网的认证代理
408	Request Timeout	服务器等请求等到超时	客户端网络慢、请求只发了一半
409	Conflict	与资源当前状态冲突	并发编辑、唯一键重复
410	Gone	资源已永久删除且不会恢复	下架后不再上架的商品页
411	Length Required	必须带 Content-Length	老客户端漏发长度头
412	Precondition Failed	请求的前置条件不满足	If-Match 乐观锁失败
413	Content Too Large	请求体超过服务器允许的上限	上传大文件被拒
414	URI Too Long	请求目标过长	超长查询串
415	Unsupported Media Type	请求体的媒体类型不被支持	上传了服务器不认识的 Content-Type
416	Range Not Satisfiable	Range 超出资源实际长度	断点续传起点越界
417	Expectation Failed	Expect 头无法被满足	老代理不支持 100-continue
418	(Unused)	RFC 9110 明确保留、不予使用	只作为彩蛋梗出现
421	Misdirected Request	请求被送到了无法响应的连接	HTTP/2 连接合并、SNI 不匹配
422	Unprocessable Content	语法正确，但语义上无法处理	表单校验失败
423	Locked	资源处于锁定状态	WebDAV 的编辑锁
424	Failed Dependency	依赖的动作失败，导致本请求失败	WebDAV 批量操作
425	Too Early	不愿处理可能被重放的早期数据	TLS 0-RTT 的重放风险
426	Upgrade Required	必须先把协议升级到指定版本	强制升级到 TLS 或 HTTP/2
428	Precondition Required	要求请求必须带前置条件	防更新丢失，强制带 If-Match
429	Too Many Requests	触发了限流	接口调用频率超限
431	Request Header Fields Too Large	请求头字段过大	Cookie 越积越大
451	Unavailable For Legal Reasons	因法律原因不可用	合规要求下架
500	Internal Server Error	服务器内部错误	代码里有未捕获的异常
501	Not Implemented	服务器不支持该功能	调用了还没实现的方法
502	Bad Gateway	上游返回了无效响应	反向代理后面的进程挂了
503	Service Unavailable	暂时不可用，可带 Retry-After	过载、停机维护
504	Gateway Timeout	等待上游响应超时	后端卡死、连接池耗尽
505	HTTP Version Not Supported	不支持该 HTTP 版本	客户端用了服务器不支持的大版本
506	Variant Also Negotiates	内容协商本身配置错误	极少见
507	Insufficient Storage	存储空间不足	WebDAV 上传
508	Loop Detected	检测到无限循环	WebDAV 目录绑定
510	Not Extended	需要对请求做扩展才能处理	极少见
511	Network Authentication Required	需要先完成网络层认证	公共 WiFi 的登录门户

页面打开时表格里已经按顺序铺好 62 行真实数据，不用点任何按钮就已经是完整示例。搜索框里直接按 Enter 即可筛选；「按码定位」输入框里按 Enter 会跳到对应那一行。

使用方法

在「搜索」框里输入三位数字（例如 404）、英文短语（例如 Bad Gateway）或中文关键词（例如 重定向），表格立刻只留下匹配的行。搜索是子串匹配，不加通配符。
只想看某一类，就在「状态码大类」里选 1xx / 2xx / 3xx / 4xx / 5xx；默认「全部」，此时 62 行全部参与匹配。
手上已经有一个确切的码，把它填进「按码定位」（允许 100～599 的整数），点「定位该码」或直接按 Enter，该行会被高亮，其余行自动让开。
表格默认只展开前 12 行。点「加载更多」会把当前筛选条件下的剩余行一次铺开，按钮随后变为「已展开全部」并置灰。
要留档就点「复制对照表」，得到的是制表符分隔文本，可以直接粘进 Excel；或者点「导出 CSV」，文件带 BOM，用 Excel 打开中文不会乱码。

这个 HTTP状态码速查表能解决什么问题

第一件是把日志里的三位数字翻译成人话。抓包、看网关日志、翻浏览器 Network 面板时，最先跳出来的永远是一个数字；本页把它对应到英文短语、语义和典型触发场景，省掉反复搜索的时间。

第二件是对齐接口文档里的短语写法。RFC 9110 重新整理过一批短语，很多框架和博客还在用旧名：413 现在写作 Content Too Large（旧名 Payload Too Large），422 现在写作 Unprocessable Content（旧名 Unprocessable Entity），416 现在写作 Range Not Satisfiable（旧名 Requested Range Not Satisfiable）。写文档时按新写法对齐，评审时不容易被当成笔误。

第三件是理清成对出现的码。真正让人写错代码的不是 404 这种一眼就懂的码，而是 301 与 302 与 307 与 308 之间的方法保持、401 与 403 之间的认证与授权、502 与 504 之间的「回了个坏响应」和「根本没回响应」。这几组本页都在下面逐组拆开。

第四件是为缓存与重定向策略提供依据。哪些码可以被缓存、哪些码必须带校验头、204 和 304 为什么不能有响应体，答案都能从类别（首位数）和具体条目推出来。这一份 HTTP状态码速查表收录的 62 行里，4xx 占了 29 行，因为线上日志里客户端错误出现的频率确实最高。

本页不做这些事：不替你发起任何请求、不解析你的响应报文、不判断业务自定义错误码的含义，也不给出「该返回什么码」的架构建议。它是一张对照表，不是一台诊断仪。

五大类与首位数：RFC 9110 是怎么划分的

按 RFC 9110《HTTP Semantics》第 15 章，状态码是一个三位十进制整数，取值范围 100～599（也就是 500 个可能的编号，本页收录其中最常用的 62 个）。分类规则简单到只有一条：看首位数字。

1xx信息性：请求已被接收，还需继续处理。它只能是中间响应，不能作为最终响应发回给客户端；唯一的例外是 101，它把连接切换到另一种协议之后就不再回到 HTTP 语义。

2xx成功：请求被成功接收、理解并接受。要看清楚有没有响应体：200 有，204 和 205 不允许有，206 只包含请求的字节范围。

3xx重定向：还需要进一步动作才能完成请求。要同时看两件事——是永久还是临时，以及是否必须保持原方法。

4xx客户端错误：请求本身有问题，或者客户端没有权限。这一类比 5xx 更容易被误当成服务端故障去排查。

5xx服务端错误：服务器承认是自己在处理这个（看起来合法的）请求时失败了。收到 5xx 通常要去查服务端日志，而不是改请求参数。

输入到输出经过了这几步。你在搜索框里敲的字符串先做首尾去空格和转小写；然后工具把每一行的四项内容（码、短语、语义、触发场景）拼成一条小写文本，做子串包含判断；同时按首位数字做类别过滤。两个条件都通过的行走入结果集，再按当前展开状态决定显示前 12 行还是全部。CSV 与「复制对照表」导出的也是当前匹配集，不是固定不变的 62 行。

记忆头部的几个硬性约束。这些不是习惯问题，而是规范要求：401 必须带 WWW-Authenticate 响应头，407 必须带 Proxy-Authenticate，405 必须带 Allow，426 必须带 Upgrade，503 可以带 Retry-After 告诉客户端多久后再来；204 和 304 不得携带消息体。缓存行为则另看 RFC 9111《HTTP Caching》：304 只有配合 If-None-Match 或 If-Modified-Since 这样的条件请求头才出现，它的意思是「你手里的副本还能用」。

常见误用。把 4xx 一律当成「服务器坏了」是最普遍的一种；把 500 当成「请求参数不对」是另一种。判据其实很直白：首发问题的责任方在哪一边，首位数就往哪一边靠。此外，状态码是给程序和缓存看的，不是给人看的文案——把「用户不存在」塞进 200 的响应体里，等于主动放弃缓存语义和监控告警。

完整示例：四组最容易记混的状态码

下面每一组都会给出判据，而不只是背定义。四组共用的思路是：先问「谁的问题」，再问「是不是永久」，最后问「方法保不保」。

第一组，301 与 302 与 307 与 308。它们是「永久/临时」和「是否保持方法」两个维度交叉出来的四个格子。301 是永久迁移，308 也是永久迁移；302 是临时，307 也是临时。真正的分界线在第 307 和 308 上：它们必须原样保持请求方法，客户端不能自作主张把 POST 改成 GET；而 301 和 302 在历史上被大量客户端改写成 GET，规范也允许这么做。所以把一个 POST 接口永久迁走时，只有 308 能保证方法不丢。另外别把 303 混进来——303 就是要求改用 GET 去取另一个地址，是「POST 之后跳结果页」那个模式的标准写法。

码	短语	永久还是临时	方法是否保持
301	Moved Permanently	永久	规范允许客户端改成 GET，历史上多被改写
302	Found	临时	同样允许被改写成 GET
303	See Other	临时	强制改用 GET 去取目标地址
307	Temporary Redirect	临时	必须保持原方法，POST 依旧是 POST
308	Permanent Redirect	永久	必须保持原方法，POST 依旧是 POST

第二组，401 与 403。401 的名字 Unauthorized 起得不好，它其实是「未认证」：请求里没有凭证，或者凭证无效、过期、签名不对，服务端不知道你是谁，响应必须带 WWW-Authenticate 告诉客户端该用哪种认证方式。403 Forbidden 是「已认证但无权」：服务端已经认出你，你要访问的东西也在，只是你的身份不够。两者的修复动作完全不同——401 要去补登录态或刷新 token，403 要去改授权策略或换个账号。把「登录过期」返成 403，会让前端的自动跳登录逻辑整个失灵，这是最常见的接口事故之一。

第三组，502 与 504。两者都出自网关或反向代理，区别在于上游回没回。502 Bad Gateway：上游回了一个响应，但这个响应无效或者无法理解（连接被重置、返回了非 HTTP 内容、响应头不合法）。504 Gateway Timeout：上游在网关的时限内根本没有回应。排查方向因此相反——502 先看上游进程是不是崩了或返回了脏数据，504 先看后端是不是卡住、连接池是不是耗尽、超时阈值是不是设得太短。同一个后端，把超时阈值调小会让 504 变多，而不会让 502 变多，这就是最快的验证方法。

第四组，200 与 204 与 206。200 OK 是通用成功，按方法和场景决定是否带响应体。204 No Content 是「成功了，但没有任何正文」，且规范禁止带消息体——DELETE 成功、PUT 成功、表单提交后不需要回内容的场景适合用它，好处是省掉一个字节都不需要的传输。206 Partial Content 只出现在客户端带了 Range 请求头的时候，服务端把请求的那一段字节回过去，并带 Content-Range 说明这是哪一段；视频拖动进度条、大文件断点续传都靠它。把 204 当成「返回空 JSON」来用是个陷阱：很多客户端会把零长度响应体的 204 当作解析失败。

输入范围与对照表（62 个状态码）

页面顶部那张表就是这份 HTTP状态码速查表的主体：四列分别是「码 / 短语 / 语义 / 常见触发场景」，共 62 行，默认展开前 12 行，其余用「加载更多」铺开，也可以用搜索和大类筛选把它筛出来；筛选结果会同步影响复制与导出。

收录范围与条数分布如下（按复算脚本对 62 行逐行统计）：

类别	编号范围	含义	本表条数
1xx	100～199	信息性，中间响应	4 条（6.5%）
2xx	200～299	成功	10 条（16.1%）
3xx	300～399	重定向	8 条（12.9%）
4xx	400～499	客户端错误	29 条（46.8%）
5xx	500～599	服务端错误	11 条（17.7%）

边界与精度说明

只覆盖 100～599 的三位码。三位十进制的上限是 599，RFC 9110 没有为 600 及以上的编号定义语义。有些框架内部会拿 600+ 当业务码用，那不是 HTTP 状态码，本表不收录。
不是每个编号都被分配。100～599 这 500 个编号里，实际被规范分配或注册的是少数；像 306 这种曾经出现过又不再使用的编号，本表不收录，用「按码定位」查它会明确提示「未收录」，而不是给一个猜测的答案。
4xx 占 29 条是有原因的。复算脚本对 62 行逐行统计，4xx 占 46.8%，是五大类里最多的一类。这不是收录偏好，而是这些码在实际日志里的确最常出现。
短语写法以 RFC 9110 为准，社区旧名并存。413、416、422 三个码在 RFC 9110 里都换了短语，很多框架、CDN 文档和中文博客仍在用旧名。看到旧名不必以为看错了版本，但写新文档建议按新写法对齐。
语义列是规范语义，不是业务语义。同一个码可以被不同业务解释成完全不同的意思。比如 402 在规范里是「保留待用」，某些网关却拿它来表示账户欠费；409 在规范里指与资源当前状态冲突，有的系统拿它表示「重复提交」。做跨系统对接时，以对方的接口文档为准。
搜索是子串匹配，不做分词。输入单个字母 c 会命中一大片短语；输入 timeout 会同时命中 408 和 504，因为两者的场景描述里都有这个词。想精确定位就填完整的三位数。
数字列不做本地化。码、编号范围、条数都按复算脚本输出的原值展示，不四舍五入、不加千分位，方便直接复制进代码和文档。

常见问题

401 和 403 到底怎么分？一句话判据是什么？

看服务端认不认识你。不认识（没带凭证、凭证无效或过期）就是 401，它会附带 WWW-Authenticate 让客户端知道该用什么方式认证；认识你但你没有这项权限就是 403。修复动作也对得上：401 去补登录态，403 去改授权。

301 和 302 在浏览器里看起来一样，为什么说一定要分清？

因为浏览器为了兼容历史行为，会把收到 301 或 302 的非 GET 请求改写成 GET再发一遍，这会让原本的 POST 体悄悄丢掉。规范允许这种改写，所以想保证方法不丢只能用 307（临时）或 308（永久）。另外 301 默认可被缓存，浏览器和 CDN 会长期记住，302 通常不会被长期缓存，改错了回滚代价差别很大。

502 和 504 我该先查哪一边？

先确认上游有没有回。502 说明上游回了，但内容非法或连接异常，查上游进程日志和它返回的报文；504 说明上游在网关时限内没有回应，查后端是否卡住、连接池是否耗尽、超时阈值是否过短。把网关超时调小只会让 504 变多，不会影响 502 的数量。

接口成功了但不需要返回内容，用 200 还是 204？

用 204。它语义上就是「成功、无正文」，而且规范禁止它带消息体，能省掉一次无意义的传输。注意不要把 204 当成「返回空 JSON」来用：零长度的响应体让不少客户端在解析时直接报错，需要返回结构体就用 200 加一个空对象。

206 是谁发出来的？我要主动处理吗？

只有当请求带了 Range 头时，服务端才应该返回 206，并附上 Content-Range 说明返回的是哪一段。视频拖动、音频跳播、大文件断点续传都由浏览器自动发起，你通常不用手动处理；但如果 CDN 对某个资源不支持 Range，拖动进度条就会退化成整段重下。

429 和 503 都是「别来了」，区别在哪？

429 Too Many Requests 是对你这一方的限流：你这个来源的调用频率超了，换一个来源或等一会儿就好，通常配合 Retry-After 告诉你等多久。503 Service Unavailable 是对所有人的不可用：服务在过载或维护中，和你这一方无关。监控告警要分开配，否则限流会淹没真正的故障。

表里的短语为什么和我框架里看到的不一样？

因为 RFC 9110 在 2022 年重新整理过一批用词：413 从 Payload Too Large 改为 Content Too Large，422 从 Unprocessable Entity 改为 Unprocessable Content，416 从 Requested Range Not Satisfiable 改为 Range Not Satisfiable。框架为了兼容老代码，往往还沿用旧字符串。两者指的是同一个码，含义没有变化。

为什么找不到 306、427 这些码？

因为它们没有被有效分配或不推荐使用。100～599 只是可用的编号区间，不等于每个数字都有定义。本表只收录在 RFC 9110 及配套 RFC 中有明确语义、且实际可能遇到的码，找不到某个编号时，「按码定位」会直接告诉你是「未收录」而不是给你一个编出来的解释。