線上報錯，先判斷該找誰
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 私有