跳到主要内容

免费 HTTP 状态码参考

可搜索的完整 HTTP 状态码参考——每个状态码的含义、使用场景和常见原因。从 100 到 511。

加载后可离线使用

61 个状态码

100

继续

服务器已接收请求头,客户端应继续发送正文。

用于 Expect: 100-continue 请求。服务器确认愿意在客户端发送正文前接收。在现代网络应用中很少见。

RFC 9110 ↗
101

切换协议

服务器正在按客户端要求切换协议。

最常用于 WebSocket 升级 — 客户端请求 Upgrade: websocket,服务器响应 101 进行切换。

RFC 9110 ↗
102

处理中

服务器已接收请求并正在处理,但尚无响应可用。

WebDAV 中间响应,用于在冗长操作期间防止客户端超时。已弃用 — 现代服务器不应发送。

RFC 2518 ↗
103

早期提示

在最终响应前发送的初步头。

让服务器在准备最终响应期间发送链接头 (预加载/预连接),以便浏览器可以更快地开始获取关键资源。

RFC 8297 ↗
200

OK

请求成功。

标准成功响应。具体含义取决于 HTTP 方法:GET → 返回资源,POST/PUT → 操作完成。

RFC 9110 ↗
201

已创建

新资源已成功创建。

常见于 POST 后。响应应包含指向新资源 URL 的 Location 头。

RFC 9110 ↗
202

已接受

请求已被接受以进行处理,但处理尚未完成。

用于异步操作 — 服务器正在排队处理。客户端应轮询状态端点或稍后重新检查。

RFC 9110 ↗
203

非权威信息

响应被转换代理修改。

请求成功,但中介 (如缓存或转换代理) 改变了来自原始服务器的有效负载 — 例如重新压缩图像。在实践中很少见。

RFC 9110 ↗
204

无内容

请求成功但没有响应正文。

通常用于 DELETE 操作或不需要返回正文的 PUT 更新。客户端不应离开当前页面。

RFC 9110 ↗
205

重置内容

请求成功;客户端应重置文档视图。

类似于 204,不返回正文 — 但另外告知客户端重置生成请求的表单或视图 (例如清空表单字段以供下一条输入)。

RFC 9110 ↗
206

部分内容

服务器仅交付了部分资源。

对 Range 请求的响应。由视频播放器和下载管理器使用,用于恢复中断的下载或流式传输大文件。

RFC 9110 ↗
207

多状态

响应正文包含多个操作的多个状态代码。

WebDAV:XML 正文独立报告多个子操作的结果 — 例如批量移动,其中某些项成功,其他项失败。

RFC 4918 ↗
208

已报告

集合的成员已在响应中更早列出。

WebDAV:在 207 多状态响应内使用,以避免在绑定创建循环时重复列出同一集合的成员。

RFC 5842 ↗
226

已使用 IM

响应是应用于资源的实例操作的结果。

增量编码:服务器返回与以前版本的差异,而不是完整资源,节省带宽。极少实现。

RFC 3229 ↗
300

多种选择

资源的多个表示形式可用。

服务器提供多个选项 (例如不同的格式或语言),客户端应选择一个。很少使用,因为自动内容协商通常处理这个。

RFC 9110 ↗
301

永久移动

资源已永久移动到新 URL。

用于永久 URL 更改 — 搜索引擎将更新其索引。SEO 权重转移到新 URL。

RFC 9110 ↗
302

已找到 (临时重定向)

资源暂时位于不同的 URL。

表示重定向不是永久的。缓存不如 301 那样激进。用于诸如 '需要登录,重定向到 /login' 之类的事情。

RFC 9110 ↗
303

查看其他

使用 GET 重定向到另一个 URL。

在 POST 提交后使用 — 响应表示 '您的 POST 成功了,请查看此 GET URL 以获取结果'。浏览器始终 GET 新 URL。

RFC 9110 ↗
304

未修改

缓存的版本仍然有效;使用它。

对条件请求 (带有 If-None-Match 或 If-Modified-Since 头) 的响应。节省带宽 — 不返回正文。

RFC 9110 ↗
307

临时重定向

类似于 302 但保留原始 HTTP 方法。

如果原始请求是 POST,重定向也使用 POST。当方法保留重要时,307 是 302 的现代替代方案。

RFC 9110 ↗
308

永久重定向

类似于 301 但保留原始 HTTP 方法。

301 的现代替代方案,适用于希望 POST 请求在重定向后仍保持为 POST 的情况。

RFC 9110 ↗
400

错误请求

服务器由于语法错误而无法理解请求。

常见原因:正文中的 JSON 格式错误、无效的查询参数或缺少必需字段。检查请求正文和头。

RFC 9110 ↗
401

未授权

需要身份验证但未提供。

客户端必须包含身份验证凭据 (Authorization 头、Cookie、令牌)。'Unauthorized' 是用词不当 — 它实际上意味着 '未认证'。

RFC 9110 ↗
402

需要付款

