當服務端返回 HTTP 響應時，會帶有一個狀態碼，用于表示特定的請求結果。比如 HTTP/1.1 200 OK，里面的 HTTP/1.1 表示協議版本，200 則是狀態碼，OK 則是對狀態碼的描述。

由協議版本、狀態碼、描述信息組成的行被稱為起始行，服務端返回的響應報文中的第一行便是它，然后是響應頭和響應體。

而本篇文章，我們來詳細聊一聊狀態碼，看看它都有哪些，以及含義是什么？

首先狀態碼由三位數字組成，按照第一個數字的不同，可分為五個類別，每個類別的含義如下。

• 1xx（信息響應）：這類狀態碼表示臨時響應，意思是告訴客戶端，服務端已收到部分請求，請你繼續發送剩余的部分；
• 2xx（成功）：這類狀態碼表示客戶端的請求已被成功處理；
• 3xx（重定向）：這類狀態碼表示為了完成請求，需要進一步的操作，比如跳轉到新位置；
• 4xx（客戶端錯誤）：這類狀態碼表示請求不合法，比如操作一個沒有權限的資源或者不存在的資源等等；
• 5xx（服務端錯誤）：這類狀態碼表示服務端內部在處理請求時出現錯誤，比如服務端的代碼報錯；

下面我們來分別介紹這五類狀態碼都有哪些，以及狀態碼對應的描述是什么。

1xx 狀態碼

1xx 系列的 HTTP 狀態碼屬于信息響應類別，這類狀態碼用于指示客戶端請求的初始部分已被接收，并且客戶端應繼續其請求過程。

那么該系列的狀態碼都有哪些呢？

100 Continue

如果客戶端發送的請求體很大，比如上傳大文件，那么在發送整個請求體之前，可以先發送請求的頭部（包含一個 Expect: 100-continue 字段）。相當于告訴服務端，大的要來了，如果同意發送請求體，那么就返回一個 100 Contiune 響應。

而服務端在接收到帶有 Expect: 100-continue 的請求頭部時，可以先進行一些預檢查，比如驗證請求頭部的有效性、檢查是否有足夠的資源處理請求、或者檢查客戶端是否有權限。如果這些初步檢查通過，服務端則返回 100 Continue 響應，指示客戶端繼續發送請求體。

因此 100 Contiune 主要用于提高大型請求的處理效率，尤其是在帶寬受限或服務端處理能力有限的情況下。然而并非所有的 HTTP 客戶端和服務端都支持這個機制，在不支持的情況下，客戶端將直接發送整個請求體，不會等待 100 Continue 響應。

1xx 系列的狀態碼從 HTTP/1.1 才開始支持，HTTP/1.0 不支持。

101 Switch Protocols

這個應該都很熟悉，它一般用于協議升級，比如將 HTTP 協議升級成 WebSocket。

首先不管使用什么協議，都有一個握手的過程，它是建立網絡連接時雙方進行的一系列交互，旨在確保雙方能夠成功地通信。不同的協議有不同的握手機制，但它們通常都包括以下基本步驟：

• 協議識別：在握手過程的開始，通信雙方確定要使用的協議以及版本；
• 參數協商：根據所選協議，雙方可能需要協商一些參數，如傳輸速率、加密方式、數據格式等；
• 身份驗證：在某些協議中，如 SSL/TLS（用于 HTTPS），握手過程還包括身份驗證，這是為了確保通信雙方的身份是合法和可信的；
• 連接確認：一旦上述步驟完成，雙方將相互確認連接已建立，此時數據傳輸便可以開始；

但有一些協議在實現握手時，搭了 HTTP 協議的便車，比如 WebSocket，它的握手過程其實就是一個 HTTP GET 請求。利用 HTTP 本身的協議升級特性，偽裝成 HTTP，這樣就能繞過瀏覽器沙箱、網絡防火墻等限制。

因此建立 WebSocket 連接時會發送一個 GET 請求，并帶上兩個專用的頭字段，表示這不是普通的 HTTP GET，而是要進行協議升級。

