HTTP 状态码

所有 HTTP 状态码的完整参考,包含描述和示例。

显示 61/61

1xx 信息

4 个状态码

100

继续

服务器已接收请求头,客户端应继续发送请求体。这用于优化大文件上传,允许客户端在发送完整负载之前检查服务器是否会接受该请求。

常见用例: 当客户端在上传大型请求体之前发送 Expect: 100-continue 头时使用,允许服务器在不浪费带宽的情况下提前拒绝请求。

RFC 9110
101

切换协议

服务器正按照客户端通过 Upgrade 头的请求切换到不同的协议。服务器同意并将在此响应后使用新协议进行通信。

常见用例: 最常见于将 HTTP 连接升级为 WebSocket 连接时。客户端发送 Upgrade: websocket 头,服务器以 101 响应确认切换。

RFC 9110
102

处理中

服务器已接收并正在处理请求,但尚无可用响应。这可以防止客户端在服务器处理长时间运行的操作时超时。

常见用例: 用于可能需要较长时间完成的 WebDAV 操作。让客户端知道服务器没有断开连接,仍在处理请求。

RFC 2518
103

早期提示

服务器在最终响应之前发送初步响应头。这允许客户端在服务器仍在准备完整响应时开始预加载资源。

常见用例: 用于提前发送 Link 头,以便浏览器可以在最终 HTML 响应到达之前预加载 CSS、JavaScript 或字体,从而提高页面加载性能。

RFC 8297

2xx 成功

10 个状态码

200

成功

请求已成功。成功的含义取决于 HTTP 方法:GET 返回请求的资源,POST 返回操作的结果,依此类推。

常见用例: 大多数 API 调用的标准成功响应。当 GET 请求返回数据、PUT 请求更新资源或任何操作成功完成并带有响应体时使用。

RFC 9110
请求
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}
201

已创建

请求已满足,新资源已被创建。响应通常包含指向新创建资源的 Location 头。

常见用例: 在成功创建新资源的 POST 请求后返回,例如创建新用户账户、添加博客文章或上传文件。

RFC 9110
请求
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}
响应
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}
202

已接受

请求已被接受进行处理,但处理尚未完成。该请求最终可能会也可能不会被执行,因为在实际处理时可能会被拒绝。

常见用例: 用于服务器将任务排入队列以供后续处理的异步操作,例如发送电子邮件、生成报告或触发批处理作业。

RFC 9110
203

非权威信息

请求成功,但头中返回的元数据可能来自本地或第三方副本,而不是源服务器。所包含的负载是源服务器 200 响应的修改版本。

常见用例: 实际中很少使用。当转换代理修改源服务器的响应头时可能出现,表明元数据可能与原始数据不匹配。

RFC 9110
204

无内容

服务器已成功处理请求,响应负载体中没有额外内容需要发送。响应可能包含更新的头。

常见用例: 在成功的 DELETE 请求后返回,或在不需要响应体的 PUT/PATCH 更新后返回。也用于仅需确认的即发即忘操作。

RFC 9110
请求
DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 204 No Content
205

重置内容

服务器已处理请求,并希望用户代理重置导致发送请求的文档视图。不包含响应体。

常见用例: 用于告诉客户端重置提交请求的表单或界面。例如,成功提交表单后,服务器可以通知浏览器清除表单字段。

RFC 9110
206

部分内容

由于客户端发送了 Range 头,服务器仅交付资源的一部分。这用于可恢复下载和媒体流。

常见用例: 当客户端请求大文件的特定字节范围时使用,支持可恢复下载、视频跳转和并行分块下载等功能。

RFC 9110
207

多状态

一种 WebDAV 响应,在可能需要多个状态码的情况下传达有关多个资源的信息。响应体是包含每个子请求各自状态码的 XML 文档。

常见用例: 用于每个子操作可能有不同结果的 WebDAV 批量操作。例如,复制多个文件时某些成功而某些失败。

RFC 4918
208

已报告

在 DAV: propstat 响应元素内使用,以避免重复枚举同一集合的多个绑定的内部成员。

常见用例: 一种 WebDAV 状态,用于避免由于绑定而在集合内多个位置出现的同一资源被多次列出。

RFC 5842
226

IM 已使用

服务器已满足对资源的 GET 请求,响应是应用于当前实例的一个或多个实例操作结果的表示。

常见用例: 与增量编码一起使用,仅发送资源当前版本与先前缓存版本之间的更改(增量),以减少带宽使用。

