首先得明白狀態碼的幾個大類：

接下來具體分析詳細的狀態碼：

1xx：表示臨時響應
100：（繼續）請求者應當繼續提出請求。伺服器返回此程式碼表示已收到請求的第一部分，正在等待其餘部分
101：（切換協議）請求者已要求伺服器切換協議，伺服器已確認並準備切換

2xx：表示成功處理了請求的狀態程式碼

200 OK
請求已成功。響應返回的資訊取決於請求中使用的方法，例如：在響應中傳送GET對應於所請求資源的實體;HEAD對應於所請求資源的實體頭欄位資訊只存在於響應報文首部，因為它不會返回報文實體，只返回報文首部;POST返回實體;
201 Created
請求已完成，並導致建立新資源。新建立的資源可以由響應實體中返回的URI引用，具有Location頭欄位給出的資源的最特定URI。響應應該包括一個實體，其中包含資源特徵和位置的列表，使用者或使用者代理可以從中選擇最合適的資源特徵和位置。實體格式由Content-Type頭欄位中給出的媒體型別指定。原始伺服器必須在返回201狀態程式碼之前建立資源。如果無法立即執行操作，伺服器應該響應202（已接受）響應。
202 Accepted
該請求已被接受處理，但處理尚未完成。該請求最終可能會或可能不會被執行，因為在實際處理時可能不允許該請求。沒有用於從諸如此類的非同步操作重新發送狀態程式碼的工具。
202回覆是故意不承諾的。其目的是允許伺服器接受對某些其他程序的請求（可能是每天只執行一次的面向批處理的程序），而不要求使用者代理與伺服器的連線一直持續到程序完成為止。使用此響應返回的實體應該包括請求的當前狀態的指示，以及指*向狀態監視器的指標或使用者可以期望滿足請求的某些估計。
204 No Content*
表示請求已成功處理，但是沒有內容返回（就應該沒有內容返回的狀況）
也就是返回的響應報文中沒有報文實體（其實是沒有報文實體的主體部分）
瀏覽器向伺服器傳送請求後收到了204，那麼瀏覽器頁面不會發生更新
一般用在只是客戶端向伺服器傳送資訊，而伺服器不用向客戶端返回什麼資訊的情況
206 Reset Content
表示伺服器已經完成了部分GET請求（客戶端進行了範圍請求）
響應報文中包含Content-Range指定範圍的實體內容

3xx（重定向）：表示要完成請求，需要進一步操作。通常，這些狀態程式碼用來重定向

301 永久性轉移
瀏覽器在拿到伺服器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取（使用者看到的效果就是他輸入的地址A瞬間變成了另一個地址B），舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜尋引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址
302短暫性轉移
臨時重定向，表示請求的資源臨時搬到了其他位置
表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜尋引擎會抓取新的內容而儲存舊的網址。
303 See Other
表示請求資源存在另一個URI，應使用GET定向獲取請求資源
303功能與302一樣，區別只是303明確客戶端應該使用GET訪問
303 表示請求的資源路徑發生改變，使用GET方法請求新url。她與302的功能一樣，但是明確指出使用GET方法請求新url（第一次請求返回的location）。

4xx（請求錯誤）：這些狀態程式碼表示請求可能出錯，妨礙了伺服器的處理

400 Bad Request
表示請求報文存在語法錯誤或引數錯誤，伺服器不理解，伺服器不應該重複提交這個請求，需要修改請求內容後再次傳送。
原因以及解決思路： 1:前端提交資料的欄位名稱或者是欄位型別和後臺的實體類不一致，導致無法封裝；最常見的可能就是後端使用@RequestBody 接收，先仔細排查一遍，不行的話，使用@RequestParam再逐一看一下是否可以封裝進去
2：前端提交的到後臺的資料應該是json字串型別，而前端沒有將物件轉化為字串型別；這個比較簡單，使用JSON.stringify(param) 轉換成json字串