保留供将来使用 — 有时用于付费 API 层级。

最初用于数字支付。现代用法:当用户超过其付费配额时,API 有时会返回 402。

RFC 9110 ↗
403

禁止

客户端已认证但没有权限。

与 401 不同 — 用户已登录,但其账户没有此资源的权限。检查角色/权限逻辑。

RFC 9110 ↗
404

未找到

请求的资源不存在。

URL 错误、资源已删除或从未存在。服务器有时会返回 404 来隐藏 403 更准确的事实。

RFC 9110 ↗
405

方法不允许

此资源不允许使用的 HTTP 方法。

例如,对仅接受 POST 的端点的 GET 请求。响应应包含列出有效方法的 Allow 头。

RFC 9110 ↗
406

不可接受

没有表示形式与客户端的 Accept 头匹配。

客户端要求服务器无法满足的内容类型、语言或编码 (通过 Accept、Accept-Language、Accept-Encoding)。许多服务器跳过严格协商并返回默认值。

RFC 9110 ↗
407

需要代理身份验证

客户端必须首先通过代理进行身份验证。

类似于 401,但由代理发出:客户端必须发送代理授权凭据。在具有身份验证代理的企业网络上很常见。

RFC 9110 ↗
408

请求超时

服务器等待请求超时。

客户端发送请求体用时过长或保持连接空闲状态。请重试请求。

RFC 9110 ↗
409

冲突

请求与资源的当前状态冲突。

通常返回于并发编辑冲突或重复资源创建(例如,使用已存在的电子邮件创建用户)。

RFC 9110 ↗
410

已删除

资源已被删除且不会返回。

比 404 更强 — 服务器明确知道资源曾经存在但已被永久删除。搜索引擎会将其从索引中移除。

RFC 9110 ↗
411

需要 Content-Length

服务器要求 Content-Length 标头。

请求被拒绝,因为缺少 Content-Length 标头,服务器拒绝接收大小未知的请求体。请添加标头并重试。

RFC 9110 ↗
412

前置条件失败

请求标头中的条件未满足。

在条件标头(如 If-Match 或 If-Unmodified-Since)验证失败时返回 — 通常为乐观锁定:自你的版本以来,其他人更改了资源。请重新获取并重试。

RFC 9110 ↗
413

请求体过大

请求体超过服务器大小限制。

上传大文件时常见。服务器配置(nginx、apache)设置了最大请求体大小。请检查服务器配置。

RFC 9110 ↗
414

URL 过长

请求 URL 超过服务器长度限制。

通常由非常长的查询字符串引起(例如在 GET 中编码数据)。改用 POST 请求体,或者如果你可以控制服务器,提高服务器限制。

RFC 9110 ↗
415

不支持的媒体类型

服务器无法处理发送的 Content-Type。

例如,向仅接受 application/json 的服务器发送 application/xml。请正确设置 Content-Type 标头。

RFC 9110 ↗
416

范围不可满足

请求的字节范围超出资源大小。

Range 标头要求文件不具有的部分 — 例如,恢复下载超过文件末尾。响应应包含具有实际大小的 Content-Range。

RFC 9110 ↗
417

期望失败

服务器无法满足 Expect 标头的要求。

在服务器不支持 Expect: 100-continue 时发送。某些客户端在大型 POST 上默认发送此标头;禁用它通常会解决错误。

RFC 9110 ↗
418

我是茶壶

服务器拒绝酿造咖啡,因为它是茶壶。

1998 年的愚人节笑话(RFC 2324)。某些真实 API 用它来开玩笑或标记已弃用的端点。不用于生产。

RFC 2324 ↗
421

请求方向错误

请求发送到无法为其生成响应的服务器。

常见于 HTTP/2 连接重用:请求到达未为目标主机名配置的服务器。客户端应在新连接上重试。

RFC 9110 ↗
422

无法处理的内容

请求在语法上有效但语义错误。

例如,JSON 解析正确但缺少必需字段,或字段值超出范围。在 REST API 验证响应中常见。

RFC 9110 ↗
423

已锁定

资源被锁定。

WebDAV:源或目标资源被另一个客户端锁定,因此操作无法进行。等待锁释放或使用正确的令牌中断它。

RFC 4918 ↗
424

依赖失败

请求失败,因为先前的相关请求失败。

WebDAV:在一系列相关操作中,较早的操作失败,因此此操作未执行。查看较早的失败以找到根本原因。

RFC 4918 ↗
425

时间过早

服务器拒绝处理可能被重放的请求。

与 TLS 1.3 0-RTT(早期数据)相关:服务器将不会冒可能重放请求的风险。客户端应在握手完成后重试。

RFC 8470 ↗
426

需要升级

客户端必须切换到其他协议。

服务器拒绝在当前协议上服务请求,但在升级后会 — 响应包含命名所需协议的 Upgrade 标头。

RFC 9110 ↗
428

需要前置条件

服务器要求请求是条件性的。

