HTTP 状态码速查参考

全量收录 1xx 至 5xx HTTP 响应状态码标准规范。支持毫秒级中英文全文检索,深度解析协议语义、高频诱发原因、服务端排障修复建议与标准响应报文,助力 API 架构与网络排障。

65 / 65 个状态码
快捷筛选:
404

未找到资源(Not Found)

客户端错误支持缓存

服务器无法在请求 URI 下定位到任何目标资源,路径可能错误或资源已不存在。

•
支持缓存:是
•
定位锚点:

协议语义说明

Web 开发中最著名、最高频的状态码。表明服务器无法在请求的端点地址检索到相匹配的页面或实体。在 REST API 中常用于指示在数据库中根据特定 ID 未查询到对应的业务数据。

高频触发场景

  • 客户端请求的 URL 路径拼写错误、路径参数遗漏或大小写不匹配。
  • 目标资源已被删除或暂时处于不可访问状态。
  • API 路由定义缺失或网关反向代理路由规则配置错误。

排障与解决建议

  • 检查并校对请求 URL 的拼写、路径层级与 Query 查询参数。
  • 确认数据库中是否存在对应 ID 的实体记录。
  • 若资源是永久有意删除且无跳转地址,建议使用 410 Gone 以指示搜索引擎立即移除收录。

典型 HTTP 响应报文示例

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "Not Found",
  "message": "Resource '/api/v1/orders/987123' does not exist"
}
关联状态码:

HTTP 状态码速查与排障指南

  • 使用顶部搜索框,支持按状态码数字(如 404、500)、中英文技术关键词(如 鉴权、网关超时、跨域)进行实时过滤。
  • 切换类别选项卡(1xx、2xx、3xx、4xx、5xx),快速收敛特定语义区间的响应码集合。
  • 点击快捷筛选标签,一键聚焦常用高频状态码、支持缓存的响应或服务端与客户端错误。
  • 点击任意状态码卡片展开详情,查阅 RFC 官方规范、核心语义、高频诱发诱因、排障解决建议及真实 HTTP 报文。
  • 利用内置快捷复制功能,一键提取状态码标准定义、响应报文模板或可直接分享的页面定位锚点链接。

HTTP 状态码分类全景速览

分类代码类别名称核心语义与设计目的典型客户端处理策略高频代表状态码
1xx信息响应 (Informational)临时过渡状态,表示服务端已收到初始请求且正在处理,客户端应继续发送主体或协议切换。继续推流发送请求头/请求体数据,或协商升级传输协议。100, 101, 103
2xx成功响应 (Success)客户端请求已成功被服务端接收、理解并接受执行,业务操作按预期顺利达成。解析响应正文数据,或确认后端业务逻辑已持久化写入完成。200, 201, 204, 206
3xx重定向 (Redirection)客户端需执行进一步重定向跳转以完成请求,通常需跟进 Location 头或读取本地缓存。向 Location 标头中指定的 URI 发起重定向跳转,或复用本地缓存。301, 302, 304, 307, 308
4xx客户端错误 (Client Error)请求报文包含语法格式错误、身份未认证、权限不足或目标资源在服务端不存在。修复请求载荷语法、补充合法鉴权 Token 或依据限流规则执行退避。400, 401, 403, 404, 422, 429
5xx服务端错误 (Server Error)服务端在尝试处理合法请求时发生内部异常崩溃、超时或依赖不可用,无法生成响应。结合退避算法(Backoff)适度重试,或向后台监控运维系统报警排查。500, 502, 503, 504

核心 HTTP 状态码关键差异深度对比

401 Unauthorized vs 403 Forbidden(身份未认证 vs 资源权限不足)

401 Unauthorized:身份认证失败。客户端缺少有效凭证(缺少或失效的 Bearer Token、无效的 API Key)。重新附带合法凭据登录或刷新 Token 即可恢复正常访问。

403 Forbidden:访问授权失败。服务端已知晓并确认客户端身份,但根据权限规则(RBAC 角色不足、IP 访问控制名单、租户隔离),拒绝向该用户授权访问。即使使用相同身份反复重试也不会成功。

301 / 302 vs 307 / 308(重定向跳转与 HTTP 请求方法保持)

301 / 302(历史兼容):传统重定向模式。历史浏览器在遭遇 301(永久)或 302(临时)时,常常擅自将原始 POST 请求的方法篡改成 GET。

