如何理解HTTP響應的狀態碼

HTTP 響應狀態代碼指示特定 HTTP 請求是否已成功完成。狀態代碼由 section 10 of RFC 2616定義。響應分爲五類：

• 1xx：信息
• 2xx：成功
• 3xx：重定向
• 4xx：客戶端錯誤
• 5xx：服務器錯誤

通常故障排除提示

• 當使用Web瀏覽器測試Web服務器時，在更改服務器後刷新瀏覽器
• 檢查服務器日誌以獲取有關服務器如何處理請求的更多詳細信息。 例如，網絡服務器，如Apache或Nginx的生成兩個文件名爲access.log和error.log ，能夠爲相關的信息進行掃描。
• 請記住：HTTP狀態代碼定義是由提供請求的應用程序實現的標準的一部分。 這意味着返回的實際狀態代碼取決於服務器軟件如何處理特定錯誤 – 本指南一般應該指向正確的方向

一些常見的狀態碼爲：

1xx（臨時響應）表示臨時響應並須要請求者繼續執行操做的狀態代碼。

這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應只包含狀態行和某些可選的響應頭信息，並以空行結束。

因爲HTTP/1.0協議中沒有定義任何1xx狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送1xx響應。

100（繼續）：迄今爲止的全部內容都是可行的，客戶端應該繼續請求，若是已經完成，則忽略它。

服務器已經接收到請求頭，而且客戶端應繼續發送請求主體（在須要發送身體的請求的狀況下：例如，POST請求），或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。要使服務器檢查請求的頭部，客戶端必須在其初始請求中發送Expect: 100-continue做爲頭部，並在發送正文以前接收100 Continue狀態代碼。

101 （切換協議）：該代碼是響應客戶端的 Upgrade 標頭髮送的，而且指示服務器也正在切換的協議。

服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。

只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP版本（如HTTP/2）比舊版本更有優點，或者切換到一個實時且同步的協議（如WebSocket）以傳送利用此類特性的資源。

102 Processing（WebDAV；RFC 2518）：

WebDAV請求可能包含許多涉及文件操做的子請求，須要很長時間才能完成請求。該代碼表示服務器已經收到並正在處理請求，但無響應可用。這樣能夠防止客戶端超時，並假設請求丟失。

103 Early Hints： 此狀態代碼主要用於與Link 連接頭一塊兒使用，以容許用戶代理在服務器仍在準備響應時開始預加載資源。

2xx （成功） 表示請求已成功被服務器接收、理解、並接受。

200（成功）：請求已成功，請求所但願的響應頭或數據體將隨此響應返回。

成功的含義取決於HTTP方法：

• GET：資源已被提取並在消息正文中傳輸。
• HEAD：實體標頭位於消息正文中。
• POST：描述動做結果的資源在消息體中傳輸。
• TRACE：消息正文包含服務器收到的請求消息

201（已建立）：該請求已成功，並所以建立了一個新的資源。這一般是在POST請求，或是某些PUT請求以後返回的響應。

202（已接受）：服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止。如：須要的資源沒法及時建立。

203（非受權信息）（自HTTP / 1.1起）：服務器已成功處理了請求，但返回的信息可能來自另外一來源。

204（無內容）：服務器成功處理了請求，沒有返回任何內容。

205（重置內容）：服務器成功處理了請求，但沒有返回任何內容。

可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。

206 （部份內容）：服務器成功處理了部分 GET 請求。實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。如：視頻播放時的數據加載請求。

該請求必須包含 Range 頭信息來指示客戶端但願獲得的內容範圍，而且可能包含 If-Range 來做爲請求條件。

207 （多狀態）：由WebDAV(RFC 2518)擴展的狀態碼，表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。

208 (已報告) （WebDAV；RFC 5842）：在 DAV 裏面使用: propstat 響應元素以免重複枚舉多個綁定的內部成員到同一個集合。

226（IM Used）（RFC 3229）：服務器已經完成了對資源的 GET 請求，而且響應是對當前實例應用的一個或多個實例操做結果的表示。