服务器要求条件标头(如 If-Match)以防止丢失更新冲突。获取资源、捕获其 ETag,并使用 If-Match 重新发送。

RFC 6585 ↗
429

请求过多

客户端被速率限制。

放慢速度。响应应包含 Retry-After 标头,指示何时重试。常见于具有请求配额的 API。

RFC 6585 ↗
431

请求标头字段过大

标头对服务器来说太大,无法处理。

单个标头或总标头大小超过限制 — 最常由过大的 cookies 引起。清除 cookies 或减少应用在其中存储的内容。

RFC 6585 ↗
451

因法律原因不可用

因法律要求而拒绝访问。

资源因法律原因被阻止 — 审查、法庭命令或地区法规。这个数字是对小说《华氏 451 度》的致敬。

RFC 7725 ↗
500

内部服务器错误

服务器遇到意外条件。

服务器端错误的通用包罗万象。检查服务器日志以找到实际原因:未处理的异常、数据库错误等。

RFC 9110 ↗
501

未实现

服务器不支持请求的功能。

例如,服务器不识别 HTTP 方法。实际上很少见 — 更常见的是看到 405。

RFC 9110 ↗
502

网关错误

充当网关的服务器从上游服务器获得了错误的响应。

在微服务架构中常见。你的负载均衡器或反向代理从后端服务获得了格式错误的响应。

RFC 9110 ↗
503

服务不可用

服务器暂时无法处理请求。

要么正在维护,要么过载。响应应包含 Retry-After 标头。通常在部署期间返回。

RFC 9110 ↗
504

网关超时

网关服务器等待上游响应超时。

后端服务响应速度不够快。检查上游服务健康状况和超时配置。

RFC 9110 ↗
505

不支持的 HTTP 版本

服务器不支持请求中使用的 HTTP 版本。

请求的 HTTP 主要版本不受服务器支持。在现代客户端中几乎从不出现。

RFC 9110 ↗
506

变体也进行协商

服务器具有内容协商配置错误。

透明内容协商陷入循环:所选变体本身配置为协商。表示服务器配置错误。

RFC 2295 ↗
507

存储空间不足

服务器磁盘空间已满。

WebDAV 特有,但有时由常规服务器使用。意味着服务器由于存储限制而无法保存请求。

RFC 4918 ↗
508

检测到循环

服务器在处理请求时检测到无限循环。

WebDAV:处理 Depth: infinity 请求时进入循环(例如循环绑定)。操作已终止。

RFC 5842 ↗
510

未扩展

需要进一步的请求扩展。

来自已过时的 HTTP 扩展框架:服务器在满足请求之前需要更多信息。实际上在现代网络上未使用。

RFC 2774 ↗
511

需要网络身份验证

客户端必须进行身份验证才能获得网络访问权限。

被强制网络门户(酒店/机场 WiFi)使用,表示用户必须先登录网络,然后才能访问外部站点。

RFC 6585 ↗

常见用途

  • API 设计参考设计 REST API 时,为每个响应选择正确的状态代码。
  • 快速查找错误代码当你的应用返回令人困惑的 HTTP 错误时,查找它实际上是什么意思。
  • 学习 HTTP 状态代码为学习 HTTP 和 REST 的学生和开发人员提供的综合参考。
  • 事件响应期间的快速参考在生产事件期间,快速查找每个状态代码的含义。
  • API文档参考在编写API文档时,链接到您返回的状态代码的权威描述。

工作原理

此工具是一个客户端参考手册,围绕硬编码的 63 个 HTTP 状态码查找表构建,涵盖全部五个类别(1xx–5xx),每个都注明了定义它的 RFC 编号。没有服务器调用、没有外部 API、没有网络请求——所有筛选和显示都在浏览器中使用 JavaScript 内置的数组和字符串方法完成。

  1. 1
    加载查找表
    全部 63 个 IANA 注册的状态码以 JavaScript 数组形式直接嵌入此工具,每个条目包含数字代码、标准英文名称、类别以及定义它的具体 RFC(例如大多数 HTTP/1.1 状态码为 RFC 9110,429 Too Many Requests 为 RFC 6585,418 I'm a Teapot 为 RFC 2324)。
  2. 2
    在内存中筛选
    你输入或选择类别筛选时,JavaScript 的 Array.filter 会对内存中的列表运行,使用 String.includes 将你的查询与状态码数字、标准名称以及简短和详细描述进行匹配——没有防抖延迟,没有服务器往返。
  3. 3
    展开详情并附 RFC 链接
    每个结果都渲染为 HTML details/summary 元素。展开条目会显示详细说明以及指向 rfc-editor.org 上权威 RFC 的直接链接,方便你阅读任何状态码的准确规范原文。
  4. 4
    深度链接与剪贴板复制
    打开条目会将网址哈希更新为状态码数字(例如 #404),使页面便于分享和收藏。复制按钮通过浏览器的 navigator.clipboard API 将标准字符串(例如 '404 Not Found')写入剪贴板。

相关工具

常见问题