307 / 308(RFC 9110 现代规范):方法强保真重定向。307(临时)与 308(永久)强制要求客户端必须严格保留原始 HTTP 请求方法(POST 依旧为 POST),并完整重新提交原请求体。

500 vs 502 vs 503 vs 504(服务端应用崩溃 vs 反向代理网关故障诊断)

500 Internal Server Error:应用代码自身抛出未捕获的运行时异常(空指针、类型转换异常、数据库宕机崩溃)。

502 Bad Gateway:反向代理(Nginx / Cloudflare)无法与上游后端建立有效连接,上游进程未监听或直接拒绝连接。

503 Service Unavailable:服务器处于临时维护窗口期或因并发激增触发限流熔断,搜索引擎会根据 Retry-After 推迟抓取而不扣减权重。

504 Gateway Timeout:反向代理成功连通上游应用,但上游处理业务(如慢查询、复杂计算)耗时超过了 proxy_read_timeout 阈值。

400 Bad Request vs 422 Unprocessable Content(请求语法错误 vs 业务语义校验失败)

400 Bad Request:请求报文存在底层语法错误。如 JSON 语法损坏(缺少引号、多余逗号)、Query 参数编码混乱、或缺少必需的协议请求头。

422 Unprocessable Content:报文语法完全合法(JSON 格式完全正确),但字段内容违反了业务逻辑规则(如邮箱格式不合规、数值超出合法区间、关联 ID 不存在)。

RESTful API 状态码工程设计规范矩阵

HTTP 请求方法CRUD 操作语义是否幂等 (Idempotent)是否安全 (Safe)标准推荐成功状态码标准常见错误状态码
GET读取 / 查询资源是 (Yes)是 (Yes)200 OK, 206 Partial404, 401, 403, 304
POST创建资源 / 执行动作否 (No)否 (No)201 Created, 202 Accepted400, 422, 409, 415
PUT全量替换 / 幂等覆写是 (Yes)否 (No)200 OK, 204 No Content400, 404, 412, 428
PATCH增量部分更新否 (No)否 (No)200 OK, 204 No Content400, 404, 422, 409
DELETE删除 / 移除实体是 (Yes)否 (No)204 No Content, 202 Accepted404, 401, 403
HEAD仅获取响应头 (无正文)是 (Yes)是 (Yes)200 OK (无响应正文)404, 304
OPTIONS跨域探测 / 能力协商是 (Yes)是 (Yes)204 No Content, 200 OK405 Method Not Allowed

Frequently Asked Questions

什么是 HTTP 状态码?其划分的五大类别分别代表什么含义?

HTTP 状态码是由服务器在响应客户端请求时下发的 3 位十进制数字代码,遵循 IETF RFC 9110 标准规范。状态码的首位数字明确划定了 5 种不同语义的响应类别:1xx 信息响应(Informational,请求已接收,仍在继续处理);2xx 成功响应(Success,操作已被服务器成功接收、理解并接受);3xx 重定向(Redirection,需客户端采取进一步跳转动作方可完成请求);4xx 客户端错误(Client Error,请求报文包含语法格式错误或无法被满足);5xx 服务端错误(Server Error,服务器在处理看似合法的请求时发生内部故障)。

401 Unauthorized 与 403 Forbidden 之间最本质的架构区别是什么?

两者的核心边界在于“身份认证(Authentication)”与“授权鉴权(Authorization)”的区别。401 Unauthorized 表示客户端未提供有效身份凭证(如缺少 Authorization 标头、Token 失效或 API Key 错误),客户端附带合法凭据重新发起认证即可解决问题;而 403 Forbidden 表示服务器已确切识别客户端身份,但根据安全策略与 RBAC 权限控制规则,该身份不具备访问受保护资源的权限(如普通成员尝试调用管理员专属接口),使用相同账号重复登录重试仍会被拒绝。

301、302、307 与 308 重定向在 SEO 权重传递与 HTTP 请求方法保持上有何不同?

从 SEO 权重传递角度:301(Moved Permanently)与 308(Permanent Redirect)属于永久性重定向,搜索引擎爬虫会将原 URL 的权重(PageRank)完整迁移至新地址;302(Found)与 307(Temporary Redirect)属于临时重定向,不会转移 SEO 权重。从 HTTP 请求方法保持角度:历史浏览器实现中,客户端在收到 301 或 302 重定向时经常将原始 POST 请求错误篡改为 GET。为彻底杜绝方法篡改行为,RFC 9110 规范引入了 307(临时)与 308(永久),严格强制客户端重定向后必须保留原始请求方法与请求体(即 POST 必须保持 POST)。

