伺服器已收到請求標頭，用戶端可以繼續送出請求內容。通常出現在用戶端送出 Expect: 100-continue、想先確認伺服器願意接收大型上傳時。
HTTP 狀態碼
查詢所有 HTTP 狀態碼的中英文名稱、意義、常見原因與解決方法，可依號碼或關鍵字搜尋。
輸入號碼（例如 404、5xx）或中英文關鍵字
共 63 個狀態碼
1xx 資訊回應
伺服器同意用戶端的 Upgrade 要求，改用另一種協定溝通，最常見的是從 HTTP/1.1 升級成 WebSocket。
WebDAV 用的暫時回應，表示伺服器已收到請求、仍在處理，避免用戶端以為逾時。現在已很少使用。
後續的 WebDAV 規範（RFC 4918）已不再定義此狀態碼。
在正式回應之前先送出 Link 標頭，讓瀏覽器提早預先載入 CSS、字型或預先連線，縮短網頁載入時間。
規範：RFC 8297 §2
2xx 成功
請求成功。GET 會在內容中回傳資源，POST 則回傳處理結果。這是最常見的狀態碼。
請求成功並建立了新資源，通常是 POST 或 PUT 的回應，Location 標頭會指向新資源的網址。
伺服器已接受請求，但還沒處理完（例如排入背景工作佇列），之後可能成功也可能失敗。
請求成功，但回傳的內容被中間的代理伺服器修改過，不是原始伺服器的版本。
請求成功，但沒有內容要回傳。常見於 DELETE、儲存設定或 CORS 預檢（OPTIONS）的回應。
請求成功，請用戶端重設畫面，例如清空剛送出的表單。實際上很少使用。
伺服器只回傳了用戶端以 Range 標頭要求的部分內容，用於續傳下載與影片拖曳播放。
WebDAV 用：一次操作多個資源時，在 XML 內容中分別列出每個資源的狀態。
WebDAV 用：同一個資源在前面的多重狀態回應中已列出，避免重複列舉。
伺服器回傳的是套用了差異編碼（instance manipulation，例如只傳變更部分）後的結果。極少使用。
3xx 重新導向
資源有多個版本（例如不同語言或格式），請用戶端自行選擇。實際上很少使用。
資源已永久搬到 Location 標頭指定的新網址，搜尋引擎會把排名轉到新網址，瀏覽器也會快取這個轉址。
常見原因與解決方法
常見原因
- 網站改版或換網域
- HTTP 轉 HTTPS
- 網址加上或去掉結尾斜線、www
解決方法
- 確認轉址真的是永久的：瀏覽器會長時間快取 301，設錯很難撤回
- POST 請求被轉址後可能變成 GET；要保留方法時改用 308
- 避免轉址鏈與迴圈，直接轉到最終網址
資源暫時位於 Location 標頭的網址，之後仍應使用原網址。常用於登入後導向，搜尋引擎會保留原網址。
常見原因與解決方法
常見原因
- 登入、登出或表單送出後的導向
- 依語言或裝置暫時轉址
- A/B 測試或維護頁
解決方法
- 網址已永久變更時改用 301 或 308
- 瀏覽器通常會把 POST 改成 GET 跟隨轉址；要保留方法時用 307
請用 GET 到 Location 標頭的網址取得結果。常用於表單送出後導向結果頁（Post/Redirect/Get），避免重新整理時重複送出。
資源自用戶端上次取得後沒有變更（依 If-None-Match 或 If-Modified-Since 判斷），用戶端可直接使用快取，回應不含內容。
常見原因與解決方法
常見原因
- 瀏覽器帶著 ETag 或 Last-Modified 重新驗證快取，這是正常行為
解決方法
- 看到舊內容時，確認伺服器在檔案更新後會產生新的 ETag，或在靜態檔名中加上雜湊值
- 開發時可在開發者工具勾選「停用快取」
要求用戶端透過指定的代理伺服器存取。因安全疑慮已被廢除，瀏覽器不支援。
早期草案中的「Switch Proxy」，已不再使用，但保留這個號碼不再分配。
和 302 一樣是暫時轉址，但明確規定用戶端必須以相同的方法與內容重新送出（POST 仍是 POST）。HSTS 讓瀏覽器自動改用 HTTPS 時也會顯示 307。
和 301 一樣是永久轉址，但用戶端必須以相同的方法與內容重新送出。適合 API 換網址。
4xx 用戶端錯誤
伺服器無法理解請求，例如格式錯誤、參數不正確或內容無法解析。
常見原因與解決方法
常見原因
- JSON 格式錯誤，或 Content-Type 與實際內容不符
- 缺少必填參數或參數格式不對
- Cookie 或標頭太大、損壞
- 網址含有未編碼的特殊字元
解決方法
- 檢查回應內容中的錯誤說明
- 用 JSON 格式化工具驗證請求內容，確認 Content-Type 正確
- 網頁出現 400 時，清除該網站的 Cookie 後再試
需要驗證身分，但請求沒有帶憑證或憑證無效。雖然名稱是「Unauthorized」，實際意思是「未驗證」（不知道你是誰）。回應應附上 WWW-Authenticate 標頭。
常見原因與解決方法
常見原因
- 沒有登入或登入已過期
- API 金鑰、Bearer token 缺少、打錯或已過期
- Authorization 標頭格式錯誤（例如少了「Bearer 」）
解決方法
- 重新登入或更新 token
- 用 JWT 解碼工具檢查 token 的到期時間（exp）
- 確認 Authorization 標頭的格式與 API 文件一致
保留給未來的付款機制，目前沒有標準用法。部分服務用它表示額度用完或訂閱過期。
伺服器知道你是誰（或不需要知道），但拒絕這個請求：你沒有權限。重新登入通常沒有幫助。
常見原因與解決方法
常見原因
- 帳號沒有該資源的權限
- 檔案或目錄權限設定錯誤，或目錄沒有索引檔且禁止列出
- 防火牆、WAF 或 CDN 依 IP、地區封鎖
- CSRF token 缺少或不正確
解決方法
- 確認帳號角色與權限
- 檢查伺服器上的檔案權限與擁有者
- 查看 WAF／CDN 的封鎖紀錄
伺服器找不到請求的資源。可能是網址打錯、頁面已刪除，或伺服器不想透露資源存在（代替 403）。
常見原因與解決方法
常見原因
- 網址拼錯、大小寫不對或少了結尾斜線
- 頁面被刪除或搬移但沒有設定轉址
- API 路徑或版本號錯誤
- 單頁應用程式（SPA）的路由沒有在伺服器設定退回 index.html
解決方法
- 檢查網址拼寫，或從網站首頁重新尋找
- 搬移頁面時設定 301 轉址到新網址
- 永久刪除的內容可改回傳 410
資源存在，但不支援這個 HTTP 方法（例如對唯讀資源送出 POST）。回應的 Allow 標頭會列出可用的方法。
常見原因與解決方法
常見原因
- 用錯方法（GET／POST／PUT／DELETE）
- 表單送到靜態檔案或錯誤的路徑
- 伺服器或框架的路由沒有註冊這個方法
解決方法
- 查看回應的 Allow 標頭與 API 文件
- 確認路由設定包含這個方法
伺服器無法提供符合請求 Accept 系列標頭（格式、語言、編碼）的內容。
和 401 類似，但需要驗證的是中間的代理伺服器，常見於公司網路。
伺服器等太久沒有收到完整的請求，於是關閉連線。
常見原因與解決方法
常見原因
- 網路很慢或不穩定
- 上傳大型檔案時中斷
- 用戶端開了連線卻沒有送出請求
解決方法
- 稍後重試
- 檢查網路連線，或把大型上傳分段進行
請求與資源目前的狀態衝突，例如同時編輯造成版本衝突，或要建立的帳號已存在。
資源曾經存在，但已永久刪除，而且沒有新網址。比 404 更明確，搜尋引擎會較快把它移出索引。
伺服器要求請求必須帶有 Content-Length 標頭。
請求中的條件標頭（例如 If-Match、If-Unmodified-Since）不成立，常用來避免覆蓋別人剛更新的資料。
請求內容超過伺服器允許的大小，常見於上傳檔案。舊名稱是「Payload Too Large」。
常見原因與解決方法
常見原因
- 上傳的檔案超過限制
- Nginx 的 client_max_body_size 預設只有 1 MB
- PHP 的 upload_max_filesize、post_max_size 或框架的大小限制
解決方法
- 先壓縮檔案或圖片再上傳
- 調高伺服器、反向代理與框架各層的上傳限制
網址太長，伺服器不願處理。常見原因是把大量資料放進 query 參數，或轉址迴圈不斷附加參數。
伺服器不支援請求內容的格式（Content-Type 或 Content-Encoding）。
常見原因與解決方法
常見原因
- 送出 JSON 卻沒有設定 Content-Type: application/json
- 上傳了伺服器不接受的檔案類型
解決方法
- 設定正確的 Content-Type 標頭
- 查看 API 文件支援的格式
Range 標頭要求的範圍超出檔案大小，例如續傳時檔案已經變小。
伺服器無法滿足 Expect 標頭的要求（通常是 Expect: 100-continue）。
彩蛋：出自 1998 年的愚人節 RFC 2324「超文字咖啡壺控制協定」，茶壺被要求煮咖啡時回傳。不是正式的 HTTP 狀態碼，但很多軟體都實作了它。
IANA 登記為「(Unused)」並保留不分配，因為太多程式已經在用它。
請求被送到無法為這個網域回應的伺服器，常見於 HTTP/2 連線重複使用、多個網域共用同一個憑證時。
請求格式正確，但內容在語意上有錯，例如欄位驗證失敗（電子郵件格式錯誤、密碼太短）。許多 API 用它回報表單驗證錯誤。
常見原因與解決方法
常見原因
- 欄位驗證失敗
- 資料型別正確但值不合理（例如結束日早於開始日）
解決方法
- 查看回應中每個欄位的錯誤說明並修正輸入
WebDAV 用：資源已被鎖定，暫時無法修改。
WebDAV 用：因為它所依賴的另一個操作失敗，這個操作也無法執行。
伺服器不願處理可能被重送攻擊的請求。用於 TLS 1.3 的 0-RTT 早期資料：請等交握完成再送一次。
伺服器要求改用其他協定（Upgrade 標頭會說明，例如更新版本的 TLS 或 HTTP）。
伺服器要求請求必須帶條件標頭（例如 If-Match），避免「先讀後寫」時覆蓋別人的修改。
規範：RFC 6585 §3
在一段時間內送出太多請求，觸發了速率限制。Retry-After 標頭可能會告訴你要等多久。
常見原因與解決方法
常見原因
- 程式迴圈或重試太頻繁
- 超過 API 方案的額度
- 多個使用者共用同一個 IP 或金鑰
解決方法
- 依 Retry-After 等待後再試
- 加入指數退避（每次重試等待時間加倍）與快取
- 合併請求或升級方案
規範：RFC 6585 §4
請求標頭太大，伺服器拒絕處理，最常見的原因是 Cookie 累積太多。
常見原因與解決方法
常見原因
- 網站或子網域累積了大量 Cookie
- 過長的 Referer 或自訂標頭
解決方法
- 清除該網站的 Cookie
- 伺服器端減少 Cookie 數量或調高標頭大小限制
規範：RFC 6585 §5
因法律要求（例如政府命令、法院判決或著作權下架）而無法提供這個資源。號碼取自小說《華氏 451 度》。
規範：RFC 7725 §3
5xx 伺服器錯誤
伺服器遇到未預期的錯誤，無法完成請求。這是伺服器端的問題，不是你的操作有誤。
常見原因與解決方法
常見原因
- 程式碼有未處理的例外
- 設定檔錯誤（例如 .htaccess 語法錯誤）
- 資料庫或相依服務出錯
- 檔案權限錯誤
解決方法
- 使用者：稍後重新整理，持續發生就聯絡網站管理員
- 開發者：查看伺服器的錯誤紀錄（error log），找出例外與堆疊追蹤
伺服器不支援完成請求所需的功能，例如不認得這個 HTTP 方法。
擔任閘道或反向代理的伺服器（例如 Nginx、CDN）從後端伺服器收到無效的回應，或根本連不上後端。
常見原因與解決方法
常見原因
- 後端程式當掉、重新啟動中或沒有在監聽的連接埠上執行
- 反向代理設定的後端位址或連接埠錯誤
- 後端回應格式錯誤或在回應中途關閉連線
解決方法
- 確認後端服務正在執行
- 查看反向代理與後端的錯誤紀錄
- 使用者：稍後重試
伺服器暫時無法處理請求，通常是過載或維護中。Retry-After 標頭可能會說明何時恢復。
常見原因與解決方法
常見原因
- 流量暴增（例如搶票、促銷）
- 系統維護
- 後端資源（連線數、記憶體）用盡
解決方法
- 稍後再試
- 維護時回傳 503 並加上 Retry-After，搜尋引擎就不會把網站移出索引
- 擴充主機或加入佇列與快取
擔任閘道或反向代理的伺服器等太久，沒有及時收到後端伺服器的回應。
常見原因與解決方法
常見原因
- 後端處理太久（慢查詢、大量運算）
- 後端與代理之間網路有問題
- 代理的逾時設定太短
解決方法
- 找出並最佳化慢的請求
- 把長時間的工作改成背景處理（回傳 202）
- 適度調高代理的逾時設定
伺服器不支援請求所使用的 HTTP 主要版本。
伺服器的內容協商設定有誤，選出的變體本身又要進行協商，形成循環。
WebDAV 用：伺服器沒有足夠的空間儲存完成請求所需的內容。
WebDAV 用：處理請求時遇到無限迴圈（例如資料夾綁定互相參照）。
請求需要更多擴充宣告才能處理。所屬的 HTTP 擴充框架（RFC 2774）已被列為歷史文件。
IANA 已將此狀態碼標為「已廢止」（OBSOLETED）。
規範：RFC 2774 §7
需要先登入網路才能上網，常見於飯店、機場、咖啡店的 Wi-Fi 登入頁（captive portal）。
規範：RFC 6585 §6
使用說明
- 在搜尋框輸入狀態碼號碼（例如 404）、類別（例如 5xx）或中英文關鍵字（例如「逾時」、gateway）。
- 用「類別」只看某一類，例如只看用戶端錯誤（4xx）。
- 常見的錯誤附有「常見原因與解決方法」，點開即可查看；規範連結會帶你到定義該狀態碼的 RFC 章節。
- 每個狀態碼都有自己的網址，例如在本頁網址後加上 #404，可以直接分享給同事。
常見問題
HTTP 狀態碼的五個類別代表什麼？
第一位數字代表類別：1xx 是資訊回應（請求已收到，繼續處理）；2xx 是成功；3xx 是重新導向（需要到其他網址）；4xx 是用戶端錯誤（請求本身有問題，例如網址錯誤或沒有權限）；5xx 是伺服器錯誤（請求沒問題，但伺服器處理失敗）。
401 和 403 有什麼不同？
401 表示「還不知道你是誰」：沒有登入或憑證無效，重新登入通常可以解決。403 表示「知道你是誰，但你沒有權限」，重新登入也沒用，需要取得權限。
301、302、307、308 要用哪一個？
永久搬移用 301 或 308，暫時轉址用 302 或 307。差別在於 301 與 302 可能讓瀏覽器把 POST 改成 GET，307 與 308 則保證沿用原本的方法與內容。一般網頁換網址用 301，API 換網址建議用 308。
418「我是茶壺」是真的狀態碼嗎？
它是彩蛋，出自 1998 年的愚人節文件 RFC 2324。它不是正式的 HTTP 狀態碼，但因為許多軟體都實作了，IANA 把 418 標為「未使用」並保留，不會分配給其他用途。
為什麼沒有 499、520 等狀態碼？
本表收錄的是在 IANA 正式登記的狀態碼。499（Nginx：用戶端關閉連線）、520–527（Cloudflare）等是特定軟體或服務自訂的，不屬於 HTTP 標準，意義也可能因服務而異，請查看該服務的說明文件。
資料來源是什麼？
狀態碼清單依據 IANA 的 HTTP Status Code Registry，名稱與定義以 RFC 9110（HTTP Semantics）及各狀態碼的原始 RFC 為準，每個狀態碼都附有規範章節的連結。