• Connection: Upgrade，表示要求協議升級；
• Upgrade: websocket，表示要升級成 WebSocket 協議；

另外，為了防止普通的 HTTP 消息被意外識別成 WebSocket，握手消息還額外增加了兩個用于認證的頭字段。

• Sec-WebSocket-Key：一個 Base64 編碼的 16 字節隨機數，作為簡單的認證密鑰；
• Sec-WebSocket-Version：協議的版本號，當前必須是 13

服務端收到 HTTP 請求報文，看到上面的四個字段，就知道這不是一個普通的 GET 請求了，而是 WebSocket 的升級請求，表示客戶端想要建立 WebSocket 連接。

如果服務端同意建立 WebSocket 連接，那么會給客戶端返回 101 Switching Protocols 響應報文，客戶端收到之后，就知道服務端同意了。

102 Processing

該狀態碼用于 WebDAV 協議，WebDAV 請求可能包含很多涉及文件操作的子請求，需要很長一段時間才能完成。因此服務端可以直接返回 102 Processing，表示請求已被接收并正在處理中，但目前無響應可用。這樣可以防止客戶端因長時間得不到響應，而假設請求丟失。

關于 1xx 系列的狀態碼就是以上幾種，它們被稱為信息性狀態碼，用于表示請求的中間狀態，因此在日常的 Web 瀏覽中并不常見。但 1xx 狀態碼在復雜的 HTTP 通信中扮演重要角色，特別是在優化性能和處理大型請求、復雜請求時。

2xx 狀態碼

2xx 系列的狀態碼應該最受開發者喜歡了，因為它表示請求被成功處理。

200 OK

這是最常見的成功狀態碼，它表示請求已成功處理，并且響應體中包含了請求的結果。

201 Created

同樣表示請求已被成功處理，并且還創建了一個新資源。

當客戶端通過 POST 請求向服務端發送數據以創建新資源（如新的數據庫記錄、文件等）時，如果請求成功并且新資源被創建，服務端會響應 201 Created。

與 200 OK 相比，201 Created 響應不僅表明請求成功，而且還指出了一個新的資源已經產生。響應中一般會包含一個 Location 字段，指明新創建資源的 URI，這對客戶端來說非常有用，因為它可以直接使用這個 URI 來訪問新創建的資源。

當然啦，由于習慣，很多時候我們還是會返回 200，并將新創建資源的信息放在響應體中。具體使用哪種看個人習慣，總之 200 和 201 沒太大區別，只是 201 意味著要明確地告訴客戶端，新的資源已經創建了。

202 Accepted

表示服務端已收到請求，但尚未處理完成，這種設計可以覆蓋很多的場景，例如異步、需要長時間處理的任務等。至于最后請求是成功還是失敗，則是未知的。

203 Non-Authoritative Information

該狀態碼表示客戶端使用了代理服務器，代理服務器將客戶端請求轉發給服務端之后，被成功處理了。但代理服務器在將響應轉發給客戶端時，對原始響應內容進行了修改。

因此代理服務器也要將狀態碼（例如 200）修改為 203，來告知客戶端這一情況，方便客戶端做出相應的處理。注：203 響應可以被緩存。

204 No Content

該狀態碼表示請求已被成功處理，但服務端沒有返回任何內容，指示客戶端不需要更新當前的頁面視圖。

205 Reset Content

該狀態碼表示請求已被成功處理，服務端同樣沒有返回任何內容，但指示客戶端需要更新當前的頁面視圖，例如清空表單內容或重置控件。

206 Partial Content

該狀態碼表示服務端已經成功處理了客戶端發送的部分請求，主要用于以下場景。

分塊請求：當客戶端只請求資源的一部分，比如客戶端使用 Range 請求頭指定要下載文件的特定部分時，服務端會使用 206 Partial Content 響應。

