https://www.tuicool.com/articles/UrUni2j

HTTP狀態碼（英語：HTTP Status Code）是用以表示網頁伺服器 超文字傳輸協議響應狀態的3位數字程式碼。

它由 RFC 2616 規範定義的，並得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 與 RFC 4918 等規範擴充套件。

HTTP狀態碼負責表示客戶端HTTP請求的返回結果、標記服務端的處理是否正常、通知出現的錯誤等工作。

狀態碼的類別

http狀態碼的由三位數字和原因短語組成，數字的第一位數字表示響應的類別，後面兩位無類別。以下有五種類別。另外只要遵循狀態碼類別的定義，即使改變RFC2616中定義的狀態碼，或者服務端自行建立狀態碼都可以。

1XX

• 類別：informational 資訊性狀態碼
• 原因短語：接收的請求正在處理

2XX

• 類別：success 成功狀態碼
• 原因短語：請求正常處理完畢

3XX

• 類別：redirection 重定向狀態碼
• 原因短語：需要進行附加操作以完成請求

4XX

• 類別：client error 客戶端錯誤狀態碼
• 原因短語：伺服器無法處理請求

5XX

• 類別：server error 伺服器錯誤狀態碼
• 原因短語：伺服器處理請求出錯

在RFC2616上的http狀態碼達到40多種，在加上WEBDAV和附加HTTP狀態碼（RFC6585）等擴充套件，就有60多種，但常用的有以下這些，接下來讓我們分別來學習下。

（注：以下的使用場景只是舉例，不包括所有使用場景）

1xx Informational 資訊響應

1XX 是資訊響應，表示接收的請求正在被處理。

100 Continue （繼續）

• 響應結果：資訊型狀態響應碼錶示目前為止一切正常, 客戶端應該繼續請求, 如果已完成請求則忽略.
• 使用場景：為了讓伺服器檢查請求的首部, 客戶端必須在傳送請求實體前, 在初始化請求中傳送 Expect: 100-continue 首部並接收 100 Continue 響應狀態碼.

101 Switching Protocols （協議切換）

• 響應結果：表示伺服器應客戶端升級協議的請求（Upgrade請求頭）正在進行協議切換。伺服器會發送一個Upgrade響應頭來表示其正在切換過去的協議。
• 使用場景： 
  在使用 WebSockets 時會用到協議切換。

  HTTP/1.1 101
   
   Switching Protocols
  Upgrade: websocket 
  Connection: Upgrade
  

2xx Successful 成功響應

2XX 表示請求被正常處理了。

200 OK （成功）

• 響應結果：請求成功，表示客戶端發來的請求在服務端被正常處理了。
• 不同的請求方法對請求成功的意義不同：
• • GET方法請求時，對應的請求資源實體會作為響應返回；
• • HEAD方法請求時，對應請求資源的實體首部不隨報文主體作為響應返回，即響應中只返回首部，不返回實體的主體部分；
• • POST方法請求時，響應的訊息體重包含請求的結果

201 Created （已建立）

• 響應結果：該請求已成功，並因此建立了一個新的資源。
• 使用場景：作為PUT請求的返回值。

202 Accepted（已接受）

• 響應結果：服務端收到請求，但未處理。
• 使用場景：這個狀態碼被設計用來將請求交由另外一個程序或者伺服器來進行處理，或者是對請求進行批處理的情形。

203 Non-Authoritative Information（非權威資訊）

• 響應結果：伺服器已成功處理了請求，但返回的實體頭部元資訊不是在原始伺服器上有效的確定集合，而是來自本地或者第三方的拷貝。當前的資訊可能是原始版本的子集或者超集。
• 使用場景：通過代理訪問原始伺服器的時候，成功獲取了原始伺服器（狀態碼200）的返回內容，但是代理對內容作出了一些改動，代理會通過這個狀態碼告知使用者，成功獲取內容，但是這部分內容和原始伺服器的返回內容可能不完全一致。

204 No Content (沒有內容)

• 響應結果：伺服器成功處理了客戶端請求，但伺服器無返回內容。204是HTTP中資料量最少的響應狀態，204的響應中沒有body，而且Content-Length=0。
• 使用場景：204狀態在一些網站分析的程式碼中最常用到，只需要把客戶端的一些資訊提交給伺服器而無需關心響應。

205 Reset Content (重置內容)

