LibraTool logoLibraTool

免費HTTP 狀態碼參考

可搜尋的完整 HTTP 狀態碼參考——每個狀態碼的含義、使用場景和常見原因。從 100 到 511。

載入後可離線使用

61 個狀態碼

100

繼續

伺服器已接收請求頭,客戶端應繼續傳送正文。

用於 Expect: 100-continue 請求。伺服器確認願意在客戶端傳送正文前接收。在現代網路應用中很少見。

RFC 9110 ↗
101

切換協議

伺服器正在按客戶端要求切換協議。

最常用於 WebSocket 升級 — 客戶端請求 Upgrade: websocket,伺服器回應 101 進行切換。

RFC 9110 ↗
102

處理中

伺服器已接收請求並正在處理,但尚無回應可用。

WebDAV 中間回應,用於在冗長操作期間防止客戶端超時。已棄用 — 現代伺服器不應傳送。

RFC 2518 ↗
103

早期提示

在最終回應前傳送的初步頭。

讓伺服器在準備最終回應期間傳送連結頭 (預載入/預連線),以便瀏覽器可以更快地開始取得關鍵資源。

RFC 8297 ↗
200

OK

請求成功。

標準成功回應。具體含義取決於 HTTP 方法:GET → 返回資源,POST/PUT → 操作完成。

RFC 9110 ↗
201

已建立

新資源已成功建立。

常見於 POST 後。回應應包含指向新資源 URL 的 Location 頭。

RFC 9110 ↗
202

已接受

請求已被接受以進行處理,但處理尚未完成。

用於非同步操作 — 伺服器正在排隊處理。客戶端應輪詢狀態端點或稍後重新檢查。

RFC 9110 ↗
203

非權威資訊

回應被轉換代理修改。

請求成功,但中介 (如快取或轉換代理) 改變了來自原始伺服器的有效負載 — 例如重新壓縮圖片。在實踐中很少見。

RFC 9110 ↗
204

無內容

請求成功但沒有回應正文。

通常用於 DELETE 操作或不需要返回正文的 PUT 更新。客戶端不應離開當前頁面。

RFC 9110 ↗
205

重設內容

請求成功;客戶端應重設文件檢視。

類似於 204,不返回正文 — 但另外告知客戶端重設產生請求的表單或檢視 (例如清空表單欄位以供下一條輸入)。

RFC 9110 ↗
206

部分內容

伺服器僅交付了部分資源。

對 Range 請求的回應。由影片播放器和下載管理器使用,用於恢復中斷的下載或流式傳輸大檔案。

RFC 9110 ↗
207

多狀態

回應正文包含多個操作的多個狀態程式碼。

WebDAV:XML 正文獨立報告多個子操作的結果 — 例如批次移動,其中某些項成功,其他項失敗。

RFC 4918 ↗
208

已報告

集合的成員已在回應中更早列出。

WebDAV:在 207 多狀態回應內使用,以避免在繫結建立迴圈時重複列出同一集合的成員。

RFC 5842 ↗
226

已使用 IM

回應是應用於資源的例項操作的結果。

增量編碼:伺服器返回與以前版本的差異,而不是完整資源,節省頻寬。極少實現。

RFC 3229 ↗
300

多種選擇

資源的多個表示形式可用。

伺服器提供多個選項 (例如不同的格式或語言),客戶端應選擇一個。很少使用,因為自動內容協商通常處理這個。

RFC 9110 ↗
301

永久移動

資源已永久移動到新 URL。

用於永久 URL 更改 — 搜尋引擎將更新其索引。SEO 權重轉移到新 URL。

RFC 9110 ↗
302

已找到 (臨時重新導向)

資源暫時位於不同的 URL。

表示重新導向不是永久的。快取不如 301 那樣激進。用於諸如 '需要登入,重新導向到 /login' 之類的事情。

RFC 9110 ↗
303

檢視其他

使用 GET 重新導向到另一個 URL。

在 POST 提交後使用 — 回應表示 '您的 POST 成功了,請檢視此 GET URL 以取得結果'。瀏覽器始終 GET 新 URL。

RFC 9110 ↗
304

未修改

快取的版本仍然有效;使用它。

對條件請求 (帶有 If-None-Match 或 If-Modified-Since 頭) 的回應。節省頻寬 — 不返回正文。

RFC 9110 ↗
307

臨時重新導向

類似於 302 但保留原始 HTTP 方法。

如果原始請求是 POST,重新導向也使用 POST。當方法保留重要時,307 是 302 的現代替代方案。

RFC 9110 ↗
308

永久重新導向

類似於 301 但保留原始 HTTP 方法。

301 的現代替代方案,適用於希望 POST 請求在重新導向後仍保持為 POST 的情況。

RFC 9110 ↗
400

錯誤請求

伺服器由於語法錯誤而無法理解請求。

常見原因:正文中的 JSON 格式錯誤、無效的查詢引數或缺少必需欄位。檢查請求正文和頭。

RFC 9110 ↗
401

未授權

需要身份驗證但未提供。

客戶端必須包含身份驗證憑據 (Authorization 頭、Cookie、令牌)。'Unauthorized' 是用詞不當 — 它實際上意味著 '未認證'。