401 Unauthorized
表示傳送的請求需要有HTTP認證資訊或者是認證失敗了
返回401的響應必須包含一個適用於被請求資源的WWW-Authenticate首部以質詢使用者資訊
瀏覽器初次接受401時，會彈出認證視窗

403 Forbidden
    返回403狀態碼就是，拒絕或者禁止訪問。但是，伺服器雖然拒絕或者禁止訪問，但是它已經理解了你的請求。
具體原因有以下多種：
     錯誤程式碼：403.1
     HTTP 403.1 禁止訪問：禁止可執行訪問 Internet 資訊服務 原因是執行許可權不夠，解決的方法是： 開啟“管理工具”的“Internet 資訊服務”，右鍵選擇“WEB站點屬性”的“主目錄”選項卡，把“執行許可”的選項從“無”改為“純指令碼”就好了。
     錯誤程式碼：403.2
     403.2錯誤是由於”讀取”訪問被禁止而造成的。導致此錯誤是由於沒有可用的預設網頁並且沒有對目錄啟用目錄瀏覽，或者要顯示的 HTML 網頁所駐留的目錄僅標記為”可執行”或”指令碼”許可權。
     錯誤程式碼：403.3
     403.3錯誤是由於”寫入”訪問被禁止而造成的，當試圖將檔案上載到目錄或在目錄中修改檔案，但該目錄不允許”寫”訪問時就會出現此種錯誤。
     錯誤程式碼：403.4
     403.4錯誤是由於要求SSL而造成的，您必須在要檢視的網頁的地址中使用”https”。
     錯誤程式碼：403.5
     403.5錯誤是由於要求使用 128 位加密演算法的 Web 瀏覽器而造成的，如果您的瀏覽器不支援128位加密演算法就會出現這個錯誤，您可以連線微軟網站進行瀏覽器升級。
     錯誤程式碼：403.6
     403.6錯誤是由於IP 地址被拒絕而造成的。如果伺服器中有不能訪問該站點的 IP 地址列表，並且您使用的 IP 地址在該列表中時您就會返回這條錯誤資訊。
     錯誤程式碼：403.7
     403.7錯誤是因為要求客戶證書，當需要訪問的資源要求瀏覽器擁有伺服器能夠識別的安全套接字層 (SSL) 客戶證書時會返回此種錯誤。
404 Not Found
     表示伺服器找不到你請求的資源。
405 Method Not Allowed
      請求行中指定的方法不允許由Request-URI標識的資源。響應必須包含一個Allow標頭，其中包含所請求資源的有效方法列表。
413 Request Entity Too Large
伺服器拒絕處理請求，因為請求實體大於伺服器願意或能夠處理的請求實體。伺服器可以關閉連線以防止客戶端繼續請求。
如果條件是臨時的，伺服器應該包括一個Retry-After頭欄位，以指示它是臨時的，並且在客戶端可以再次嘗試之後。
414 Request-URI Too Long
伺服器拒絕為請求提供服務，因為Request-URI比伺服器願意解釋的長。這種罕見的情況是隻可能當客戶端已經不正確地將POST請求轉換到具有長查詢資訊的GET請求中，當客戶端已陷入URI重定向“黑洞”發生（例如，一個重定向的URI指向字首它本身的字尾，或者當伺服器受到試圖利用固定長度緩衝區來讀取或操作Request-URI的某些伺服器中存在的安全漏洞的客戶端的攻擊時。
415 Unsupported Media Type
伺服器拒絕為請求提供服務，因為請求的實體採用所請求方法的請求資源不支援的格式。

416（請求範圍不符合要求）如果頁面無法提供請求的範圍，則伺服器會返回此狀態碼

428 Precondition Required (要求先決條件)
先決條件是客戶端傳送 HTTP 請求時，如果想要請求能成功必須滿足一些預設的條件。
一個好的例子就是 If-None-Match 頭，經常在 GET 請求中使用，如果指定了 If-None-Match ，那麼客戶端只在響應中的 ETag 改變後才會重新接收回應。
先決條件的另外一個例子就是 If-Match 頭，這個一般用在 PUT 請求上用於指示只更新沒被改變的資源，這在多個客戶端使用 HTTP 服務時用來防止彼此間不會覆蓋相同內容。
當伺服器端使用 428 Precondition Required 狀態碼時，表示客戶端必須傳送上述的請求頭才能執行請求，這個方法為伺服器提供一種有效的方法來阻止 'lost update' 問題。

