HTTP Status Codes 工具是一個獨立運作、以瀏覽器為基礎的參考資料,收錄了 IANA HTTP Status Code Registry 中 64 筆個別註冊的條目,於 July 17, 2026 擷取,同時作為 HTTP 狀態碼 API 的替代方案,因為每次查詢皆在本機執行,不會發出網路請求、呼叫外部服務,也不會上傳搜尋文字。開發者不必依賴會回傳相同描述字串的託管端點,而是開啟單一頁面,在瀏覽器中直接篩選 IANA 快照,因此隱私、流量限制與服務可用性不再是查詢流程的一環。表格依照數值排序,包含每個代碼的回應類別、意義的簡明釋義、註冊狀態,以及連結的 RFC 參考文件,適合用來交叉檢查哪些代碼仍被視為網際網路標準,哪些已被標示為已棄用、未使用或已過時。由於資料集是基於註冊表,而非收錄任何伺服器可能產出的所有數字,因此刻意排除了廠商專屬的擴充與未指派的範圍,使參考資料與 IANA 快照保持一致,而非依循特定框架的詮釋。

http status codes api alternative
HTTP Status Codes API 替代方案:一個私密的瀏覽器工具

為什麼開發者會尋找 HTTP Status Codes API 替代方案

外部的 HTTP 狀態碼 API 與執行階段程式庫解決了一個反覆出現的問題:開發者需要快速確認 503、429 或 422 究竟代表什麼,而不必每次重新閱讀 RFC 9110。託管端點、內含硬式編碼列舉的 NPM 套件,以及特定語言的常數程式庫各有其用途,但每一種都帶有會在團隊之間及隨時間累積的摩擦。任何第三方服務都會受到流量限制,而查詢端點的停機會在技術堆疊中不相關的工具與測試上造成故障。當新的暫時性註冊出現或代碼被重新分類時,常數程式庫會逐漸偏離 IANA 註冊表,使真相來源分散於多個過時的套件版本中。各框架也會發布自己的代碼清單,而這些清單常包含並非網際網路標準的廠商專屬擴充,在該框架內有其用處,但開發者取用通用參考資料時,則會造成誤導。

以註冊表為優先的瀏覽器參考資料透過將網路呼叫從查詢路徑中移除,來解決這些痛點。搜尋在使用者的瀏覽器中,針對內嵌的 IANA HTTP Status Code Registry 快照進行,因此資料不會移動,開發者也不需要帳號、權杖或配額。其權衡在於資料集帶有快照日期,而在該日期之後新增或重新分類的代碼,將不會出現,直到快照更新。對大多數查詢流程而言,此權衡是可接受的,因為註冊表變動緩慢,且快照是明確標示的,而不是隱藏在會變動的 API 後方。

以瀏覽器為基礎的註冊表參考資料實際提供什麼

HTTP Status Codes 參考資料刻意維持在狹窄的範圍內。它僅包含 IANA HTTP 狀態碼註冊表中目前列出的 64 個個別命名條目,涵蓋從 100 到 511,除此之外別無其他。未指派的範圍是刻意排除的,這能避免一個語法上有效的三位數數字被誤述為已註冊的標準。例如,數值 105 位於未指派的範圍內,因此精確搜尋 105 不會回傳任何資料列,介面會顯示沒有符合的註冊條目。這對註冊表參考資料而言是正確的行為,即使對於曾在自訂框架中見過 105 的開發者來說,可能會感到意外。

表格中的每一列皆包含五項資訊:數值代碼、原因片語、回應類別、意義的簡明釋義,以及註冊狀態標籤。當代碼指向一份權威文件時,表格也會附上 RFC 參考資料,讓開發者在變更實作行為前能查閱相關的規範。註冊狀態標籤對任何曾經歷過標準化流程的代碼都很重要:104 被標示為 Temporary(暫時性),因為它繫結於一份進行中的 Internet-Draft;305 Use Proxy 被標示為 deprecated(已棄用);306 與 418 被標示為 unused(未使用);510 Not Extended 則被標示為 obsolete(已過時)。表格保留這些條目,因為它們在註冊表中擁有明確的資料列,但標籤明確指出,它們不應被選為新工作中的普通現行回應代碼。

如何在不呼叫 API 的情況下查詢狀態碼

若要在不呼叫外部 API 的情況下查詢 HTTP 狀態碼,請開啟 HTTP Status Codes 參考資料,並依照下列步驟操作:

  1. 在搜尋框中輸入精確的三位數代碼(例如 404)、類別樣式(例如 4xx)、原因片語(例如 Not Found)、概念(例如 gateway),或通訊協定詞彙(例如 WebDAV)。搜尋會檢查代碼、片語、類別、摘要、RFC 參考資料,以及註冊狀態,因此部分與概念性的比對與精確的數值查詢同樣有效。
  2. 當您希望將比對範圍限制在某個一百區段時,從回應類別選擇器中選擇 Informational、Successful、Redirection、Client error 或 Server error。選擇器會與文字查詢結合,因此在 Server error 下搜尋 gateway 僅會回傳與 gateway 相關的伺服器端失敗;而在 Server error 下搜尋 Not Found 會產生明確的空白結果,而不是留下一個過時的表格。
  3. 閱讀篩選後每列所留下的片語、簡明意義、註冊狀態標籤,以及 RFC 參考資料。請將簡明意義視為釋義,而非引用 RFC 的替代,因為精確的語意通常取決於請求方法、標頭、快取狀態、驗證內容、中介行為,或諸如 WebDAV 之類的擴充。
  4. 當實作細節影響互通性、安全性、快取或自動重試行為時,請開啟連結的 RFC。連結的規範是以下事項的權威來源:方法是否允許、主體是否可使用、快取如何驗證,以及用戶端應如何回應。
  5. 將註冊狀態標籤本身作為篩選條件。當標籤顯示為 Temporary、Deprecated、Unused 或 Obsolete 時,請將該代碼視為超出普通現行集合的範圍,並選用註冊表中其他位置所記載的現行替代方案。

