首先得明白狀態碼的幾個大類：
| 狀態碼 | 響應類別 | 出現原因 |
|---|---|---|
| 1XX | 信息性狀態碼（Informational） | 服務器正在處理請求 |
| 2XX | 成功狀態碼（Success） | 請求已正常處理完畢 |
| 3XX | 重定向狀態碼（Redirection） | 需要進行額外操作以完成請求 |
| 4XX | 客戶端錯誤狀態碼（Client Error） | 客戶端原因導致服務器無法處理請求 |
| 5XX | 服務器錯誤狀態碼（Server Error） | 服務器原因導致處理請求出錯 |
接下來具體分析詳細的狀態碼：
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）。
304（未修改）
自從上次請求后，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。
如果網頁自請求者上次請求后再也沒有更改過，您應將服務器配置為返回此響應（稱為 If-Modified-Since HTTP 標頭）。服務器可以告訴 Googlebot 自從上次抓取后網頁沒有變更，進而節省帶寬和開銷。
305（使用代理）
請求者只能使用代理訪問請求的網頁。如果服務器返回此響應，還表示請求者應使用代理。
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 狀態碼以確認是否需要認證后才能訪問。
參考原文：https://blog.csdn.net/pulong0748/article/details/81838086