3xx （重定向） 表示要完成請求，須要進一步操做。

表示要完成請求，須要進一步操做。 一般，這些狀態代碼用來重定向。

當且僅當後續的請求所使用的方法是GET或者HEAD時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。客戶端應當自動監測無限循環重定向（例如：A→B→C→……→A或A→A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。按照HTTP/1.0版規範的建議，瀏覽器不該自動訪問超過5次的重定向。

300（多種選擇）：被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。

若是服務器自己已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。

301 （永久移除）：請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。

若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。

新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。若是這不是一個GET或者HEAD請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求獲得了一個301響應的話，接下來的重定向請求將會變成GET方式。

302（臨時移動）：服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。

只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。

新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。

若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。所以狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。

303（查看其餘位置）：對應當前請求的響應能夠在另外一個 URI 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。

同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。

新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。

許多HTTP/1.1版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。

304 （未修改）：表示資源未被修改，由於請求頭指定的版本If-Modified-Since或If-None-Match。在這種狀況下，因爲客戶端仍然具備之前下載的副本，所以不須要從新傳輸資源。

304 響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。

305（使用代理）：被請求的資源必須經過指定的代理才能被訪問。

Location 域中將給出指定的代理所在的 URI 信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。

RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。

306（臨時重定向）： 在最新版的規範中，306狀態碼已經再也不被使用。

307（臨時重定向）： 請求的資源如今臨時從不一樣的URI 響應請求。

因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。

308（永久重定向）：這意味着資源如今永久位於由 Location: HTTP Response 標頭指定的另外一個 URI。

這意味着資源如今永久位於由 Location: HTTP Response 標頭指定的另外一個 URI。 這與 301 Moved Permanently HTTP 響應代碼具備相同的語義，但用戶代理不能更改所使用的 HTTP 方法：若是在第一個請求中使用 POST，則必須在第二個請求中使用 POST。

4xx（客戶端錯誤）表示請求可能出錯，妨礙了服務器的處理。

這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個HEAD請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。

若是錯誤發生時客戶端正在傳送數據，那麼使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的鏈接以前，客戶端已經收到了包含錯誤信息的數據包。若是客戶端在收到錯誤信息後繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端全部還未識別的輸入緩衝，以避免這些數據被服務器上的應用程序讀取並干擾後者。

400（錯誤請求）：因爲明顯的客戶端錯誤，服務器不能或不會處理該請求。

• 語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。
• 請求參數有誤。好比：傳參的數據結構不對
• 請求格式有誤。如：因爲瀏覽器故障，致使請求格式錯誤
• 參數數據量太大
• 無效的請求消息或欺騙性路由請求
• 與該網站相關聯的用戶Cookie已損壞。 清除瀏覽器的緩存和Cookie能夠解決此問題
• 惡意代碼的請求因爲人爲錯誤手動造成HTTP請求時（例如，使用curl錯誤）

401（未受權）： 請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。

當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。

注意：當網站（一般是網站域名）禁止IP地址時，有些網站狀態碼顯示的401，表示該特定地址被拒絕訪問網站。

402 （要求付費）：此響應碼保留以便未來使用，創造此響應碼的最初目的是用於數字支付系統，然而如今並未使用。

若是特定開發人員已超過請求的每日限制，Google Developers API會使用此狀態碼。

403（禁止）：服務器已經理解請求，可是拒絕執行它。

與 401 響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個 HEAD 請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個 404 響應，假如它不但願讓客戶端得到任何信息。

• 執行訪問被禁止。
• 讀訪問被禁止。
• 寫訪問被禁止。
• 要求 SSL。
• 要求 SSL 128。
• IP 地址被拒絕。
• 要求客戶端證書。
• 站點訪問被拒絕。
• 用戶數過多。
• 配置無效。
• 密碼更改。
• 拒絕訪問映射表。
• 客戶端證書被吊銷。
• 拒絕目錄列表。
• 超出客戶端訪問許可。
• 客戶端證書不受信任或無效。
• 客戶端證書已過時或還沒有生效。
• 在當前的應用程序池中不能執行所請求的 URL。
• 不能爲這個應用程序池中的客戶端執行 CGI。
• Passport 登陸失敗。