斷點續傳：在文件下載過程中，如果下載被中斷（例如因為網絡問題），那么恢復正常時，客戶端可以只請求未下載的部分。服務端對這種請求的響應就是 206 Partial Content，允許客戶端繼續從中斷的地方下載，而不是重新開始。

流媒體：在流媒體應用中，客戶端可能只請求媒體文件的一小部分，以便快速加載和播放，服務端對這種請求的響應也使用 206 Partial Content。

響應頭信息：在返回 206 Partial Content 時，服務端會包含有關響應內容的信息，如 Content-Range 頭部，這個頭部指明了返回的部分內容在整個資源中的范圍。

減少數據傳輸：使用 206 Partial Content 可以減少網絡帶寬的使用，因為它允許客戶端僅請求和下載所需的數據部分。

206 Partial Content 狀態碼是一個高效處理大型資源請求的重要機制，特別是在網絡條件不穩定或資源非常大的情況下，它可以顯著提高數據傳輸的效率和可靠性。

207 Multi-Status

該狀態碼用于 WebDAV 協議，當一個客戶端請求對多個資源產生作用時，服務端會以 XML 的形式返回多個資源的狀態，此時狀態碼為 207。

所以 207 Multi-Status 狀態碼在處理操作多個資源的請求時非常有用，特別是在 WebDAV 等分布式文件系統中，它提供了一種高效且靈活的方式來同時報告多個資源的狀態。

208 Already Reported

該狀態碼通常和 207 一起使用，在 WebDAV 中，一個操作可能涉及多個資源，而這些資源可能又包含在不同的集合中。通過使用 208 Already Reported，服務端能夠高效地表示哪些資源已經被處理，從而避免在多狀態響應中重復報告。

3xx 狀態碼

3xx 系列的狀態碼屬于重定向類別，用于告知客戶端資源的獲取方式已經改變，需要采取額外動作以完成請求。

比如訪問一個已經廢棄的鏈接，服務端就會返回 3xx 狀態碼，并在響應頭的 Location 字段中指定新鏈接。客戶端發現狀態碼為 3xx 之后，就會自動重定向到 Location 中指定的新鏈接。

另外在 RFC2068 中，規定客戶端重定向次數不應超過 5 次，以防止死循環。

300 Mutiple Choices

當請求的資源有多種表示時，服務端會返回 300，并提供一個資源列表，讓客戶端自行選擇。由于缺乏明確的細節，因此該狀態碼不常用。

301 Moved Permanently

表示請求的資源已經被永久移動到了一個新的位置，該狀態碼的使用場景如下。

永久性重定向：當服務端返回 301 Moved Permanently 響應時，它表明請求的資源已經永久地移動到了由 Location 字段指定的 URL，未來所有對該資源的請求都應該使用這個新的URL。

更新書簽和鏈接：301 狀態碼告訴客戶端（如瀏覽器或搜索引擎）更新其鏈接或書簽。對于搜索引擎優化（SEO）來說，這意味著應將原先頁面的權重轉移給新的 URL。

搜索引擎優化：在SEO的背景下，使用 301 Moved Permanently 是管理網站結構變化的最佳實踐。它有助于維持舊 URL 的搜索排名和信譽，并將其傳遞給新 URL。

重定向方法：與臨時重定向（如 302 Found 或 307 Temporary Redirect）不同，301 是永久性的。這告訴客戶端在未來的所有請求中都應使用新的 URL，而不是臨時性地查找資源。

302 Found

表示請求的資源臨時位于不同的 URL，該狀態碼的使用場景如下。

臨時性重定向：當服務端返回 302 Found 響應時，它表明請求的資源現在暫時位于由 Location 頭部指定的不同 URI 中。與 301 Moved Permanently 不同，302 Found 表示這種重定向只是暫時的。

原始 URL 保持有效：服務端期望客戶端在未來的請求中繼續使用原始的 URL，這意味著臨時重定向后，原始 URL 仍然被視為有效。