整個流程都在瀏覽器中完成。搜尋文字絕不會上傳至 Lizely 或任何其他服務,因此此工具在受限的網路環境、注重隱私的情境,以及限制對外 HTTP 流量的環境中,皆可使用。

五種回應類別與篩選運作方式

HTTP 回應代碼根據首位數字分為五個類別,而參考資料上的回應類別選擇器反映了此分組。理解類別之間的界線,是精準搜尋與雜訊結果之間的差異所在。下表概述了 RFC 9110 所定義的結構,以及本工具篩選邏輯所使用的結構。

類別代碼範圍一般意義典型動作
Informational100–199最終回應之前的過渡進度繼續等待或傳送請求的其餘部分
Successful200–299請求已接受、已理解並已處理讀取回應主體或進行下一步
Redirection300–399需要進一步動作才能完成請求遵循 Location 標頭或套用快取規則
Client error400–499由於用戶端條件,請求無法處理檢查請求、修正輸入,或重新驗證身分
Server error500–599伺服器無法完成有效的請求檢查伺服器記錄、以退避方式重試,或聯絡操作人員

類別的範圍比單一代碼更廣。404 Not Found 與 429 Too Many Requests 都屬於用戶端錯誤回應,但它們傳達的條件不同,通常也需要不同的處理方式。當開發者正在除錯一整類失敗,而非特定代碼時,以類別進行篩選是一種縮窄搜尋範圍的方法。在搜尋框中輸入 4xx 會回傳用戶端錯誤類別中所有個別註冊的條目;它並不會為未指派的數字虛構資料列,因此結果數量會對應該類別中已註冊代碼的數量,而不是介於 400 至 499 之間每個可能值的合成數量。

「Current」以外的註冊狀態

將每個 HTTP 狀態碼視為穩定、現行的標準,是常見的錯誤來源。IANA 註冊表追蹤了數種註冊狀態,並以標籤形式在表格中呈現,讓開發者一眼即可判斷某個代碼是否適合發出。Current(現行)代碼是任何符合規範的用戶端與伺服器皆可依賴的日常值。Temporary(暫時性)代碼(例如 104 Upload Resumption Supported)繫結於進行中的 Internet-Draft,可能在成為永久代碼之前過期或變更,因此在評估該狀態下的代碼時,條目旁的快照日期至關重要。

Deprecated(已棄用)條目仍保有註冊資料列,但不再建議用於新工作。RFC 9110 將 305 Use Proxy 記載為 deprecated。Unused(未使用)條目(例如 306 與 418)為保留狀態,並在註冊表中標示為 unused;與 418 相關的知名「I'm a teapot」片語並非目前的 IANA 描述,表格刻意顯示註冊表的 unused 標籤,而非該文化性片語。Obsolete(已過時)條目(包括 510 Not Extended)僅作為歷史參考而保留,不應作為普通回應代碼使用。這些狀態皆代表應從現行集合中選擇其他代碼的訊號,表格的標籤使該訊號無需額外研究即可一目了然。

當登錄項目參考無法診斷即時事件時

HTTP 狀態碼傳達的是通訊協定結果,並無法證明根本原因,且登錄項目參考並不能取代即時除錯。502 Bad Gateway 可能反映上游服務當機、網路路徑問題、代理程式逾時政策,或格式錯誤的上游輸出,單一狀態碼很少足以區分這些情境。429 回應代表速率限制,但其重試行為取決於特定服務,可能會使用 Retry-After 標頭來傳達等待時間。404 可能將受禁止的資源隱藏在通用的找不到回應之後,而 500 刻意設計為通用訊息,以避免洩漏實作細節。

對於上述任何情況,HTTP 狀態碼工具說明的是已註冊的通訊協定意義,而非特定伺服器上的運作錯誤。請使用回應標頭、要求識別碼、伺服器記錄,以及相關服務文件來判斷即時事件的實際原因。此工具不會聯絡 URL、不會檢查伺服器,也不會聲稱能識別執行階段錯誤,而這項界線正是它能作為穩定參考而非除錯工具的一部分原因。若需要獨立的、以實作為導向的交叉檢查,MDN 的HTTP response status codes 參考是一個有用的輔助資源,但仍應與 IANA 快照並行閱讀,而非作為替代品。

如果您正在權衡各種選項,JavaScript Playground API Alternative for Browser Testing 對此有詳細說明。