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