HTTP 速查
HTTP 状态码与 MIME 类型速查表,按 2xx/4xx/5xx 着色,支持实时筛选与点击复制。
显示 62 / 62 · 点击行复制
| 状态码 | 原因短语 | 描述 |
|---|---|---|
| 100 | Continue | 已收到请求头,客户端可继续发送请求体。 |
| 101 | Switching Protocols | 服务器按 Upgrade 头切换协议。 |
| 102 | Processing | 请求处理中,尚无响应(WebDAV)。 |
| 103 | Early Hints | 在最终响应前下发预加载提示。 |
| 200 | OK | 请求成功。 |
| 201 | Created | 资源已成功创建。 |
| 202 | Accepted | 请求已接受,但处理尚未完成。 |
| 203 | Non-Authoritative Information | 返回的元信息来自副本而非源服务器。 |
| 204 | No Content | 请求成功,但无响应体。 |
| 205 | Reset Content | 请求成功,客户端应重置文档视图。 |
| 206 | Partial Content | 已返回部分内容(Range 请求)。 |
| 207 | Multi-Status | 为多个子请求返回多种状态(WebDAV)。 |
| 208 | Already Reported | 绑定成员已枚举,不再重复(WebDAV)。 |
| 226 | IM Used | 响应为实例操作的结果(Delta 编码)。 |
| 300 | Multiple Choices | 存在多个可选资源表述。 |
| 301 | Moved Permanently | 资源已永久移动到新地址。 |
| 302 | Found | 资源临时位于另一地址。 |
| 303 | See Other | 使用 GET 从另一地址获取资源。 |
| 304 | Not Modified | 资源未修改,可使用缓存。 |
| 305 | Use Proxy | 必须通过代理访问资源(已弃用)。 |
| 307 | Temporary Redirect | 临时重定向,保持原请求方法。 |
| 308 | Permanent Redirect | 永久重定向,保持原请求方法。 |
| 400 | Bad Request | 请求语法错误,服务器无法理解。 |
| 401 | Unauthorized | 需要身份认证或认证失败。 |
| 402 | Payment Required | 保留状态码,预留给付费场景。 |
| 403 | Forbidden | 已认证但无权限访问。 |
| 404 | Not Found | 未找到请求的资源。 |
| 405 | Method Not Allowed | 该资源不支持此请求方法。 |
| 406 | Not Acceptable | 没有符合 Accept 头的表述。 |
| 407 | Proxy Authentication Required | 需要先通过代理认证。 |
| 408 | Request Timeout | 服务器等待请求超时。 |
| 409 | Conflict | 请求与资源当前状态冲突。 |
| 410 | Gone | 资源已被永久删除。 |
| 411 | Length Required | 需提供 Content-Length 头。 |
| 412 | Precondition Failed | 请求的前置条件未满足。 |
| 413 | Payload Too Large | 请求体过大。 |
| 414 | URI Too Long | 请求 URI 过长。 |
| 415 | Unsupported Media Type | 不支持的媒体类型。 |
| 416 | Range Not Satisfiable | 请求的 Range 范围无法满足。 |
| 417 | Expectation Failed | 无法满足 Expect 头的期望。 |
| 418 | I'm a teapot | 玩笑状态码(RFC 2324,愚人节)。 |
| 421 | Misdirected Request | 请求被发往无法响应的服务器。 |
| 422 | Unprocessable Entity | 请求语义有误,无法处理(校验失败)。 |
| 423 | Locked | 资源被锁定(WebDAV)。 |
| 424 | Failed Dependency | 因依赖的请求失败而失败(WebDAV)。 |
| 425 | Too Early | 服务器不愿处理可能被重放的请求。 |
| 426 | Upgrade Required | 客户端需升级到其它协议。 |
| 428 | Precondition Required | 要求请求附带前置条件。 |
| 429 | Too Many Requests | 请求过于频繁,触发限流。 |
| 431 | Request Header Fields Too Large | 请求头字段过大。 |
| 451 | Unavailable For Legal Reasons | 因法律原因不可用。 |
| 500 | Internal Server Error | 服务器内部错误。 |
| 501 | Not Implemented | 服务器不支持该功能。 |
| 502 | Bad Gateway | 网关从上游收到无效响应。 |
| 503 | Service Unavailable | 服务暂不可用(过载或维护)。 |
| 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 | 需通过网络认证才能访问。 |
使用说明
用途
HTTP 状态码速查工具,列出 1xx / 2xx / 3xx / 4xx / 5xx 全部状态码(100 Continue ... 511 Network Authentication Required),含官方含义、使用场景、何时返回、客户端如何处理。同时区分常用与冷门状态码、RESTful API 推荐用法、与浏览器行为关系。常用于 API 设计参考、排查接口报错、面试复习、HTTP 协议学习。所有数据本地存储无需联网。
操作步骤
- 左侧输入状态码(如 200 / 404)或按类目浏览
- 右侧显示官方定义 + 含义 + 何时返回
- 常用度标注:超高频(200 / 404 / 500)/ 常用(401 / 403 / 502)/ 冷门(418 / 451)
- RESTful 推荐用法:每个动词(GET / POST / PUT / DELETE)应该返回哪些状态码
- 客户端处理建议:前端遇到这个码应该怎么处理
- 相关 RFC 标准:RFC 7231 / 9110 等的引用
- 相似状态码对比:401 vs 403 / 301 vs 302 / 502 vs 504
- 一键复制状态码 + 描述
常见问题
- 401 和 403 有什么区别?
- **401 Unauthorized**: **没登录或登录已失效**。客户端应该:跳转登录页,重新获取 token。**403 Forbidden**: **登录了但没权限**。客户端应该:显示"无权限"提示,不能通过重新登录解决。**实际命名误导**:401 应该叫 "Unauthenticated"(未认证),403 才是 Unauthorized(未授权)。
- 301 和 302 哪个用于永久跳转?
- **301 Moved Permanently**: 永久重定向,**浏览器会缓存**新地址(下次直接访问新地址不再走旧地址)。**302 Found**: 临时重定向,每次都走旧地址再跳新地址。**SEO 影响**: 301 把旧 URL 的 SEO 权重传递给新 URL,302 不传。**何时用**:301 用于域名换了 / 永久搬家;302 用于 A/B 测试 / 临时维护页。
- 502 和 504 区别?
- **502 Bad Gateway**: 上游服务器返回了无效响应(如服务挂了 / 协议错误)。Nginx 后面的 PHP-FPM 挂了就 502。**504 Gateway Timeout**: 上游服务器超时未返回。**实际**: 502 通常是上游进程问题(重启服务),504 是上游慢(看慢查询 / 网络)。
- POST 创建资源应该返回 200 还是 201?
- **RESTful 推荐 201 Created**(明确表达"创建成功"),同时返回 Location 头指向新资源 URI。**返回 200** 也常见("成功但不强调创建"语义),多数 API 也接受。**完全 RESTful 项目用 201**,业务为主项目 200 / 201 都行(保持团队一致即可)。
- 为什么有的 API 全返 200,错误信息放在 body?
- **这种是反 RESTful 设计**(前端要解析 body 才知道是不是错)。**支持理由**: 1) 浏览器对 4xx/5xx 的处理特殊(部分场景不进 success 回调);2) 国内移动端历史习惯;3) 错误码丰富,HTTP 状态码不够用。**RESTful 反对**: HTTP 状态码就是为表达成功 / 失败设计的,应该用上。**实际**: 看团队 / 业务,没绝对对错。但 RESTful 设计的项目接入第三方更顺畅。
应用场景
- API 设计:决定接口失败时返回哪个状态码
- 排查接口报错:API 返回 5xx 看是什么含义
- 前端错误处理:根据状态码决定提示用户什么
- 面试复习:HTTP 协议常考状态码
- 教学:给新人讲 HTTP 状态码区别
适用场景
API 设计、接口排查、前端错误处理、面试复习、HTTP 教学。后端、前端、QA、技术支持、面试者常用。常用度标注、RESTful 推荐、相似码对比、客户端处理建议是关键差异点。