线上报错，先判断该找谁
502 / 503 / 504 对照表告诉你是应用挂了、被摘流量了还是太慢了；Cloudflare 52x 卡片直接给出「查源站防火墙 / 证书 / 超时」的方向。
加载中…
使用指南
HTTP 状态码全表收录 72 个状态码：RFC 9110 定义的全部标准码（100–101、200–206、300–308、400–418、421、422、426、500–505），RFC 6585 / 7725 / 8297 / 8470 与 WebDAV 系列 RFC 定义的扩展码（103、207、208、226、423–425、428、429、431、451、506–511），以及虽不在任何 RFC 里、但排查线上问题时天天见的非标准码——nginx 的 444 与 499，Cloudflare 的 520–526。
更新于 2026-09-094 个来源约 8 分钟读完
HTTP 状态码全表收录 72 个状态码：RFC 9110 定义的全部标准码（100–101、200–206、300–308、400–418、421、422、426、500–505），RFC 6585 / 7725 / 8297 / 8470 与 WebDAV 系列 RFC 定义的扩展码（103、207、208、226、423–425、428、429、431、451、506–511），以及虽不在任何 RFC 里、但排查线上问题时天天见的非标准码——nginx 的 444 与 499，Cloudflare 的 520–526。
与只给「含义」的状态码表不同，这里每个码都分四段写：它的语义是什么；什么情况下你会看到它；前端 / 客户端拿到它该做什么（重试？跳登录？读哪个响应头？）；后端在什么时候应该返回它、返回时要带什么头。高频码另加一段「常见误用」，因为线上大多数状态码问题不是不认识，而是用错——业务失败返回 200、未登录返回 403、限流返回 503。
页首还有七组「易混淆对照」：401 vs 403、301/302/307/308、400 vs 422、404 vs 410、502/503/504、200/201/202/204、429 vs 503。这些是面试、代码评审和排障时最常被问到的组合。
502），精确匹配的那一张卡会置顶显示。搜「429」得到的卡片内容（节选）：
对应的后端响应长这样：
429 Too Many Requests 请求过多 RFC 6585
语义 在给定时间内发了太多请求（限流）。
何时 接口频率限制、登录尝试过多、爬虫被限速、AI API 超出每分钟配额。
前端 读 Retry-After 头（秒数或日期）后指数退避重试；给用户「稍后再试」提示；不要立刻重试。
后端 带 Retry-After 与 RateLimit-* 头；按用户 / IP / API key 计数。
误用 限流返回 403 或 503，客户端无法区分是权限问题还是该等一会。HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"每分钟最多 60 次请求，请 30 秒后重试"}状态码第一位数字决定类别，这是刻意的：即使客户端不认识某个具体的码（比如新的 425），也能按类别正确处理——4xx 一律「别原样重试，问题在请求」，5xx 一律「可以稍后重试」，3xx 一律「看 Location」。RFC 9110 明确要求客户端必须理解类别语义、可以不理解具体码。这也是为什么自定义状态码要落在正确的百位区间里。
历史命名失误。HTTP 早期没有区分 authentication（你是谁）与 authorization（你能做什么），401 被命名为 Unauthorized，但配套的 WWW-Authenticate 头和「重新提供凭证后可能成功」的语义都在说「认证」。RFC 9110 在 §15.5.2 里的措辞已改为 "lacks valid authentication credentials"。记住一句话：401 = 请登录，403 = 登录了也不行。前端据此决定是跳登录页还是显示「无权限」，用反了就会出现「已登录却被反复踢回登录页」。
四个常用重定向码其实是 2×2 矩阵。301 与 308 是永久（浏览器和搜索引擎会记住新地址），302 与 307 是临时。历史上浏览器处理 301/302 时会把 POST 改成 GET，RFC 9110 承认了这一现实，并用 307/308 提供「必须保持方法与请求体」的严格版本。给网页做 https 跳转用 301 没问题；给 API 端点做迁移，POST 请求就必须用 307/308，否则请求体会丢。
304 常被误认为「省了一次请求」。实际上浏览器仍向服务器发了带 If-None-Match / If-Modified-Since 的条件请求，服务器比较后回 304 且不带响应体——省的是传输，不是往返。真正省请求靠 Cache-Control: max-age（在有效期内浏览器根本不问服务器），两者配合：max-age 期内直接用，过期后条件请求拿 304 续期。DevTools 里显示 "200 (from disk cache)" 是前者、"304" 是后者。
线上最常见的 5xx 组合，区分它们能直接缩小排查范围。反向代理（Nginx、网关、CDN）连不上上游或上游回了不合法的东西——502，去看应用进程是不是挂了；上游明确表示忙或维护——503，通常是主动返回的，看健康检查与熔断；上游迟迟不回——504，看慢查询与超时配置。Cloudflare 把这三种情况细分成 520–526，其中 521 ≈ 502（连接被拒）、522/524 ≈ 504（连接 / 读取超时）、525/526 是 TLS 层问题。
最常见的反模式是所有请求都返回 200、错误放在响应体的 code 字段里。它让 CDN 缓存错误页、让监控系统的 5xx 告警失效、让浏览器 fetch().ok 失去意义、让重试策略无从下手。正确做法是 HTTP 状态码表达「请求层面发生了什么」（RFC 9110 的语义），响应体的业务码表达「业务层面的细节」，两者分工而不是互相替代：库存不足是 422 + {"code":"OUT_OF_STOCK"}，不是 200 + {"code":500}。
502 / 503 / 504 对照表告诉你是应用挂了、被摘流量了还是太慢了；Cloudflare 52x 卡片直接给出「查源站防火墙 / 证书 / 超时」的方向。
按卡片里的「前端 / 客户端」栏写拦截器：401 刷 token 或跳登录，403 提示无权限，429 读 Retry-After 退避，5xx 有限重试并上报。
创建资源是不是返回了 201 + Location？删除是不是 204？业务校验失败是 400 还是 422？限流有没有带 Retry-After？「后端」栏和「常见误用」栏就是评审清单。
七组对照表覆盖了最常见的「区别」类问题；「原理与背景」解释了 401 命名、307/308 出现的原因、304 的真实作用。
网站的入口服务器（网关）连不上真正处理请求的后端，通常是后端进程崩了或正在重启。用户端只能稍后刷新；如果是你自己的站点，去看后端进程和网关的错误日志。
客户端：读 Retry-After 头，等够时间再重试，多次失败就指数退避（1s、2s、4s…），并告诉用户「操作太频繁」。服务端：返回 429 时一定要带 Retry-After，最好再带 RateLimit-* 头让客户端能提前减速。
看请求的对象。GET /users/123 而 123 不存在——404；GET /users?name=xxx 结果为空——200 + 空数组。列表接口的空结果是合法的「有结果，结果是空」，不是错误。
204 没有响应体，json() 解析空字符串会抛 SyntaxError。先判断 response.status === 204（或 response.headers.get('content-length') === '0'）再决定是否解析。
它们是 nginx 写进访问日志用的内部码：444 表示 nginx 直接关连接没回任何响应，499 表示客户端在 nginx 回响应前就断开了。浏览器端看到的是「连接被重置」或根本没收到响应。
状态码数据随页面静态下载，搜索、筛选、复制、收藏都在浏览器本地完成，不发送任何请求。收藏保存在本机 localStorage。外链指向 RFC Editor、IANA 与 Cloudflare 文档，点击后由对方站点处理。
更新于 2026-09-09
RFC 9110 全部状态码 + 扩展码 + nginx/Cloudflare 非标准码共 72 个，每码含语义、出现场景、前端与后端各自的处理方式、常见误用；含 7 组易混淆对照；可搜索、复制、收藏
请求已收到，继续处理；浏览器几乎不会把它暴露给页面脚本。
请求头已收到，客户端可以继续发送请求体。
RFC 9110 §15.2.1
服务器同意按 Upgrade 头切换到另一个协议。
RFC 9110 §15.2.2
服务器已收到并在处理请求，但尚无最终响应。
RFC 2518（WebDAV，已废弃）
在最终响应之前先发一部分头（主要是 Link: preload），让浏览器提前加载资源。
RFC 8297
请求被成功接收、理解并处理。
请求成功，响应体里是请求的资源或操作结果。
RFC 9110 §15.3.1
请求成功且创建了新资源。
RFC 9110 §15.3.2
请求已接受但尚未处理完，是异步任务的回执。
RFC 9110 §15.3.3
响应成功，但内容被中间代理修改过。
RFC 9110 §15.3.4
成功，但没有响应体。
RFC 9110 §15.3.5
成功，且要求客户端重置「文档视图」（如清空表单）。
RFC 9110 §15.3.6
返回的是资源的一部分（Range 请求成功）。
RFC 9110 §15.3.7
响应体是 XML，里面每个子资源各有自己的状态码。
RFC 4918（WebDAV）
207 响应里，同一个资源已在前面报告过，不再重复。
RFC 5842（WebDAV）
服务器对当前实例应用了「实例操作」（增量编码）返回差异。
RFC 3229
需要客户端进一步动作（通常是换个地址再请求）才能完成。
资源有多个表示，请客户端选一个。
RFC 9110 §15.4.1
资源永久搬到 Location 指向的新地址，以后都用新地址。
RFC 9110 §15.4.2
资源暂时在别处，下次仍请求原地址。
RFC 9110 §15.4.3
请用 GET 去 Location 看结果（与当前请求方法无关）。
RFC 9110 §15.4.4
资源没变，用你缓存里的那份。
RFC 9110 §15.4.5
必须通过 Location 指定的代理访问。
RFC 9110 §15.4.6（已弃用）
曾在草案中表示「切换代理」，现已保留不用。
RFC 9110 §15.4.7
临时跳转，且客户端必须用**同样的方法和请求体**重发。
RFC 9110 §15.4.8
永久跳转，且保持方法与请求体（301 的严格版）。
RFC 9110 §15.4.9
请求本身有问题：语法、鉴权、资源不存在、频率过高……重试同样的请求不会成功。
服务器无法理解请求：语法错、参数缺失/格式错、JSON 解析失败。
RFC 9110 §15.5.1
缺少或无效的身份凭证——「你是谁？」（名字叫 Unauthorized，实际含义是 Unauthenticated）。
RFC 9110 §15.5.2
为将来的数字支付保留，规范未定义具体语义。
RFC 9110 §15.5.3（保留）
服务器知道你是谁，但你没有权限——「你不能」。重新认证也没用。
RFC 9110 §15.5.4
服务器找不到请求的资源，且不说明是临时还是永久。
RFC 9110 §15.5.5
资源存在，但不支持这个 HTTP 方法。
RFC 9110 §15.5.6
服务器没有能满足 Accept / Accept-Language 等要求的表示。
RFC 9110 §15.5.7
需要先向代理服务器认证（401 的代理版）。
RFC 9110 §15.5.8
服务器等请求等太久（客户端迟迟没发完）。
RFC 9110 §15.5.9
请求与资源当前状态冲突，用户可能通过修改请求解决。
RFC 9110 §15.5.10
资源曾经存在，现在永久移除，且没有转发地址。
RFC 9110 §15.5.11
服务器要求请求带 Content-Length。
RFC 9110 §15.5.12
请求头里的条件（If-Match、If-Unmodified-Since）不满足。
RFC 9110 §15.5.13
请求体超过服务器允许的大小。
RFC 9110 §15.5.14（旧名 Payload Too Large）
URL 太长服务器拒绝处理。
RFC 9110 §15.5.15
请求体的格式（Content-Type）服务器不支持。
RFC 9110 §15.5.16
Range 头请求的字节范围超出资源大小。
RFC 9110 §15.5.17
无法满足 Expect 头的要求。
RFC 9110 §15.5.18
1998 年愚人节 RFC 的玩笑，不应在真实 HTTP 里使用。
RFC 2324（愚人节 RFC）；RFC 9110 标记为未使用
请求发到了无法为该 authority（域名）提供响应的服务器。
RFC 9110 §15.5.20
请求语法正确、格式也对，但语义上无法处理（业务校验失败）。
RFC 9110 §15.5.21（旧名 Unprocessable Entity）
资源被锁定。
RFC 4918（WebDAV）
因为前一个依赖操作失败，本操作也失败。
RFC 4918（WebDAV）
服务器不愿处理可能被重放的请求（TLS 1.3 0-RTT 早期数据）。
RFC 8470
服务器拒绝在当前协议上处理，要求切换到 Upgrade 头指定的协议。
RFC 9110 §15.5.22
服务器要求请求必须带条件头（如 If-Match），防止「丢失更新」。
RFC 6585
在给定时间内发了太多请求（限流）。
RFC 6585
请求头（总和或单个）太大。
RFC 6585
因法律要求（版权、政府命令）拒绝提供资源。编号致敬《华氏 451》。
RFC 7725
服务器知道自己出错或无法完成合法请求；稍后重试可能成功。
服务器遇到了意料之外的情况，无法完成请求。
RFC 9110 §15.6.1
服务器不支持完成请求所需的功能（通常是不认识的方法）。
RFC 9110 §15.6.2
作为网关/代理的服务器从上游收到了无效响应。
RFC 9110 §15.6.3
服务器暂时无法处理（过载或维护），通常是临时的。
RFC 9110 §15.6.4
网关/代理等上游响应超时。
RFC 9110 §15.6.5
服务器不支持请求使用的 HTTP 主版本。
RFC 9110 §15.6.6
内容协商配置错误导致循环。
RFC 2295
服务器无法存储完成请求所需的内容。
RFC 4918（WebDAV）
处理请求时检测到无限循环。
RFC 5842（WebDAV）
请求需要进一步扩展才能被处理。
RFC 2774（历史）
客户端需要先通过网络层认证（强制门户）才能上网。
RFC 6585
不在任何 RFC 里，只出现在特定服务器的日志或 CDN 的错误页；知道它们能省很多排查时间。
Nginx 直接关闭连接、不发任何响应；只出现在 Nginx 日志里。
nginx 私有
服务器还没响应，客户端就断开了；只出现在 Nginx 日志。
nginx 私有
源站给 Cloudflare 的响应是空的、格式不对或超出头大小限制。
Cloudflare 私有
Cloudflare 连不上源站（TCP 连接被拒）。
Cloudflare 私有
Cloudflare 向源站发起 TCP 连接超时。
Cloudflare 私有
Cloudflare 无法路由到源站（DNS 或网络路由问题）。
Cloudflare 私有
TCP 已连上，但源站在 100 秒内没有返回 HTTP 响应。
Cloudflare 私有
Cloudflare 与源站的 TLS 握手失败。
Cloudflare 私有
Full (strict) 模式下源站证书过期、自签或域名不匹配。
Cloudflare 私有