搜索引擎處理：對于搜索引擎優化（SEO）來說，由于 302 Found 指示的是臨時重定向，搜索引擎通常保持對原始 URL 的索引，而不是轉移到新的地址。

其它用途：302 Found 也可以用于在網站維護期間或在進行 A/B 測試時，重定向到不同的 URL，同時保持原 URL 的有效性。

303 See Other

該狀態碼表示請求資源的響應需要通過另一個 URI 獲取，并且要通過 GET 方法訪問該 URI。

當服務端處理完 POST 請求（如表單提交）后，它可以發送 303 See Other 狀態碼，告訴客戶端通過 GET 方法從指定的 URI 獲取資源或信息，這樣做可以防止刷新頁面時重新提交表單。

所以 303 See Other 狀態碼在處理特定類型的 Web 請求（尤其是表單提交）并進行安全重定向時非常有用，它通過強制將后續請求的方法改為 GET，防止了表單重復提交這類問題。

304 Not Modified

該狀態碼表示從上次請求后，請求的資源未發生更改，因此客戶端可以繼續使用其緩存的版本。

關于資源緩存，這里解釋一下。當服務端返回的響應中包含以下字段，代表資源可以被緩存。

Cache-Control：這是最重要的緩存頭部之一，它可以設置多種指令來控制資源的緩存行為。如 max-age 指定資源可以緩存多久，no-cache 和 no-store 指示不緩存資源等。

• Cache-Control: max-age=3600，緩存 3600 秒；
• Cache-Control: no-cache，不緩存資源；
• Cache-Control: no-store，不緩存資源；

關于 no-cache 和 no-store，雖然都表示不緩存資源，但它們之間還是有一些區別的。

• no-cache 指示響應不應該被緩存，而是在每次請求時都要向服務端驗證其有效性。它并不意味著資源不能被緩存，而是在使用緩存的副本之前，客戶端（如瀏覽器）必須向服務端進行確認，檢查資源是否更新。這種方法通常用于保證獲取到的信息是最新的，同時仍然允許利用緩存來減少一些不必要的數據傳輸。
• no-store 是一種更加嚴格的指令，它告訴瀏覽器和中間緩存（如代理服務器），不應該存儲任何關于客戶端請求和服務端響應的信息。該指令通常用于敏感數據，如銀行頁面或個人資料頁面，確保這些數據在傳輸后不會留在緩存中，從而提供更高的隱私保護。

Expires：該頭部提供一個日期，該日期之后資源被認為過期。如果提供了 Cache-Control，那么 Expires 頭部通常會被忽略。

Last-Modified：指示資源最后被修改的時間，客戶端可以在后續的請求中使用 If-Modified-Since 頭部來檢查自該日期以來資源是否被修改。

ETag：提供資源的特定版本的標識，客戶端可以在后續請求中使用 If-None-Match 頭部，帶上這個標簽來檢查資源是否有更新。

當客戶端擁有某資源的緩存副本，并通過發送一個條件性請求（通常包含 If-Modified-Since 或 If-None-Match）來檢查資源是否更新時，如果資源未更新，服務端就會返回 304 Not Modified。這意味著客戶端無需下載該資源，可以使用其緩存的副本，否則將返回 200 OK 和新的資源。

因此和其它 HTTP 響應不同，304 Not Modified 響應通常不包含響應體，這是因為實際的內容沒有更改，不需要重新傳輸。

304 有助于減少不必要的網絡帶寬使用，因為它避免了重新下載未更改的資源。所以 304 常用于網頁和 Web 應用中，以優化性能，例如瀏覽器可能緩存網站的靜態資源，并在后續訪問時使用 If-Modified-Since 頭部來檢查這些資源是否已更新。

總的來說，304 Not Modified 狀態碼在管理 Web 資源緩存方面發揮著重要作用，減少了不必要的網絡流量和加載時間，從而提高了網站或 Web 應用的性能，特別是對于那些需要頻繁檢索大量靜態資源的網站。

307 Temporary Redirect

注：305 和 306 已經被廢棄了，這里簡單了解一下即可。

