HTTP 狀態碼完整參考：200 到 599 全解

HTTP 狀態碼完整參考：200 到 599 全解 | 開發者與 SEO 必備指南

在網際網路的世界裡，瀏覽器（Client）與伺服器（Server）之間的溝通，本質上是一場永無止境的問答。當你輸入一個網址並按下 Enter，瀏覽器會發送一個 HTTP 請求，而伺服器在處理完畢後，必須回傳一個「回應」。這個回應中，最關鍵的資訊之一就是 HTTP 狀態碼（HTTP Status Code）。

對於前端開發者來說，狀態碼是除錯（Debugging）的第一線線索；對於後端工程師來說，它是 API 設計與系統穩定性的指標；而對於 SEO 專家來說，狀態碼的正確性直接決定了搜尋引擎如何索引你的網站。

本文將為你提供一份 HTTP 狀態碼完整參考，從 200 系列到 500 系列進行深度解析，幫助你掌握網頁通訊的核心邏輯。如果你在開發過程中遇到不明原因的連線問題，也可以利用 HTTP 狀態碼檢查工具 來快速診斷問題所在。

100-199：資訊性回應（Informational）

這類狀態碼在現代網頁開發中較少直接與使用者互動，但它們在底層通訊中扮演著重要的「過渡」角色。

1xx 類別：正在處理中

這類狀態碼表示伺服器已收到請求的一部分，正在繼續處理後續的部分。

• 100 Continue：客戶端應繼續發送請求的一部分。這常用於處理大型檔案上傳，當客戶端先發送 Header，伺服器回傳 100，告訴客戶端「我準備好了，可以開始傳送 Body 了」。
• 101 Switching Protocols：伺服器正在根據客戶端的請求切換協定（例如從 HTTP 切換到 WebSocket）。

2xx：成功回應（Success）

當你看到 2xx 系列的狀態碼時，代表你的請求已經成功被伺服器接收、理解並處理。這是開發者最希望看到的結果。

200 OK：最經典的成功

這是最常見的狀態碼。當請求成功且回應主體（Response Body）包含正確資訊時，伺服器會回傳 200。無論是讀取網頁、取得 JSON 資料或是提交表單，只要一切順利，就是 200。

201 Created：資源已建立

這在 RESTful API 設計中非常重要。當你發送一個 POST 請求來建立新資源（例如註冊新用戶、上傳新文章）且伺服器成功建立該資源時，應回傳 201。此時，回應通常會包含新資源的 URI。

202 Accepted：已接受但尚未處理完成

這代表伺服器已接受請求，但尚未完成處理。這常用於「非同步處理」的場景，例如你提交了一個大型影片轉檔任務，伺服器回傳 202 告訴你：「我收到任務了，但還在排隊中，請稍後再來查詢進度」。

2․ 204 No Content：成功但無內容

這表示請求已成功，但伺服器不需要回傳任何內容。常見於 DELETE 請求（刪除成功後不需要回傳資料）或某些 PUT 更新請求。

3xx：重定向回應（Redirection）

3xx 系列狀態碼告訴瀏覽器：「你要找的東西不在這裡，請去另一個地方」。這對於網站遷移與 URL 結構調整至關重要。

301 Moved Permanently：永久重新導向

這是 SEO 的重中之重。 當你更換了網域或修改了網址結構，且未來都不會再使用舊網址時，應使用 301。它會將原有的「權重（Link Juice）」傳遞給新網址，讓搜尋引擎知道舊頁面已永久搬家。

302 Found：暫時性重新導向

這表示資源暫時移動到了另一個位置。與 301 不同，302 不會傳遞權重，搜尋引擎仍會保留舊網址的索引。常用於活動頁面導向或根據使用者語言進行的暫時性跳轉。

304 Not Modified：內容未變動（快取機制）