• 響應結果：伺服器成功處理了請求，且沒有返回任何內容。但是與204響應不同，返回此狀態碼的響應要求請求者重置文件檢視。
• 使用場景：用來通知客戶端重置文件檢視，比如清空表單內容、重置 canvas 狀態或者重新整理使用者介面。

206 Partial Content （部分內容）

• 響應結果：表示客戶端進行了範圍請求，而伺服器成功執行了這部分GET請求。響應報文中包含由Content-Range指定範圍的實體內容。
• 使用場景：類似於 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文件分解為多個下載段同時下載。該請求必須包含 Range 頭資訊來指示客戶端希望得到的內容範圍，並且可能包含 If-Range 來作為請求條件

3xx Redirection 重定向

3XX響應結果表明瀏覽器需要執行某些特殊的處理以正確的處理請求。

300 Multiple Choices （多項選擇）

• 響應結果：是一個用來表示重定向的響應狀態碼，表示該請求擁有多種可能的響應。使用者代理或者使用者自身應該從中選擇一個。
• 使用場景：由於沒有如何進行選擇的標準方法，這個狀態碼極少使用。

301 Moved Permanently（永久性重定向)

• 響應結果：表示請求的資源已被分配了新的URL，以後應使用現在所指的URL。也就是說如果已經吧資源對應的URL儲存為書籤了，這時應該按Location首部欄位提示的URL重新儲存。
• 使用場景：
• • 域名到期不想續費（或者發現了更適合網站的域名），想換個域名。
• • 在搜尋引擎的搜尋結果中出現了不帶www的域名，而帶www的域名卻沒有收錄，這個時候可以用301重定向來告訴搜尋引擎我們目標的域名是哪一個。
• • 空間伺服器不穩定，換空間的時候。

302 Found（臨時性重定向）

• 響應結果：該狀態碼錶示請求的資源已被分配了新的URL，希望使用者（本次）能使用新的URL訪問。
• 使用場景：儘量使用301！

303 See Other（參見其他）

• 響應結果：表示由於請求對應的資源存在這另一個URL，應使用GET方法定向獲取請求的資源。303與302不同之處在於，302是不會改變請求的方法，如果請求方法是POST的話，重定向的請求也應該是POST。而對於303，使用POST請求的話，重定向的請求應該是GET請求。
• 使用場景：未知。

304 Not Modified（未修改）

響應結果：該狀態碼錶示客戶端傳送附帶條件的請求（指採用GET方法的請求報文中包含）時，伺服器端允許請求訪問資源，但未滿足條件的情況。304狀態碼返回時，不包含任何響應的主體。304雖然在3xx類別中，但是和重定向沒關係。

• 使用場景：在 Web 頁面中檢視任務詳情時，要求能夠不重新整理頁面便自動的更新它的狀態與日誌等資訊（任務的執行會花費一定的時間，同時後臺在處理任務的過程中會同步它的狀態與日誌的更新）。因為任務的狀態更新可接受短暫的延時，所以不必採用長連線的方式，客戶端只需要定時往伺服器傳送獲取資料的請求即可，但是任務的資料量較大，如果任務並未發生改變，就查詢它全部的相關資訊並返回到客戶端對效能而言必然不是最優的選擇，所以我們需要在它發生改變後才查詢並返回資料，那麼這裡就可以引入 304 狀態碼來解決任務無變化時的返回結果。

305 Use Proxy （使用代理）

• 響應結果：被請求的資源必須通過指定的代理才能被訪問。
• 使用場景：未知。

306 (Unused)

在最新版的規範中，306狀態碼已經不再被使用。

307 Temporary Redirect （臨時重定向）

• 響應結果：該狀態碼與302有著相同的含義。儘管302標準禁止POST變換成GET，但實際使用時大家並不遵守。307會遵照瀏覽器標準，不會從POST變成GET。但是，對於處理響應時的行為，每種瀏覽器有可能出現不同的情況。
• 使用場景：同302

308 Permanent Redirect（永久重定向）

• 響應結果：是表示重定向的響應狀態碼，說明請求的資源已經被永久的移動到了由 Location 首部指定的 URL 上。瀏覽器會進行重定向，同時搜尋引擎也會更新其連結（用 SEO 的行話來說，意思是連結汁被傳遞到了新的 URL）。在重定向過程中，請求方法和訊息主體不會發生改變，然而在返回 301 狀態碼的情況下，請求方法有時候會被客戶端錯誤地修改為 GET 方法。
• 使用場景：一些 Web 應用可能會將 308 Permanent Redirect 以一種非標準的方式使用以及用作其他用途。例如，Google Drive 會使用 308 Resume Incomplete 狀態碼來告知客戶端檔案上傳終止且不完整。