404（未找到）： 請求失敗，請求所但願獲得的資源未被在服務器上發現。

沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。

• 資源的連接是否有打字錯誤？
• 用戶鍵入的網址有誤嗎？
• 文件是否存在於服務器上的正確位置？ 資源是否已在服務器上移動或刪除？
• 服務器配置是否具備正確的文檔根位置？
• 擁有Web服務器工做進程的用戶是否有權限遍歷到請求的文件所在的目錄？ （提示：目錄須要訪問讀取和執行權限）
• 訪問的資源是不是符號連接？ 若是是，請確保Web服務器配置爲遵循符號連接

405（方法禁用）：請求行中指定的請求方法（post、get、put、delete等）不能被用於請求相應的資源。

該響應必須返回一個Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。 鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。

406（（不接受） ）：請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。

除非這是一個HEAD請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。

407（（須要代理受權））：與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。

代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端能夠返回一個 Proxy-Authorization 信息頭用以驗證。

408（（請求超時） ）：請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。

409（衝突）：因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。

這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。如：多個同步更新之間的編輯衝突。

410（已刪除）：被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。

這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用 404 狀態碼。除非額外說明，不然這個響應是可緩存的。

411（須要有效長度）：服務器拒絕在沒有定義 Content-Length 頭的狀況下接受請求。在添加了代表請求消息體長度的有效 Content-Length 頭以後，客戶端能夠再次提交該請求。

412（前提條件失敗）：服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。

413（請求實體過大）：服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。

此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。若是這個情況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。

414（請求的 URI 過長）：請求的URI 長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。

• 本應使用POST方法的表單提交變成了GET方法，致使查詢字符串（Query String）過長。
• 重定向URI「黑洞」，例如每次重定向把舊的URI做爲新的URI的一部分，致使在若干次重定向後URI超長。
• 客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操做請求的URI，當GET後的參數超過某個數值後，可能會產生緩衝區溢出，致使任意代碼被執行。

415（不支持的媒體類型） ：對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。

416（請求範圍不符合要求） （RFC 7233）：若是請求中包含了 Range 請求頭，而且 Range 中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義 If-Range 請求頭。

417（未知足指望值）：此響應代碼意味着服務器沒法知足 Expect 請求標頭字段指示的指望值。

418 （I'm a teapot）（RFC 2324）：本操做碼是在1998年做爲IETF的傳統愚人節笑話，在RFC 2324超文本咖啡壺控制協議中定義的，並不須要在真實的HTTP服務器中定義。當一個控制茶壺的HTCPCP收到BREW或POST指令要求其煮咖啡時應當回傳此錯誤。

這個HTTP狀態碼在某些網站（包括Google.com）與項目（如Node.js、ASP.NET和Go語言）中用做彩蛋。

420（保持冷靜）：Twitter Search與Trends API在客戶端被限速的狀況下返回。

421（錯誤請求）（RFC 7540）：該請求針對的是沒法產生響應的服務器。 這能夠由服務器發送，該服務器未配置爲針對包含在請求 URI 中的方案和權限的組合產生響應。

422 （沒法處理的實體）（WebDAV；RFC 4918 ）：請求格式良好，但因爲語義錯誤而沒法遵循。

423 （鎖定）（WebDAV；RFC 4918）：正在訪問的資源被鎖定。

424 （依賴）（WebDAV；RFC 4918）：因爲先前的請求失敗，因此這次請求失敗。

425 （太早了）：服務器不肯意冒着風險去處理可能重播的請求。如：安全驗證未完成。

426 （須要升級）（RFC 2817）：服務器拒絕使用當前協議執行請求，但可能在客戶機升級到其餘協議後願意這樣作。