RFC 3229

3xx 重定向

7 个状态码

300

多种选择

目标资源有多种表示形式,用户或用户代理可以选择首选的一种。服务器可能包含可用表示形式的列表。

常见用例: 实际中很少使用。当资源以多种格式(例如 JSON、XML、HTML)可用且服务器希望客户端明确选择时可能使用。

RFC 9110
301

永久移动

目标资源已被分配新的永久 URI,此资源的任何未来引用都应使用返回的 Location URI。搜索引擎将更新其索引。

常见用例: 当页面或 API 端点已永久移动到新 URL 时使用。在重组网站、更改域名或废弃旧 URL 模式时对 SEO 至关重要。

RFC 9110
请求
GET /old-page HTTP/1.1
Host: www.example.com
响应
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html

<html><body>This page has moved to <a href="https://www.example.com/new-page">/new-page</a>.</body></html>
302

已找到

目标资源临时位于不同的 URI 下。由于重定向可能会偶尔更改,客户端应继续使用原始 URI 进行未来请求。

常见用例: 用于临时重定向,例如重定向到登录页面、将用户发送到维护页面或对不同页面版本进行 A/B 测试。

RFC 9110
请求
GET /dashboard HTTP/1.1
Host: www.example.com
响应
HTTP/1.1 302 Found
Location: https://www.example.com/login?redirect=/dashboard
303

查看其他

服务器正在使用 GET 请求将用户代理重定向到不同的资源,通常在 POST 操作之后。这确保客户端不会重新提交表单数据。

常见用例: 在 POST 表单提交后用于重定向到确认页面(Post/Redirect/Get 模式),防止用户刷新页面时重复提交表单。

RFC 9110
304

未修改

自请求头 If-Modified-Since 或 If-None-Match 指定的版本以来,资源未被修改。服务器不需要再次发送资源体。

常见用例: 当客户端发出条件请求且资源未更改时返回,允许客户端使用其缓存副本。这节省了带宽并改善了加载时间。

RFC 9110
请求
GET /api/users/42 HTTP/1.1
Host: api.example.com
If-None-Match: "etag-abc123"
响应
HTTP/1.1 304 Not Modified
ETag: "etag-abc123"
Cache-Control: max-age=3600
307

临时重定向

目标资源临时位于不同的 URI 下,用户代理在跟随重定向时不得更改请求方法。与 302 不同,方法和请求体保证保持不变。

常见用例: 当需要严格保留 HTTP 方法的临时重定向时使用。例如,将 POST 请求重定向到另一个端点而不将其更改为 GET。

RFC 9110
308

永久重定向

目标资源已被分配新的永久 URI。与 301 类似,但在跟随重定向时请求方法和请求体不得更改。

常见用例: 用于需要保留 HTTP 方法的永久重定向。例如,永久重定向 POST 端点同时确保客户端继续发送 POST 请求。

RFC 9110

4xx 客户端错误

29 个状态码

400

错误请求

由于被认为是客户端错误(如格式错误的请求语法、无效的请求帧或欺骗性的请求路由),服务器无法或不愿处理该请求。

常见用例: 当请求体包含格式错误的 JSON、缺少必填字段、查询参数无效或请求不符合预期格式时返回。

RFC 9110
请求
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "",
  "email": "not-an-email"
}
响应
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "validation_error",
  "message": "Request validation failed",
  "details": [
    { "field": "name", "message": "Name is required" },
    { "field": "email", "message": "Must be a valid email address" }
  ]
}
401

未授权

由于缺少目标资源的有效身份验证凭据,请求未被应用。响应必须包含 WWW-Authenticate 头,指示适用的身份验证方案。

常见用例: 当请求缺少身份验证凭据或提供的令牌/凭据已过期或无效时返回。客户端需要在重试之前进行身份验证。

RFC 9110
请求
GET /api/users/me HTTP/1.1
Host: api.example.com
响应
HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer

{
  "error": "unauthorized",
  "message": "Authentication required. Please provide a valid Bearer token."
}
402

需要付款

保留供将来使用。最初用于数字支付方案,此状态码未被广泛标准化,但有时被 API 用于指示需要付款。

常见用例: 虽然官方为保留状态,但某些 API 使用它来指示需要付费功能或订阅,或用户已超出免费层使用限制。

RFC 9110
403

禁止访问

服务器理解了请求但拒绝授权。与 401 不同,身份验证无济于事。客户端没有该资源所需的权限。