500、502、503 与 504 服务端错误在网络链路排障时如何定位?

500 Internal Server Error 属于应用层异常,通常是业务代码内部未捕获的异常崩溃、空指针或数据库连接崩溃;502 Bad Gateway 属于网关反向代理层故障,表明 Nginx/Cloudflare/ALB 尝试连接上游应用容器时,遭遇了连接拒绝(Connection Refused)或上游进程崩溃退出;503 Service Unavailable 表示服务暂时超载或正在停机维护,通常为熔断限流保护机制触发,常附带 Retry-After 标头;504 Gateway Timeout 表示反向代理与上游成功连通,但上游处理时间超出了代理配置的读取超时阈值(如执行了耗时过长的慢 SQL 查询)。

API 接口设计中,何时应该返回 400 Bad Request,何时该返回 422 Unprocessable Content?

当请求报文存在底层语法错误导致服务端无法正确反序列化时(如 JSON 缺少闭合括号、多余逗号、非法字符编码或缺少必需的协议标头),应返回 400 Bad Request。当请求体语法格式完全合法(如 JSON 结构规整),但字段内容未能通过业务逻辑语义校验时(如邮箱不符合正则、年龄为负数、或关联的外键 ID 在数据库中不存在),根据 RFC 9110 §15.5.21 标准规范,应精准返回 422 Unprocessable Content。

对于搜索引擎 SEO 与 API 开发,404 Not Found 与 410 Gone 有何显著差异?

404 Not Found 仅表明当前 URI 未匹配到资源,搜索引擎会假设该失效可能是暂时性或意外故障,因此爬虫未来仍会多次回访重试抓取;而 410 Gone 明确宣称“该资源曾存在但已被有意且永久下线,未来也不会提供任何跳转地址”。Googlebot、BaiduSpider 等主流搜索引擎爬虫在收到 410 后,会立即将该 URL 从搜索索引中彻底清除并停止后续抓取,有助于保护宝贵的整站抓取预算(Crawl Budget)。

RESTful API 在执行 POST、PUT、PATCH 与 DELETE 操作时推荐返回哪些状态码?

POST(新建资源):推荐返回 201 Created 并附带指向新资源的 Location 标头;若加入异步队列处理则返回 202 Accepted。PUT 与 PATCH(更新资源):若返回最新数据表征则返回 200 OK;若无需返回响应体则返回 204 No Content。DELETE(删除资源):执行成功且无响应体时返回 204 No Content;若调度异步删除则返回 202 Accepted。当任意写请求遭遇数据校验失败时,统一返回 422 Unprocessable Content 并附带字段错误明细。

API 服务端实现 429 Too Many Requests 限流策略时有哪些最佳实践?

当客户端调用频次突破速率限制阈值时,服务端应返回 429 Too Many Requests(RFC 6585),并在响应头中附带 "Retry-After" 标头(标明需等待的秒数或恢复访问的 GMT 时间戳)。业界成熟的开放 API 还会同步提供 "X-RateLimit-Limit"(配额上限)、"X-RateLimit-Remaining"(剩余配额)以及 "X-RateLimit-Reset"(配额重置时间戳)标头,帮助客户端在触发熔断前提前自适应调节并发请求速率。

哪些 HTTP 状态码在默认情况下允许被浏览器和 CDN 边缘节点缓存?

依据 RFC 9110 与 RFC 9111 HTTP 缓存规范,状态码 200 (OK)、203 (Non-Authoritative Information)、204 (No Content)、206 (Partial Content)、300 (Multiple Choices)、301 (Moved Permanently)、404 (Not Found)、405 (Method Not Allowed)、410 (Gone)、414 (URI Too Long) 以及 501 (Not Implemented) 在未显式声明禁止缓存的情况下,默认均允许被客户端和代理缓存,除非响应中被 Cache-Control: no-store / private 等指令覆盖。

现代 HTTP API 在返回 4xx 与 5xx 错误时,业界推荐采用何种标准响应格式?

IETF RFC 9457(前身为 RFC 7807)正式确立了 "Problem Details for HTTP APIs" 标准规范(Content-Type: application/problem+json)。与各团队随意的自定义错误格式不同,合规 API 统一使用规范约定的 5 个标准字段:type(指示错误类别的 URI)、title(简短的错误类型可读摘要)、status(对应的 HTTP 状态码数值)、detail(针对当前具体出错实例的详细解释)以及 instance(标识本次错误事件的唯一 URI 跟踪标识)。