• 305 Use Proxy：該狀態碼表示請求的資源必須通過代理訪問，代理的地址由 Location 字段給出。
• 306 Switch Proxy：該狀態碼表示后續請求應使用不同的代理來訪問資源。

305 和 306 在現如今的網絡請求中不會遇到，因此簡單帶過，我們直接看 307。

首先 307 和 302 的作用相同，都表示臨時性重定向，即要訪問的資源臨時移動到了另一個 URI 上，但在 HTTP 方法的處理方面，兩者有所差異。

307 Temporary Redirect 要求客戶端在后續的重定向請求中使用與原始請求相同的 HTTP 方法。例如原始請求是一個 POST 請求，那么在重定向后，客戶端也必須使用 POST 方法發送到新的 URI。

而 302 Found 最初設計時也要求客戶端保持相同的請求方法，但在實際使用中，許多客戶端（如瀏覽器）會將后續的重定向請求改為 GET 方法，即使原始請求是 POST 或其它方法。雖然這種行為與 HTTP/1.1 規范不符，但已經成為事實上的標準。

所以 302、303、307 都表示臨時性重定向：

• 302 Found 的原始設計意圖是重定向時使用的方法不變，但許多客戶端（如瀏覽器）會默認使用 GET，當然也有客戶端沒有這么做。因此這就增加了模糊性，于是便有了 303 和 307；
• 303 See Other 明確指出客戶端在重定向時應該使用 GET 方法，無論原始請求使用的是哪種方法。因此 303 可以確保在處理完 POST 請求（如表單提交）后引導瀏覽器加載一個新頁面，并且刷新或后退操作不會再次提交表單；
• 307 Temporary Redirect 則明確指出重定向時，使用的請求方法要保持不變；

308 Permanent Redirect

308 和 301 是類似的，都表示永久性重定向，但 301 可能會導致請求方法從 POST 轉變為 GET，而 308 則明確要求請求方法保持不變。

以上就是 3xx 系列的狀態碼，它們使得資源的遷移、緩存、優化更加靈活和有效，是網絡基礎設施中不可或缺的一部分，幫助網站和應用程序管理資源的更改和更新。

4xx 狀態碼

4xx 系列的 HTTP 狀態碼表示客戶端錯誤，這些狀態碼指出請求中有錯誤，導致服務端無法或不會處理該請求。

400 Bad Request

該狀態碼表示由于客戶端錯誤，服務端無法處理請求，主要在以下情況發生。

• 無效的請求語法：請求的格式不正確，例如 HTTP 頭部格式錯誤或不完整。
• 錯誤的請求數據：請求數據有誤，例如無效的 JSON 數據，錯誤的參數；
• 大小問題：請求體過大，超過了服務端愿意處理的大小；
• 編碼問題：請求的編碼不被服務端支持；
• 無效的請求消息：請求中包含無效的消息，如錯誤的請求行或頭部；

400 Bad Request 是一個通用的錯誤響應，表明服務端因客戶端的錯誤而無法處理請求。這要求開發者對請求進行仔細檢查和調整，所以正確的請求格式、有效的數據和合適的編碼是避免這種錯誤的關鍵。

401 Unauthorized

該狀態碼表示請求未被服務端處理，因為它缺少有效的身份認證，主要在以下情況觸發：

• 未提供認證信息：當請求需要身份驗證，但客戶端沒有提供任何認證信息時。
• 認證失敗：即使提供了認證信息，如用戶名和密碼，但這些信息不正確或無法驗證。

需要注意的是，Unauthorized 這個單詞的意思是未授權，而不是未認證，所以用它來描述 401 就不太準確。關于認證和授權，這兩個概念容易讓人混淆，我們解釋一下。

認證（Authentication）就是驗證當前用戶的身份是否合法的過程，比如指紋打卡，當你的指紋和系統里錄入的指紋相匹配時，就打卡成功。像用戶名密碼登錄、郵箱發送登錄鏈接、手機接收驗證碼等等都屬于互聯網中的常見認證方式，只要你能收到驗證碼，就默認你是賬號的主人。認證主要是為了保護系統的隱私數據與資源。