429 Too Many Requests (太多請求)
當你需要限制客戶端請求某個服務數量時，該狀態碼就很有用，也就是請求速度限制。
在此之前，有一些類似的狀態碼，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （這不是HTTP定義的狀態碼）
如果你希望限制客戶端對服務的請求數，可使用 429 狀態碼，同時包含一個 Retry-After 響應頭用於告訴客戶端多長時間後可以再次請求服務。

431 Request Header Fields Too Large (請求頭欄位太大)
某些情況下，客戶端傳送 HTTP 請求頭會變得很大，那麼伺服器可傳送 431 Request Header Fields Too Large 來指明該問題。
我不太清楚為什麼沒有 430 狀態碼，而是直接從 429 跳到 431，我嘗試搜尋但沒有結果。唯一的猜測是 430 Forbidden 跟 403 Forbidden 太像了，為了避免混淆才這麼做的，天知道！

5xx（伺服器錯誤）這些狀態程式碼表示伺服器在嘗試處理請求時發生內部錯誤。這些錯誤可能是伺服器本身的錯誤，而不是請求出錯

500 Internal Server Error
表示伺服器執行請求的時候出錯了，可能是伺服器端的bug,但是也可能是前端的問題，比如後臺報了序列化錯誤，可能就是因為你的前端沒有設定content-type=application/json

502 Bad Gateway
伺服器在充當閘道器或代理時，在嘗試完成請求時從其訪問的上游伺服器收到無效響應。

503 Bad Gateway
由於伺服器的臨時過載或維護，伺服器當前無法處理請求。這意味著這是一個暫時的條件，經過一段時間的延遲後會得到緩解。如果已知，延遲的長度可以在Retry-After報頭中指示。如果沒有給出Retry-After，客戶端應該像處理500響應一樣處理響應。

注意：503狀態程式碼的存在並不意味著a
伺服器必須在變得過載時使用它。有些伺服器可能希望
簡單地拒絕連線。

504（閘道器超時）伺服器作為閘道器或者代理，但是沒有及時從上游伺服器收到請求
505（HTTP版本不受支援）伺服器不支援請求中所用的HTTP協議版本

511 Network Authentication Required (要求網路認證)
對我來說這個狀態碼很有趣，如果你在開發一個 HTTP 伺服器，你不一定需要處理該狀態碼，但如果你在編寫 HTTP 客戶端，那這個狀態碼就非常重要。
如果你頻繁使用筆記本和智慧手機，你可能會注意到大量的公用 WIFI 服務要求你必須接受一些協議或者必須登入後才能使用。
這是通過攔截HTTP流量，當用戶試圖訪問網路返回一個重定向和登入，這很討厭，但是實際情況就是這樣的。

使用這些“攔截”客戶端，會有一些討厭的副作用。在 RFC 中有提到這兩個的例子：

如果你在登入WIFI前訪問某個網站，網路裝置將會攔截首個請求，這些裝置往往也有自己的網站圖示 ‘favicon.ico'。登入後您會發現，有一段時間內你訪問的網站圖示一直是WIFI登入網站的圖示。
如果客戶端使用HTTP請求來查詢文件（可能是JSON），網路將會響應一個登入頁，這樣你的客戶端就會解析錯誤並導致客戶端執行異常，在現實中這種問題非常常見。
因此 511 狀態碼的提出就是為了解決這個問題。

如果你正在編寫 HTTP 的客戶端，你最好還是檢查 511 狀態碼以確認是否需要認證後才能訪問。

---------------------
作者：coderV
來源：CSDN
原文：https://blog.csdn.net/pulong0748/article/details/81838086