4xx Client Error客戶端響應

4XX的響應結果表明客戶端是發生錯誤的原因所在。

400 Bad Request（壞請求）

• 響應結果：該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需要修改請求的內容後再次傳送請求。另外，瀏覽器會像200OK一樣對待該狀態碼。
• 出現原因：語義有誤，當前請求無法被伺服器理解。除非進行修改，否則客戶端不應該重複提交這個請求。請求引數有誤。

401 Unauthorized（未授權）

-響應結果：表示傳送的請求需要有通過HTTP認證的認證資訊。另外若之前已進行過一次請求，則表示使用者認證失敗。返回含有401響應必須包含一個適用於被請求資源的WWW-Authenticate 首部用以質詢使用者資訊。當瀏覽器初次接收到401響應，會彈出認證用的對話視窗。

• 出現原因：客戶端錯誤，指的是由於缺乏目標資源要求的身份驗證憑證，傳送的請求未得到滿足。

402 Payment Required（要求付款）

• 響應結果：此響應碼保留以便將來使用，創造此響應碼的最初目的是用於數字支付系統，然而現在並未使用。

403 Forbidden （禁止）

• 響應結果：對請求資源的訪問伺服器拒絕了。伺服器端沒有必要給出拒絕的詳細理由，但如果想作說明的話，可以在實體的主題部分對原因進行描述，這樣就能讓使用者看到了。
• 出現原因：未獲得檔案系統的訪問授權，訪問許可權出現某些問題（從未授權的傳送源IP地址試圖訪問）等列舉情況都可能是發生403的原因。

404 Not Found（未找到）

• 響應結果：表明伺服器上無法找到請求的資源。
• 使用場景：伺服器找不到資源時，或者伺服器拒絕請求又不想說明理由時。

405 Method Not Allowed（不允許使用的方法）

• 響應結果：請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭資訊用以表示出當前資源能夠接受的請求方法的列表。
• 出現原因：鑑於 PUT，DELETE 方法會對伺服器上的資源進行寫操作，因而絕大部分的網頁伺服器都不支援或者在預設配置下不允許上述請求方法，對於此類請求均會返回405錯誤。

406 Not Acceptable（無法接受）

• 響應結果：表示客戶端錯誤，指代伺服器端無法提供與 Accept-Charset 以及 Accept-Language 訊息頭指定的值相匹配的響應
• 出現原因：在實際應用中，這個錯誤狀態碼極少使用：不是給使用者返回一個晦澀難懂（且難以更正）的錯誤狀態碼，而是將相關的訊息頭忽略，同時給使用者提供一個看得見摸得著的頁面。這種做法基於這樣一個假設：即便是不能達到使用者十分滿意，也強於返回錯誤狀態碼。

如果伺服器返回了這個錯誤狀態碼，那麼訊息體中應該包含所能提供的資源表現形式的列表，允許使用者手動進行選擇。

407 Proxy Authentication Required(要求進行代理認證)

• 響應結果：代表客戶端錯誤，指的是由於缺乏位於瀏覽器與可以訪問所請求資源的伺服器之間的代理伺服器（proxy server ）要求的身份驗證憑證，傳送的請求尚未得到滿足。
• 使用場景：這個狀態碼會與 Proxy-Authenticate 首部一起傳送，其中包含有如何進行驗證的資訊。

//響應示例
HTTP/1.1 407 Proxy Authentication Required 
Date: Wed, 21 Oct 2015 07:28:00 GMT
Proxy-Authenticate: Basic realm="Access to internal site"

408 Request Timeout（請求超時）

• 響應結果：遇到408意味著你的請求傳送到該網站花的時間比該網站的伺服器準備等待的時間要長，即連結超時。408錯誤往往難以解決，通常涉及系統工作量或系統操作中的一次性變化。
• 出現原因：如果使用者持續看到408錯誤，管理員首先要考慮到Web伺服器的工作量，特別是在產生408錯誤的時間段，另外網路流量激增也可能導致使用者無法訪問網頁從而出現該錯誤。