RFC 9110 ↗
402

需要付款

保留供將來使用 — 有時用於付費 API 層級。

最初用於數字支付。現代用法:當使用者超過其付費配額時,API 有時會返回 402。

RFC 9110 ↗
403

禁止

客戶端已認證但沒有權限。

與 401 不同 — 使用者已登入,但其帳戶沒有此資源的權限。檢查角色/權限邏輯。

RFC 9110 ↗
404

未找到

請求的資源不存在。

URL 錯誤、資源已刪除或從未存在。伺服器有時會返回 404 來隱藏 403 更準確的事實。

RFC 9110 ↗
405

方法不允許

此資源不允許使用的 HTTP 方法。

例如,對僅接受 POST 的端點的 GET 請求。回應應包含列出有效方法的 Allow 頭。

RFC 9110 ↗
406

不可接受

沒有表示形式與客戶端的 Accept 頭符合。

客戶端要求伺服器無法滿足的內容型別、語言或編碼 (透過 Accept、Accept-Language、Accept-Encoding)。許多伺服器跳過嚴格協商並返回預設值。

RFC 9110 ↗
407

需要代理身份驗證

客戶端必須首先透過代理進行身份驗證。

類似於 401,但由代理發出:客戶端必須傳送代理授權憑據。在具有身份驗證代理的企業網路上很常見。

RFC 9110 ↗
408

請求超時

伺服器等待請求超時。

客戶端傳送請求體用時過長或保持連線空閒狀態。請重試請求。

RFC 9110 ↗
409

衝突

請求與資源的當前狀態衝突。

通常返回於併發編輯衝突或重複資源建立(例如,使用已存在的電子郵件建立使用者)。

RFC 9110 ↗
410

已刪除

資源已被刪除且不會返回。

比 404 更強 — 伺服器明確知道資源曾經存在但已被永久刪除。搜尋引擎會將其從索引中移除。

RFC 9110 ↗
411

需要 Content-Length

伺服器要求 Content-Length 標頭。

請求被拒絕,因為缺少 Content-Length 標頭,伺服器拒絕接收大小未知的請求體。請新增標頭並重試。

RFC 9110 ↗
412

前置條件失敗

請求標頭中的條件未滿足。

在條件標頭(如 If-Match 或 If-Unmodified-Since)驗證失敗時返回 — 通常為樂觀鎖定:自你的版本以來,其他人更改了資源。請重新取得並重試。

RFC 9110 ↗
413

請求體過大

請求體超過伺服器大小限制。

上傳大檔案時常見。伺服器設定(nginx、apache)設定了最大請求體大小。請檢查伺服器設定。

RFC 9110 ↗
414

URL 過長

請求 URL 超過伺服器長度限制。

通常由非常長的查詢字串引起(例如在 GET 中編碼資料)。改用 POST 請求體,或者如果你可以控制伺服器,提高伺服器限制。

RFC 9110 ↗
415

不支援的媒體型別

伺服器無法處理傳送的 Content-Type。

例如,向僅接受 application/json 的伺服器傳送 application/xml。請正確設定 Content-Type 標頭。

RFC 9110 ↗
416

範圍不可滿足

請求的位元組範圍超出資源大小。

Range 標頭要求檔案不具有的部分 — 例如,恢復下載超過檔案末尾。回應應包含具有實際大小的 Content-Range。

RFC 9110 ↗
417

期望失敗

伺服器無法滿足 Expect 標頭的要求。

在伺服器不支援 Expect: 100-continue 時傳送。某些客戶端在大型 POST 上預設傳送此標頭;停用它通常會解決錯誤。

RFC 9110 ↗
418

我是茶壺

伺服器拒絕釀造咖啡,因為它是茶壺。

1998 年的愚人節笑話(RFC 2324)。某些真實 API 用它來開玩笑或標記已棄用的端點。不用於生產。

RFC 2324 ↗
421

請求方向錯誤

請求傳送到無法為其產生回應的伺服器。

常見於 HTTP/2 連線重用:請求到達未為目標主機名設定的伺服器。客戶端應在新連線上重試。

RFC 9110 ↗
422

無法處理的內容

請求在語法上有效但語義錯誤。

例如,JSON 解析正確但缺少必需欄位,或欄位值超出範圍。在 REST API 驗證回應中常見。

RFC 9110 ↗
423

已鎖定

資源被鎖定。

WebDAV:源或目標資源被另一個客戶端鎖定,因此操作無法進行。等待鎖釋放或使用正確的令牌中斷它。

RFC 4918 ↗
424

依賴失敗

請求失敗,因為先前的相關請求失敗。

WebDAV:在一系列相關操作中,較早的操作失敗,因此此操作未執行。檢視較早的失敗以找到根本原因。

RFC 4918 ↗
425

時間過早

伺服器拒絕處理可能被重放的請求。

與 TLS 1.3 0-RTT(早期資料)相關:伺服器將不會冒可能重放請求的風險。客戶端應在握手完成後重試。

RFC 8470 ↗
426

需要升級

客戶端必須切換到其他協議。

