HTTP 状态码:完整参考指南
· 12分钟阅读
目录
什么是 HTTP 状态码?
HTTP 状态码是服务器响应客户端请求时返回的三位数字。它们指示请求是成功、重定向还是导致错误。每次浏览器加载页面、调用 API 或提交表单时,服务器都会响应一个状态码。
可以把状态码看作是服务器与您的请求沟通发生了什么的方式。就像交通信号灯告诉您是停止还是前进一样,状态码告诉您的应用程序是继续、重试还是处理错误。
状态码根据其第一位数字分为五类:
- 1xx (信息性): 已接收请求,继续处理
- 2xx (成功): 请求已接收、理解并接受
- 3xx (重定向): 需要进一步操作才能完成请求
- 4xx (客户端错误): 请求包含来自客户端的错误
- 5xx (服务器错误): 服务器未能完成有效请求
快速参考: 使用我们的 HTTP 状态码查询 工具快速检查任何状态码并查看带示例的详细说明。
状态码如何工作
当客户端(如您的浏览器或 API 客户端)发出 HTTP 请求时,服务器会处理它并返回响应。此响应始终在第一行包含状态码,后跟标头和可选的正文。
以下是典型 HTTP 响应的样子:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234
{"status": "success", "data": {...}}
状态码出现在 HTTP 版本之后。在此示例中,200 OK 告诉客户端请求成功。
状态码有多种用途:
- 通信: 它们为服务器提供标准化的方式来传达结果
- 错误处理: 应用程序可以根据代码以编程方式处理不同的场景
- 调试: 开发人员可以快速识别请求-响应周期中出现问题的位置
- SEO: 搜索引擎使用状态码来了解如何索引内容
- 缓存: 浏览器和 CDN 使用代码来确定缓存行为
1xx 信息性
信息性状态码表示服务器已收到请求并正在继续处理。这些是临时响应,在日常网页浏览中很少见到,但对于某些协议和优化很重要。
100 Continue
服务器收到了请求标头,客户端应继续发送正文。这用于大型上传,其中客户端发送 Expect: 100-continue 标头以在发送完整有效负载之前检查服务器是否接受请求。
此优化可防止在将被拒绝的请求上浪费带宽。例如,如果您要上传 500MB 的视频文件,您不希望发送所有数据后才发现服务器会因身份验证失败而拒绝它。
POST /upload HTTP/1.1
Host: api.example.com
Content-Length: 524288000
Expect: 100-continue
// 服务器响应 100 Continue
// 然后客户端发送请求正文
101 Switching Protocols
服务器同意按客户端请求切换协议。最常见于使用 Upgrade: websocket 标头从 HTTP 升级到 WebSocket 时。
WebSocket 实现客户端和服务器之间的实时双向通信,这对于聊天应用程序、实时更新和协作工具至关重要。
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
// 服务器响应 101 Switching Protocols
103 Early Hints
这个相对较新的状态码允许服务器在最终响应之前发送初步标头。它通常用于在服务器仍在准备主响应时开始预加载 CSS、字体和 JavaScript 文件等资源。
Early Hints 可以通过允许浏览器在页面加载过程的早期开始下载关键资源来显著改善页面加载时间。
专业提示: 大多数开发人员永远不需要直接处理 1xx 代码。它们通常由 Web 服务器和 HTTP 库自动管理。将错误处理重点放在 4xx 和 5xx 代码上。
2xx 成功
成功代码是您想看到的。它们表示请求已成功接收、理解和接受。不同的 2xx 代码提供有关请求如何处理的细微信息。
200 OK
标准成功响应。请求成功,响应正文包含请求的数据。这是网络上最常见的状态码。
对返回数据的成功 GET 请求、返回已创建资源数据的成功 POST 请求以及返回已更新资源数据的成功 PUT/PATCH 请求使用 200 OK。
GET /api/users/123 HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/json
{"id": 123, "name": "John Doe", "email": "[email protected]"}
201 Created
已成功创建新资源。这是创建新资源的 POST 请求的适当响应。响应应包含指向新创建资源的 Location 标头。
POST /api/users HTTP/1.1
Content-Type: application/json
{"name": "Jane Smith", "email": "[email protected]"}
HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json
{"id": 124, "name": "Jane Smith", "email": "[email protected]"}
202 Accepted
请求已被接受处理,但处理尚未完成。这对于服务器将请求排队以供稍后处理的异步操作很有用。
常见用例包括批处理、电子邮件发送、视频编码以及其他不应阻塞 HTTP 响应的长时间运行操作。
204 No Content
请求成功,但没有要返回的内容。这通常用于 DELETE 请求或客户端不需要返回更新资源的 PUT/PATCH 请求。
使用 204 No Content 而不是带有空正文的 200 OK 可以节省带宽并清楚地传达意图。
DELETE /api/users/123 HTTP/1.1
HTTP/1.1 204 No Content
206 Partial Content
由于客户端发送的范围标头,服务器仅传送资源的一部分。这使得可恢复下载和视频流成为可能,其中客户端请求特定的字节范围。
视频播放器广泛使用此功能,允许在不先下载整个文件的情况下跳转到视频的不同部分。
| 状态码 | 名称 | 何时使用 |
|---|---|---|
200 |
OK | 带内容的标准成功响应 |
201 |
Created | 资源成功创建 |
202 |
Accepted | 请求已排队等待异步处理 |
204 |
No Content | 成功但不需要响应正文 |
206 |
Partial Content | 返回请求的字节范围 |
3xx 重定向
重定向代码表示客户端需要采取其他操作才能完成请求。这些对于 URL 管理、SEO 以及在资源移动时保持向后兼容性至关重要。
301 Moved Permanently
资源已永久移动到 Location 标头中指定的新 URL。浏览器和搜索引擎应更新其记录以使用新 URL。
这是永久重定向的首选状态码。搜索引擎会将 SEO 价值从旧 URL 转移到新 URL,浏览器会缓存重定向。
GET /old-page HTTP/1.1
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
专业提示: 当您永久移动内容时使用 301 重定向。对于临时移动使用 302。弄错这一点可能会损害您的 SEO,因为搜索引擎对它们的处理方式非常不同。
302 Found (临时重定向)
资源暂时位于不同的 URL。客户端应继续使用原始 URL 进行将来的请求。搜索引擎不会通过此重定向转移 SEO 价值。
常见用例包括 A/B 测试、维护页面和临时促销页面。
303 See Other
可以使用 GET 在另一个 URL 找到对请求的响应。这通常在 POST 请求后用于重定向到结果页面,防止用户刷新时重复提交表单。
这实现了 Post/Redirect/Get 模式,这是 Web 表单的最佳实践。
304 Not Modified
自请求标头中指定的版本(If-Modified-Since 或 If-None-Match)以来,资源未被修改。客户端可以使用其缓存版本。
这通过在内容未更改时避免不必要的数据传输,大大减少了带宽使用并提高了性能。
307 Temporary Redirect
类似于 302,但保证重定向时请求方法不会更改。如果原始请求是 POST,则重定向的请求也将是 POST。
308 Permanent Redirect
类似于 301,但保证请求方法不会更改。这是 301 的现代、更精确版本,适用于需要严格保留方法的 API 和应用程序。
4xx 客户端错误
客户端错误代码表示请求包含错误语法或由于客户端问题而无法完成。这些错误意味着客户端需要在重试之前修改请求。
400 Bad Request
由于格式错误的语法、无效的请求消息框架或欺骗性请求路由,服务器无法处理请求。这是不适合其他 4xx 类别的请求的通用错误。
常见原因包括格式错误的 JSON、缺少必填字段、无效的数据类型或违反 API 约束的请求。
POST /api/users HTTP/1.1
Content-Type: application/json
{"name": "John", "email": "not-an-email"}
HTTP/1.1 400 Bad Request
Content-Type: application/json
{"error": "Invalid email format"}
401 Unauthorized
需要身份验证但失败或未提供。尽管名称如此,这实际上意味着"未经身份验证" - 客户端需要提供有效凭据。
响应应包含指示所需身份验证方法的 WWW-Authenticate 标头。
GET /api/protected-resource HTTP/1.1
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"
{"error": "Authentication required"}
403 Forbidden
服务器理解请求但拒绝授权。与 401 不同,身份验证无济于事 - 客户端没有访问此资源的权限。
当用户已通过身份验证但没有必要的权限,或者访问受 IP 地址、速率限制或其他策略限制时使用此代码。