409 Conflict（衝突）

• 響應結果：表示請求與當前伺服器端的狀態相沖突。
• 出現原因：衝突最有可能發生在對 PUT 請求的響應中。例如，當上傳檔案的版本比伺服器上已存在的要舊，從而導致版本衝突的時候，那麼就有可能收到狀態碼為 409 的響應。

410 Gone（消失了）

• 響應結果：說明請求的內容在伺服器上不存在了，同時是永久性的丟失。如果不清楚是否為永久或臨時的丟失，應該使用404 。

411 Length Required（要求長度指示）

• 響應結果：屬於客戶端錯誤，表示由於缺少確定的Content-Length 首部欄位，伺服器拒絕客戶端的請求。

412 Precondition Failed（先決條件失敗）

• 響應結果:（先決條件失敗）表示客戶端錯誤，意味著對於目標資源的訪問請求被拒絕。
• 出現場景：這通常發生於採用除 GET 和 HEAD 之外的方法進行條件請求時，由首部欄位 If-Unmodified-Since 或 If-None-Match 規定的先決條件不成立的情況下。這時候，請求的操作——通常是上傳或修改檔案——無法執行，從而返回該錯誤狀態碼。

413 Payload Too Large（請求實體太大）

• 響應結果：表示請求主體的大小超過了伺服器規定的限度，伺服器可以選擇關閉連線或者返回 Retry-After 首部欄位。

414 URI Too Long（請求URI太長）

• 響應結果：表示客戶端所請求的 URI 超過了伺服器允許的範圍。
• 出現原因：
• • 當客戶端誤將 POST 請求當作 GET 請求的時候，會帶有一個常常的查詢字串(query)；
• • when the client has descended into a loop of redirection (for example, a redirected URI prefix that points to a suffix of itself)
• • 當客戶端對伺服器進行攻擊，試圖尋找潛在的漏洞的時候。

415 Unsupported Media Type（不支援的媒體型別）

• 響應結果：是一種HTTP協議的錯誤狀態程式碼，表示伺服器由於不支援其有效載荷的格式，從而拒絕接受客戶端的請求。
• 出現原因：格式問題的出現有可能源於客戶端在 Content-Type 或 Content-Encoding 首部中指定的格式，也可能源於直接對負載資料進行檢測的結果。

416 Requested Range Not Satisfiable （所請求的範圍未得到滿足）

• 響應結果：伺服器無法處理所請求的資料區間，最常見的情況是所請求的資料區間不在檔案範圍之內。一則 416 應答訊息包含有一個 Content-Range 首部，提示無法滿足的資料區間（用星號 * 表示），後面緊跟著一個“/”，再後面是當前資源的長度。例如：

遇到這一錯誤狀態碼的時候，瀏覽器一般有兩種策略：一種是終止操作，例如，一項中斷的下載操作被認為是不可恢復的；另外一種是再次請求整個檔案。

417 Expectation Failed（無法滿足期望）

• 響應結果：客戶端錯誤，意味著伺服器無法滿足 Expect 請求訊息頭中的期望條件。

426 Upgrade Required（需要升級）

• 響應結果：是一種HTTP協議的錯誤狀態程式碼，表示伺服器拒絕處理客戶端使用當前協議傳送的請求，但是可以接受其使用升級後的協議傳送的請求。

伺服器會在響應中使用 Upgrade 首部來指定要求的協議。

//示例
HTTP/1.1 426 Upgrade Required 
Upgrade: HTTP/3.0 
Connection: Upgrade 
Content-Length: 53 
Content-Type: text/plain 

This service requires use of the HTTP/3.0 protocol

428 Precondition Required（先決條件要求）

• 響應結果：表示伺服器端要求傳送條件請求。
• 出現原因：一般的，這種情況意味著必要的條件首部——如 If-Match ——的缺失。.

當一個條件首部的值不能匹配伺服器端的狀態的時候，應答的狀態碼應該是 412 Precondition Failed，前置條件驗證失敗。

429 Too Many Requests（請求太多）

表示在一定的時間內使用者傳送了太多的請求，即超出了“頻次限制”。

431 Request Header Fields Too Large

• 響應主體：表示在一定的時間內使用者傳送了太多的請求，即超出了“頻次限制”。在響應中，可以提供一個 Retry-After 首部來提示使用者需要等待多長時間之後再發送新的請求。

  //示例
  HTTP/1.1 429 Too Many Requests
  Content-Type: text/html
  Retry-After: 3600
  