伺服器拒絕在當前協議上服務請求,但在升級後會 — 回應包含命名所需協議的 Upgrade 標頭。

RFC 9110 ↗
428

需要前置條件

伺服器要求請求是條件性的。

伺服器要求條件標頭(如 If-Match)以防止丟失更新衝突。取得資源、捕獲其 ETag,並使用 If-Match 重新傳送。

RFC 6585 ↗
429

請求過多

客戶端被速率限制。

放慢速度。回應應包含 Retry-After 標頭,指示何時重試。常見於具有請求配額的 API。

RFC 6585 ↗
431

請求標頭欄位過大

標頭對伺服器來說太大,無法處理。

單個標頭或總標頭大小超過限制 — 最常由過大的 cookies 引起。清除 cookies 或減少應用在其中儲存的內容。

RFC 6585 ↗
451

因法律原因不可用

因法律要求而拒絕存取。

資源因法律原因被阻止 — 審查、法庭命令或地區法規。這個數字是對小說《華氏 451 度》的致敬。

RFC 7725 ↗
500

內部伺服器錯誤

伺服器遇到意外條件。

伺服器端錯誤的通用包羅永珍。檢查伺服器日誌以找到實際原因:未處理的異常、資料庫錯誤等。

RFC 9110 ↗
501

未實現

伺服器不支援請求的功能。

例如,伺服器不識別 HTTP 方法。實際上很少見 — 更常見的是看到 405。

RFC 9110 ↗
502

閘道器錯誤

充當閘道器的伺服器從上游伺服器獲得了錯誤的回應。

在微服務架構中常見。你的負載均衡器或反向代理從後端服務獲得了格式錯誤的回應。

RFC 9110 ↗
503

服務不可用

伺服器暫時無法處理請求。

要麼正在維護,要麼過載。回應應包含 Retry-After 標頭。通常在部署期間返回。

RFC 9110 ↗
504

閘道器超時

閘道器伺服器等待上游回應超時。

後端服務回應速度不夠快。檢查上游服務健康狀況和超時設定。

RFC 9110 ↗
505

不支援的 HTTP 版本

伺服器不支援請求中使用的 HTTP 版本。

請求的 HTTP 主要版本不受伺服器支援。在現代客戶端中幾乎從不出現。

RFC 9110 ↗
506

變體也進行協商

伺服器具有內容協商設定錯誤。

透明內容協商陷入迴圈:所選變體本身設定為協商。表示伺服器設定錯誤。

RFC 2295 ↗
507

儲存空間不足

伺服器磁碟空間已滿。

WebDAV 特有,但有時由常規伺服器使用。意味著伺服器由於儲存限制而無法儲存請求。

RFC 4918 ↗
508

檢測到迴圈

伺服器在處理請求時檢測到無限迴圈。

WebDAV:處理 Depth: infinity 請求時進入迴圈(例如迴圈繫結)。操作已終止。

RFC 5842 ↗
510

未擴展

需要進一步的請求擴展。

來自已過時的 HTTP 擴充功能框架:伺服器在滿足請求之前需要更多資訊。實際上在現代網路上未使用。

RFC 2774 ↗
511

需要網路身份驗證

客戶端必須進行身份驗證才能獲得網路存取權限。

被強制網路門戶(酒店/機場 WiFi)使用,表示使用者必須先登入網路,然後才能存取外部網站。

RFC 6585 ↗

工作原理

此工具是一個客戶端參考手冊,圍繞硬編碼的 63 個 HTTP 狀態碼查詢表建立,涵蓋全部五個類別(1xx–5xx),每個都註明了定義它的 RFC 編號。沒有伺服器呼叫、沒有外部 API、沒有網路請求——所有篩選和顯示都在瀏覽器中使用 JavaScript 內建的陣列和字串方法完成。

  1. 1
    載入查詢表
    全部 63 個 IANA 註冊的狀態碼以 JavaScript 陣列形式直接嵌入此工具,每個條目包含數字程式碼、標準英文名稱、類別以及定義它的具體 RFC(例如大多數 HTTP/1.1 狀態碼為 RFC 9110,429 Too Many Requests 為 RFC 6585,418 I'm a Teapot 為 RFC 2324)。
  2. 2
    在記憶體中篩選
    你輸入或選擇類別篩選時,JavaScript 的 Array.filter 會對記憶體中的列表執行,使用 String.includes 將你的查詢與狀態碼數字、標準名稱以及簡短和詳細描述進行符合——沒有防抖延遲,沒有伺服器往返。
  3. 3
    展開詳情並附 RFC 連結
    每個結果都渲染為 HTML details/summary 元素。展開條目會顯示詳細說明以及指向 rfc-editor.org 上權威 RFC 的直接連結,方便你閱讀任何狀態碼的準確規範原文。
  4. 4
    深度連結與剪貼簿複製
    開啟條目會將網址雜湊更新為狀態碼數字(例如 #404),使頁面便於分享和收藏。複製按鈕透過瀏覽器的 navigator.clipboard API 將標準字串(例如 '404 Not Found')寫入剪貼簿。

相關工具

常見問題