授權（Authorization）則是誰（who）對什么（what）進行了什么操作（how），和認證不同，認證是確認用戶的合法性，以及讓服務端知道你是誰，而授權則是為了更細粒度地對資源進行權限上的劃分。所以授權是在認證通過后，控制不同的用戶訪問不同的資源。

并且授權是雙向的，可以是用戶給服務端授權，也可以是服務端給用戶授權。

• 用戶給服務端授權：比如你在安裝手機應用的時候，APP 會詢問是否允許授予權限（訪問相冊、地理位置等權限）；你在登錄微信小程序時，小程序會詢問是否允許授予權限（獲取昵稱、頭像、地區、性別等個人信息）。
• 服務端給用戶授權：比如你想追一個很火的劇，但被告知必須是 VIP 才能觀看，于是你充錢成為了 VIP，那么服務端便會給你授予觀看該劇（訪問該資源）的權限。

因此 401 狀態碼表示的是客戶端未認證，但 Unauthorized 的中文翻譯是未授權。

403 Forbidden

該狀態碼表示服務端理解客戶端的請求，但因客戶端沒有訪問請求資源的權限，所以服務端拒絕執行該請求，即使請求是有效的。

和 401 不同，返回 401 是因為請求缺少有效的身份憑證，導致服務端不知道客戶端的身份。而 403 意味著服務端知道客戶端是誰，只是它沒有足夠的權限來觸發請求的執行，因此拒絕訪問。

所以回顧一下認證和授權：

• 未認證是 Unauthenticated；
• 未授權是 Unauthorized；

我們發現 401 Unauthorized 改成 401 Unauthenticated 會更合理一些，而 403 Forbbiden 對應的才是 Unauthorized，因為沒有訪問資源的權限不就是未授權嗎，即客戶端未被授予訪問指定資源的權限。

認證和授權的中文很好區分，但英文就容易混淆了，因為長得比較像。

補充：為了安全起見，服務端可能會故意使用 404 Not Found 而非 403 Forbidden 來隱藏資源的存在，避免暴露敏感信息。

404 Not Found

這個應該是最知名的狀態碼了，它表示服務器找不到請求的資源。當客戶端請求的資源在服務器上不存在或者未被發現，就會返回 404。

出現 404，主要是以下幾個原因：

• 用戶輸入了錯誤的 URL；
• 本來存在的資源被刪除、移動或重命名，但卻沒有重定向；
• 服務器或網站的配置問題，導致無法訪問特定資源；

在 Web 開發中，我們通常也會自定義 404，比如你要找的頁面去火星了······，等等之類的。

雖然 404 通常被視為錯誤，但合適的處理和用戶友好的錯誤頁面可以在很大程度上改善用戶的瀏覽體驗。對于網站管理員和開發者而言，妥善管理和最小化 404 錯誤是提高網站質量和用戶滿意度的重要部分。

405 Method Not Allowed

該狀態碼表示客戶端以錯誤的 HTTP 方法去訪問請求的資源，比如一個資源只接受 GET 和 POST 請求，但客戶端嘗試使用 PUT 或 DELETE。

而當返回 405 Method Not Allowed 時，服務端通常會在響應頭中包含一個 Allow 字段，列出對該資源有效的請求方法。例如，Allow: GET, POST。

406 Not Acceptable

該狀態碼表示服務端無法提供與客戶端在請求的 Accept 頭字段中指定的內容特征相匹配的響應，換句話說，服務端無法生成客戶端期望的響應格式。

比如客戶端在 Accept 頭部中指定了一種服務端不支持的媒體類型（如 application/xml）。

另外當客戶端請求的語言（通過 Accept-Language 指定）或編碼（通過 Accept-Encoding 指定）服務端無法提供時，也可能返回此狀態碼。