常见用例: 当用户已通过身份验证但没有所需权限时返回。例如,普通用户尝试访问仅限管理员的端点,或访问属于其他用户的资源。

RFC 9110
请求
DELETE /api/users/99 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden",
  "message": "You do not have permission to delete this user. Admin role required."
}
404

未找到

源服务器未找到目标资源的当前表示,或不愿透露该资源的存在。这可能是临时的或永久的。

常见用例: 最常遇到的错误。当请求的资源不存在时返回,例如通过数据库中不存在的 ID 请求用户,或访问没有匹配路由的 URL。

RFC 9110
请求
GET /api/users/99999 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "not_found",
  "message": "User with ID 99999 was not found"
}
405

方法不允许

请求行中接收的方法为源服务器所知,但目标资源不支持。响应必须包含列出有效方法的 Allow 头。

常见用例: 当端点不支持该 HTTP 方法时返回。例如,向只读资源发送 DELETE 请求,或向仅支持 GET 的端点发送 POST。

RFC 9110
请求
DELETE /api/reports/monthly HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Allow: GET, HEAD

{
  "error": "method_not_allowed",
  "message": "DELETE is not allowed on this resource. Allowed methods: GET, HEAD"
}
406

不可接受

根据请求中接收到的主动内容协商头,目标资源没有用户代理可接受的表示形式。

常见用例: 当服务器无法生成与客户端发送的 Accept 头匹配的响应时返回。例如,客户端请求 XML 但 API 仅支持 JSON。

RFC 9110
407

需要代理身份验证

与 401 类似,但客户端需要向代理进行身份验证。代理必须返回包含适用质询的 Proxy-Authenticate 头。

常见用例: 当客户端未为代理本身提供有效凭据时由代理服务器返回。在出站流量通过经过身份验证的代理的企业网络环境中常见。

RFC 9110
408

请求超时

服务器在其准备等待的时间内未收到完整的请求消息。客户端可以在之后的任何时间重复该请求而无需修改。

常见用例: 当客户端发送完整请求耗时过长时返回。可能在连接缓慢、通过不可靠网络进行大文件上传或客户端打开连接但不发送数据时发生。

RFC 9110
409

冲突

由于与目标资源的当前状态存在冲突,请求无法完成。客户端应能够解决冲突并重新提交请求。

常见用例: 当请求与现有数据冲突时使用,例如使用已存在的电子邮件创建用户,或尝试更新自上次获取以来已被其他请求修改的资源。

RFC 9110
请求
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}
响应
HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "conflict",
  "message": "A user with email jane@example.com already exists",
  "existing_id": 42
}
410

已删除

目标资源在源服务器上不再可用,此状态很可能是永久的。与 404 不同,这明确表示资源曾经存在但已被故意删除。

常见用例: 当资源被故意且永久删除时使用。向搜索引擎发出信号,应将该 URL 从索引中移除,与可能是临时的 404 不同。

RFC 9110
411

需要内容长度

服务器拒绝接受没有定义 Content-Length 头的请求。如果添加了有效的 Content-Length 头,客户端可以重复该请求。

常见用例: 当服务器要求请求中存在 Content-Length 头时返回,通常用于服务器需要预先知道负载大小的上传或 POST 请求。

RFC 9110
412

前提条件失败

请求头字段中给出的一个或多个条件在服务器上测试时评估为 false。用于 If-Match 或 If-Unmodified-Since 等条件请求。

常见用例: 当条件更新因资源自客户端上次获取后已被修改而失败时返回。用于在 API 中实现乐观并发控制。

RFC 9110
413

内容过大

服务器拒绝处理请求,因为请求负载大于服务器愿意或能够处理的大小。服务器可能会关闭连接或返回 Retry-After 头。

常见用例: 当文件上传或请求体超过服务器配置的最大大小限制时返回,例如向 10MB 限制的端点上传 100MB 文件。

RFC 9110
414

URI 过长

服务器拒绝处理请求,因为请求目标长于服务器愿意解释的长度。当 GET 请求的查询参数过长时可能发生。

常见用例: 当 URL 超过服务器的最大长度时返回。这通常发生在将过多数据编码到查询参数中而不是在 POST 请求体中发送时。

RFC 9110
415

不支持的媒体类型

源服务器拒绝处理请求,因为负载的格式不被目标资源上的此方法支持。Content-Type 或 Content-Encoding 不可接受。

常见用例: 当服务器不支持请求中发送的 Content-Type 时返回。例如,向仅接受 application/json 的端点发送 form-urlencoded 数据。