這是一個提升網站效能的關鍵狀態碼。當瀏覽器請求資源時，會帶上 If-Modified-Since 標頭。如果伺服器發現檔案自上次下載後未變動，就會回傳 304。這告訴瀏覽器：「直接用你本地的快取即可，不需要重新下載」，大幅節省頻寬與載入時間。

307 Temporary Redirect 與 308 Permanent Redirect

這兩個是 HTTP/1.1 引入的新標準，旨在解決 302 與 301 在處理 POST 請求時可能改變 Method 的問題。 * 307：確保重定向時，請求方法（如 POST）不會變成 GET。 * 308：與 301 類似，但同樣保證 Method 不變。

4xx：用戶端錯誤（Client Error）

當你看到 4xx 時，代表問題出在「請求端」。可能是 URL 打錯了、權限不足，或是發送了格式錯誤的資料。

400 Bad Request：錯誤的請求

伺服器無法理解請求的語法。這通常是因為前端傳送的 JSON 格式錯誤、缺少必要的參數，或是參數類型不符（例如預期是數字卻傳了字串）。

401 Unauthorized：未經授權

這代表請求需要身分驗證。如果你嘗試存取需要登入的 API，但沒有提供正確的 Token 或 Cookie，伺服器就會回傳 401。

403 Forbidden：禁止存取

這與 401 不同。401 是「不知道你是誰」，而 403 是「我知道你是誰，但你沒有權限看這個」。例如，一般用戶嘗試存取管理員後台，伺服器會回傳 403。

404 Not Found：找不到資源

開發者最熟悉的錯誤。請求的 URL 在伺服器上不存在。這可能是因為連結失效、檔案被刪除，或是開發者在路徑拼字上出了錯。

4的 405 Method Not Allowed：不允許的使用方法

這發生在請求的 Method 與伺服器定義的不符。例如，你對一個只接受 POST 的 API 發送了 GET 請求。

429 Too Many Requests：請求過於頻繁

這是 API 流量限制（Rate Limiting）的警訊。當單一 IP 或使用者在短時間內發送過多請求，伺服器會回傳 429 來保護系統不被 DDoS 攻擊或過度爬蟲耗盡資源。

5xx：伺服器錯誤（Server Error）

當你看到 5xx 時，請檢查你的後端代碼、資料庫連線或伺服器設定。這代表請求本身沒問題，但伺服器在處理過程中「崩潰」或「出錯」了。

500 Internal Server Error：伺服器內部錯誤

最泛用的錯誤代碼。當後端程式碼拋出未捕獲的 Exception（異常），或是發生了未預期的邏輯錯誤時，伺服器通常會回傳 500。

502 Bad Gateway：錯誤的閘道

這通常發生在代理伺服器（如 Nginx）與後端應用伺服器（如 Node.js, Python Gunicorn）之間。當 Nginx 嘗試連接後端，但後端沒有回應或已關閉，就會回傳 502。

503 Service Unavailable：服務不可用

這代表伺服器目前無法處理請求，通常是因為伺服器過載（Overload）或正在進行維護（Maintenance）。

504 Gateway Timeout：閘道逾時

與 502 類似，但 504 是指代理伺服器雖然連上了後端，但後端處理時間太長，導致代理伺服器等得不耐煩而主動中斷連線。

狀態碼快速比較表

為了方便開發者查閱，下表整理了最常遇到的狀態碼及其核心差異：

實戰範例：如何在 JavaScript 中處理 HTTP 狀態碼

在前端開發中，我們經常使用 fetch API 來與後端溝通。一個專業的開發者不應該只假設請求會成功，而應該針對不同的狀態碼進行邏輯判斷。

以下是一個完整的範例，展示如何根據不同的 HTTP 狀態碼執行不同的業務邏輯：