對于開發者來說，這個狀態碼強調了內容協商機制的重要性，即服務端需要根據客戶端的要求提供不同格式的響應。對于終端用戶來說，遇到 406 錯誤通常意味著他們的客戶端（例如 Web 瀏覽器或應用）發送了服務端無法滿足的請求。在某些情況下，用戶可以嘗試更改請求的格式。

407 Proxy Authentication Required

與 401 類似，但它表示請求需要通過代理發送，而客戶端沒有通過代理服務器的認證。

以上是 4xx 系列比較常見的狀態碼，還有一些不常見的，我們簡單羅列一下。

• 408 Request Timeout：表示客戶端未在服務端預備等待的時間內完成請求的發送；
• 409 Conflict：表示請求與服務端當前狀態沖突，常見于并發編輯同一資源導致的問題；
• 410 Gone：表示請求的資源已被永久刪除，類似于 404，但它是永久性的，明確告知客戶端該位置永遠找不到指定的資源；
• 411 Length Required：服務端要求請求必須包含 Content-Length 頭部；
• 412 Precondition Failed：服務端未滿足請求頭中的一個或多個前提條件；
• 413 Payload Too Large：請求實體太大，服務端拒絕處理請求；
• 414 URI Too Long：請求的 URI 過長，服務端拒絕處理；
• 415 Unsupported Media Type：客戶端在其請求中指定了服務端無法或不愿處理的媒體類型，比如上傳一個服務端無法處理的文件格式。要注意它和 406 的區別：

406 指的是服務端無法生成客戶端接受的響應類型；

415 指的是服務端不支持客戶端上傳的文件類型；

• 416 Range Not Satisfiable：客戶端請求的范圍無法滿足；
• 417 Expectation Failed：服務器無法滿足 Expect 請求頭中的期望值；
• 429 Too Many Requests：客戶端發送的請求過多，通常用于限制請求速率；

4xx 系列的狀態碼提供了服務端對于特定錯誤情況的反饋，幫助客戶端開發者診斷問題并采取相應措施。

5xx 狀態碼

5xx 系列的 HTTP 狀態碼表示服務器錯誤，這些狀態碼表明客戶端的請求本身可能沒有問題，但由于服務器遇到問題而無法完成請求。

500 Internal Server Error

這是最常見的服務器錯誤狀態碼，表明服務端遇到了一個意外情況，阻止了其完成請求。比如服務端代碼報錯了，但又沒有異常捕獲，這個時候會直接拋出 500。

501 Not Implemented

該狀態碼表示服務器不支持當前請求所需要的功能，當服務器無法識別請求方法，并且無法支持其對任何資源的請求時，可能會返回這個狀態碼。

502 Bad Gateway

當服務器作為網關或代理，從上游服務器收到無效響應時，會返回此狀態碼。相信 502 大家也經常會遇到，伴隨而來往往是 NGINX。

NGINX 將請求轉發給后端服務，但后端服務報錯了，沒有提供正常響應，這時 NGINX 就會返回 502 給客戶端。因此當你看到 502 時，就應該知道 NGINX 代理正常工作，但它背后的服務出錯了。

503 Service Unavailable

該狀態碼表明服務器目前無法使用（由于超載或停機維護），通常這只是暫時狀態。

504 Gateway Timeout

當服務器作為網關或代理，沒有及時從上游服務器收到請求時，會返回這個狀態碼。

505 HTTP Version Not Supported

該狀態碼表明服務器不支持請求中使用的 HTTP 協議版本。

以上就是 5xx 系列常見的狀態碼，這些狀態??表示客戶端的請求正常，但問題出現在服務端。

小結

以上就是 HTTP 狀態碼，它是 Web 通信的核心組成部分，為理解客戶端和服務端之間的交互提供了基礎。這些狀態碼提供了關于請求是否成功，以及如果不成功，原因是什么的關鍵信息。

了解每個狀態碼的含義，可以讓我們在 Web 開發中迅速定位到問題。