428 （須要前提條件） (RFC 6585)：原始服務器要求該請求是有條件的。 旨在防止「丟失更新」問題，即客戶端獲取資源狀態，修改該狀態並將其返回服務器，同時第三方修改服務器上的狀態，從而致使衝突。

429 （請求過多） （RFC 6585）：用戶在給定的時間內發送了太多請求（「限制請求速率」）。

431 （請求頭過大）（RFC 6585）：服務器不肯意處理請求，由於它的 請求頭字段太大（ Request Header Fields Too Large）。 請求能夠在減少請求頭字段的大小後從新提交。

444 (不響應)：Nginx上HTTP服務器擴展。服務器不向客戶端返回任何信息，並關閉鏈接（有助於阻止惡意軟件）。

450（被Windows家長控制系統阻止）：這是一個由Windows家庭控制（Microsoft）HTTP阻止的450狀態代碼的示例，用於信息和測試。

451（因爲法律緣由沒法使用）：用戶請求非法資源，例如：由政府審查的網頁。

5xx（服務器錯誤） 表示服務器在嘗試處理請求時發生內部錯誤。

這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個HEAD請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。這些狀態碼適用於任何響應方法。

500（內部服務器錯誤）：通用錯誤消息，服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。

這此錯誤最多見的緣由是服務器配置錯誤（例如，一個畸形.htaccess文件）或缺失的軟件包（如試圖在沒有安裝正確PHP執行的PHP文件）。

501（還沒有實施）：此請求方法不被服務器支持且沒法被處理。只有GET和HEAD是要求服務器支持的，它們一定不會返回此錯誤代碼。

502（錯誤網關）：這意味着服務器的網關或代理服務器，它沒有收到來自實際應該履行請求的後端服務器的有效響應。

若是有問題的服務器是逆向代理服務器，例如負載均衡器，則須要檢查如下幾項：

• 後端服務器（HTTP請求轉發到的）是正常的
• 正確配置逆向代理，指定適當的後端
• 後端服務器和逆向代理服務器之間的網絡鏈接是正常的。 若是服務器能夠在其餘端口上通訊，請確保防火牆容許它們之間的流量
• 若是Web應用程序配置爲偵聽套接字，請確保套接字存在於正確的位置，而且具備適當的權限

503（服務不可用）： 表示服務器超載或正在維護。 這個錯誤意味着服務應該在某個時候可用。

請注意，與此響應一塊兒，應發送解釋問題的用戶友好頁面。 這個響應應該用於臨時條件和 Retry-After：若是可能的話，HTTP頭應該包含恢復服務以前的估計時間。 網站管理員還必須注意與此響應一塊兒發送的與緩存相關的標頭，由於這些臨時條件響應一般不該被緩存。

若是服務器未處於維護狀態，則這能夠指示服務器沒有足夠的CPU或內存資源來處理全部傳入的請求，或者Web服務器須要配置爲容許更多的用戶，線程或進程

504（網關超時）：當服務器做爲網關，不能及時獲得響應時返回此錯誤代碼。

• 服務器之間的網絡鏈接不好
• 因爲性能不佳，履行請求的後端服務器太慢
• 網關或代理服務器的超時持續時間過短

505 （HTTP 版本不受支持）：服務器不支持請求中所使用的HTTP協議版本。

506 （協商引發的異常）（RFC 2295）：對請求的透明內容協商致使循環引用。

507 （存儲不足）（WebDAV；RFC 4918）：服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。

508 （循環檢測）（WebDAV；RFC 5842）：服務器在處理請求時陷入死循環。 可代替 208狀態碼

510 （擴展不足）（RFC 2774）：獲取資源所須要的策略並無被知足，客戶端須要對請求進一步擴展，服務器才能實現它。服務器會回覆客戶端發出擴展請求所需的全部信息。

511 （網絡身份驗證要求） （RFC 6585）：客戶端須要進行身份驗證才能得到網絡訪問權限，旨在限制用戶羣訪問特定網絡。如：鏈接WiFi熱點時的強制網絡門戶

參考連接

MDN HTTP 響應代碼