431 Request Header Fields Too Large

• 響應主體：表示由於請求中的首部欄位的值過大，伺服器拒絕接受客戶端的請求。客戶端可以在縮減首部欄位的體積後再次傳送請求。

• 應用場景：該響應碼可以用於首部總體體積過大的情況，也可以用於單個首部體積過大的情況。

  這種錯誤不應該出現於經過良好測試的投入使用的系統當中，而是更多出現於測試新系統的時候

451 Unavailable For LegalReason（因法律原因不可用）

• 響應結果：是一種HTTP協議的錯誤狀態程式碼，表示伺服器由於法律原因，無法提供客戶端請求的資源，例如可能會導致法律訴訟的頁面。

  <!--
  這個響應示例來自 IETF RFC 規範（見下文），其中提到了英國戲劇電影Monty Python's Life of Brian （《蒙提·派森之布萊恩的一生》）。
  
  注意 Link 首部中可能會包含一個 rel="blocked-by" 欄位，用於標明為該資源無法提供負責的主體，例如頒佈法令將資源刪除的個人或組織的名稱。
  -->
  HTTP/1.1 451 Unavailable For Legal Reasons
  Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
  Content-Type: text/html
  
  <html>
  <head><title>Unavailable For Legal Reasons</title></head>
  <body>
  <h1>Unavailable For Legal Reasons</h1>
  <p>This request may not be serviced in the Roman Province
  of Judea due to the Lex Julia Majestatis, which disallows
  access to resources hosted on servers deemed to be
  operated by the People's Front of Judea.</p>
  </body>
  </html>
  

5xx Server Error 伺服器錯誤

5XX 響應結果表明伺服器本身發生錯誤。

500 Internal Server Error（內部資源出錯）

• 響應結果：表明伺服器端在執行請求時發生了錯誤。也有可能是Web應用存在的bug或某些臨時的故障。
• 解決方案：這個錯誤程式碼是一個通用的“全方位”響應程式碼。通常伺服器管理員對於類似於 500 這樣的錯誤會更加詳細地記錄相關的請求資訊來防止以後同樣錯誤的出現。

501 Not Implemented

• 響應結果：伺服器錯誤響應碼錶示請求的方法不被伺服器支援，因此無法被處理。伺服器必須支援的方法（即不會返回這個狀態碼的方法）只有 GET 和 HEAD。

• 解決方法：你無法修復 501 錯誤，需要被訪問的 web 伺服器去修復該問題。

502 Bad Gateway

• 響應結果：是一種HTTP協議的伺服器端錯誤狀態程式碼，它表示扮演閘道器或代理角色的伺服器，從上游伺服器中接收到的響應是無效的。
• 解決方法：502 錯誤通常不是客戶端能夠修復的，而是需要由途徑的Web伺服器或者代理伺服器對其進行修復。

503 Service Unavailable

• 響應結果：表明伺服器暫時處於超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的視覺，最好寫入Retry-After首部欄位在返回給客戶端。
• 出現原因：在伺服器503錯誤出現了之後，大家不必擔心的， 伺服器或許就是正在維護或者暫停了，你可以聯絡一下伺服器空間商。還有的時候cpu佔用的頻率大導致的。

504 Gateway Timeout（閘道器超時）

• 響應結果：與狀態嗎408類似， 但是響應來自閘道器或代理，此閘道器或代理在等待另一臺伺服器的響應時出現了超時

505 HTTP Version Not Supported（不支援的HTTP版本）

• 響應結果：伺服器收到的請求使用了它不支援的HTTP協議版本。 有些伺服器不支援HTTP早期的HTTP協議版本，也不支援太高的協議版本

511 Network Authentication Required

• 響應結果：表示客戶端需要通過驗證才能使用該網路。該狀態碼不是由源頭伺服器生成的，而是由控制網路訪問的攔截代理伺服器生成的。
• 出現原因：網路運營商們有時候會在准許使用網路之前要求使用者進行身份驗證、接受某些條款，或者進行其他形式的與使用者之間的互動（例如在網路咖啡廳或者機場）。他們通常用使用者裝置的 MAC 地址來進行識別。

以上就是常見的一些狀態碼，如有不正確的地方，歡迎指正。

參考連結：