RFC 9110
416

范围不可满足

请求的 Range 头字段中的范围集已被拒绝,因为所选表示的所有请求范围均不可满足。

常见用例: 当客户端请求超出资源大小的字节范围时返回,例如请求 500 字节文件的第 1000-2000 字节。

RFC 9110
417

期望失败

请求的 Expect 头字段中给出的期望无法被至少一个入站服务器满足。

常见用例: 当服务器无法满足 Expect 头中指定的要求时返回。最常与 Expect: 100-continue 机制相关,当服务器在发送请求体之前拒绝请求时。

RFC 9110
418

我是茶壶

任何用茶壶冲泡咖啡的尝试都应该返回此错误码。这是在超文本咖啡壶控制协议中作为愚人节玩笑定义的,但作为文化符号被保留了下来。

常见用例: 来自愚人节 RFC 的彩蛋状态码。有时在 API 中幽默地用作有趣的响应,或作为服务器认为荒谬的请求的故意拒绝。

RFC 2324
421

误导的请求

请求被定向到无法生成响应的服务器。当服务器未配置为对请求 URI 中的方案和授权组合生成响应时,可能会发生这种情况。

常见用例: 在 HTTP/2 中,当连接被重用于服务器无法处理的不同主机名时可能发生。客户端应在不同的连接上重试请求。

RFC 9110
422

不可处理的内容

服务器理解内容类型且请求语法正确,但无法处理所包含的指令。请求格式正确但语义无效。

常见用例: 当请求体是语法有效的 JSON 但业务逻辑验证失败时使用。例如,设置负价格、安排过去的会议或提供早于开始日期的结束日期。

RFC 9110
请求
POST /api/events HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "Team Meeting",
  "start_date": "2025-12-01",
  "end_date": "2025-11-01"
}
响应
HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "unprocessable_entity",
  "message": "Semantic validation failed",
  "details": [
    { "field": "end_date", "message": "End date must be after start date" }
  ]
}
423

已锁定

方法的源或目标资源已被锁定。客户端应稍后重试或请求解锁。

常见用例: 在 WebDAV 中当资源被其他用户或进程锁定时使用。也可在 API 中使用,表示资源暂时被其他用户锁定以进行编辑。

RFC 4918
424

依赖失败

由于请求的操作依赖于另一个已失败的操作,该方法无法在资源上执行。

常见用例: 在 WebDAV 中当操作因其依赖的先决操作也失败而失败时使用。例如,目录复制失败是因为复制其中一个子文件失败了。

RFC 4918
425

过早

服务器不愿冒险处理可能被重放的请求,以避免在使用 TLS 1.3 早期数据(0-RTT)时的潜在重放攻击。

常见用例: 当请求在 TLS 1.3 早期数据(0-RTT)中到达且服务器无法保证它尚未被处理时使用。防止对非幂等请求的重放攻击。

RFC 8470
426

需要升级

服务器拒绝使用当前协议执行请求,但在客户端升级到不同协议后可能愿意执行。服务器必须包含 Upgrade 头指示所需的协议。

常见用例: 当服务器要求客户端切换到更新的协议版本时使用,例如从 HTTP/1.1 升级到 HTTP/2,或从未加密连接升级到 TLS。

RFC 9110
428

需要前提条件

源服务器要求请求是有条件的。这旨在防止"丢失更新"问题,即一个客户端通过 GET 获取资源、修改后通过 PUT 发回,而另一个客户端也已修改了该资源。

常见用例: 当服务器要求 If-Match 或 If-Unmodified-Since 等条件头以防止并发修改问题时返回。强制客户端实现乐观锁。

RFC 6585
429

请求过多

用户在给定时间内发送了过多请求(速率限制)。响应应包含 Retry-After 头,指示在发出新请求之前应等待多长时间。

常见用例: 当客户端超过 API 速率限制时返回。大多数 API 使用此功能来防止滥用并确保公平使用。客户端应退避并在 Retry-After 头指定的时间后重试。

RFC 6585
请求
GET /api/search?q=test HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
响应
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Maximum 100 requests per minute.",
  "retry_after": 60
}
431

请求头字段过大

服务器不愿处理该请求,因为其头字段过大。在减小请求头字段的大小后,可以重新提交请求。

常见用例: 当请求头超过服务器的大小限制时返回。这通常发生在 Cookie 变得过大,或在自定义头或过大的 Authorization 令牌中传递了过多数据时。