async function fetchData(url) {
    try {
        const response = await fetch(url);

        // 檢查 response.ok (這代表狀態碼在 200-299 之間)
        if (response.ok) {
            const data = await response.json();
            console.log("✅ 請求成功:", data);
            return data;
        }

        // 針對特定錯誤狀態碼進行處理
        switch (response.status) {
            case 401:
                console.error("❌ 身份驗證失敗：請重新登入");
                // 執行導向登入頁面的邏輯
                break;
            case 403:
                console.error("❌ 權限不足：您沒有權限查看此內容");
                break;
            case 404:
                console.error("❌ 找不到資源：請檢查 URL 是否正確");
                break;
            case 429:
                console.error("⚠️ 請求太頻繁：請稍後再試");
                break;
            case 500:
                console.error("🔥 伺服器出錯：請聯繫後端工程師");
                break;
            case 503:
                console.error("🛠️ 伺服器維護中：請稍後再回來");
                break;
            default:
                console.error(`❌ 發生未知錯誤，狀態碼：${response.status}`);
        }
    } catch (error) {
        // 這裡處理網路斷線、DNS 解析失敗等網路層級的錯誤
        console.error("🌐 網路連線異常或 CORS 錯誤:", error.message);
    }
}

// 使用範例
fetchData('https://api.example.com/user/profile');

FAQ：關於 HTTP 狀態碼的常見問題

Q1: 301 和 302 有什麼本質上的區別？

A: 最核心的區別在於「權重轉移」與「搜尋引擎的行為」。301 是永久性的，搜尋引擎會將舊網址的排名權重移交給新網址；302 是暫時性的，搜尋引擎仍會保留舊網址的索引，這對於需要頻繁切換的短暫活動非常有用。

Q2: 為什麼我的網站出現 502 錯誤，但伺服器看起來是正常的？

A: 502 通常發生在「代理層」。如果你的架構使用了 Nginx 作為反向代理，雖然 Nginx 服務正常，但它後端的應用伺服器（如 Node.js 或 PHP-FPM）可能因為當機、資源耗盡或配置錯誤而無法回應。請檢查後端服務的運行狀態與 Nginx 的 error.log。

Q3: 404 錯誤會影響 SEO 嗎？

A: 會。雖然偶爾的 404 是正常的（例如產品下架），但如果大量的重要頁面出現 404，搜尋引擎會認為你的網站品質下降，且會浪費爬蟲的「抓取預算（Crawl Budget）」。建議針對重要的失效連結，使用 301 導向至相關的替代頁面。

Q4: 什麼時候應該使用 204 No Content？

A: 當你的 API 執行了一個動作（例如刪除資料、更新設定），且這個動作不需要回傳任何 JSON 或文字內容給前端時，使用 204 是最符合 RESTful 規範的做法，這能減少網路傳輸的負擔。

Q5: 429 Too Many Requests 應該如何緩解？

A: 對於開發者來說，應在前端實作「指數退避（Exponential Backoff）」演算法，即在收到 429 後，等待一段時間再重試，且每次重試的等待時間隨次數增加。對於系統管理員，則應檢查是否有惡意爬蟲或異常的 API 調用流量。

Q6: 為什麼 304 狀態碼對網站效能提升這麼大？

A: 因為 304 意味著「不傳輸內容」。瀏覽器不需要重新下載圖片、CSS 或 JavaScript，只需要接收一個極小的 Header 訊息，確認檔案沒變。這能極大化減少瀏覽器的下載量，縮短首屏渲染時間（FCP）。

結論

掌握 HTTP 狀態碼完整參考 不僅是開發者的基本功，更是維護高品質網站的基石。正確地使用 2xx 確保服務順暢，利用 3xx 進行精準的流量引導與 SEO 優化，透過 4xx 強化系統安全性與使用者體驗，並透過 5xx 監控伺服器的健康狀況。

當你在開發過程中遇到難以捉摸的連線問題時，請務必養成查看 Network Tab 中狀態碼的習慣。如果你需要更系統化的工具來檢測網路請求的正確性，歡迎探索 Super Tools 研發工具箱，我們提供多樣化的開發者工具，助你打造更穩定的 Web 應用。