RFC 6585
451

因法律原因不可用

由于法律要求,服务器拒绝访问该资源。响应应在正文中包含法律限制的说明,并包含 Link 头以标识法律授权机构。

常见用例: 当资源因政府审查命令、DMCA 下架通知、法院命令或制裁合规等法律要求而被阻止时使用。代码编号引用了《华氏 451》。

RFC 7725

5xx 服务器错误

11 个状态码

500

内部服务器错误

服务器遇到了阻止其完成请求的意外情况。当没有更具体的 5xx 状态码适用时,这是一个通用的兜底错误。

常见用例: 最常见的服务器错误。当服务器遇到未处理的异常、bug、数据库连接失败或请求处理期间的任何其他意外问题时返回。

RFC 9110
响应
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "internal_server_error",
  "message": "An unexpected error occurred. Please try again later.",
  "request_id": "req_abc123xyz"
}
501

未实现

服务器不支持完成请求所需的功能。当服务器不识别请求方法且无法支持它时,这是适当的响应。

常见用例: 当服务器不识别或尚未实现请求的 HTTP 方法时返回。可用作已计划但尚未构建的 API 端点的占位符。

RFC 9110
502

错误网关

服务器作为网关或代理时,从其访问的上游服务器收到了无效响应,以尝试完成请求。

常见用例: 由反向代理、负载均衡器或 API 网关返回,当上游应用服务器发送格式错误的响应、崩溃或不可达时。在部署期间常见。

RFC 9110
响应
HTTP/1.1 502 Bad Gateway
Content-Type: application/json

{
  "error": "bad_gateway",
  "message": "The upstream server returned an invalid response. Please try again shortly."
}
503

服务不可用

由于临时过载或计划维护,服务器当前无法处理请求。这意味着这是临时状态,服务器将很快再次可用。

常见用例: 在计划维护窗口期间、服务器过载时或关键依赖项宕机时返回。Retry-After 头可以指示客户端何时应重试。

RFC 9110
响应
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300

{
  "error": "service_unavailable",
  "message": "Service is temporarily unavailable for scheduled maintenance. Expected back at 2025-12-01T03:00:00Z.",
  "retry_after": 300
}
504

网关超时

服务器作为网关或代理时,未能及时从其需要访问的上游服务器收到响应以完成请求。

常见用例: 由反向代理或负载均衡器返回,当上游应用服务器响应时间过长时。通常表示数据库查询缓慢、外部 API 超时或后端过载。

RFC 9110
505

HTTP 版本不受支持

服务器不支持或拒绝支持请求消息中使用的 HTTP 主要版本。

常见用例: 当服务器不支持请求中使用的 HTTP 协议版本时返回,例如仅支持 HTTP/1.1 的服务器收到其无法处理的 HTTP/2 请求。

RFC 9110
506

变体也在协商

服务器存在内部配置错误:所选的变体资源被配置为自身参与透明内容协商,导致循环引用。

常见用例: 一个罕见的错误,表明服务器端内容协商存在配置错误,其中协商的资源本身尝试进行协商,创建了无限循环。

RFC 2295
507

存储空间不足

由于服务器无法存储成功完成请求所需的表示,该方法无法在资源上执行。

常见用例: 当服务器在尝试写入数据时磁盘空间或存储配额耗尽时返回的 WebDAV 状态。也可适用于已达到存储限制的 API。

RFC 4918
508

检测到循环

服务器在处理带有 Depth: infinity 的请求时检测到无限循环,因此终止了操作。这是 500 的更具体版本。

常见用例: 当服务器检测到资源绑定中的循环依赖或无限循环时返回的 WebDAV 状态,例如引用自身的目录结构。

RFC 5842
510

未扩展

请求中未满足访问资源的策略。服务器应发回客户端发出扩展请求所需的所有信息。

常见用例: 一个很少使用的状态码,表示服务器需要对请求进行进一步扩展才能满足它。在 HTTP 扩展框架规范中定义。

RFC 2774
511

需要网络认证

客户端需要进行身份验证才能获得网络访问权限。这不是关于 HTTP 级别的身份验证,而是关于网络级别的访问,例如登录强制门户。

常见用例: 当用户尚未通过网络认证时,由强制门户(例如酒店或机场 Wi-Fi 登录页面)返回。响应体通常包含登录页面。

RFC 6585

相关指南

在 RequestDock 中试试

发送真实的 HTTP 请求并检查响应——直接在浏览器中完成。