當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。 當瀏覽器接收并顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。 HTTP狀態碼由三個十進制數字組成，三位數字代碼分別代表著不同的請求狀態，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。

壞境搭建

本文的測試需要的linux+nginx+PHP環境，可以不需要MySQL。搭建環境的資料如下： lnmp.zip

http狀態碼分類

1. 消息類（1字頭）
2. 成功類（2字頭）
3. 重定向類（3字頭）
4. 請求錯誤類（4字頭）
5. 服務器錯誤類（5、6字頭）

中途可能會穿插nginx自定義的http狀態碼，nginx狀態碼本身不屬于http狀態碼了，只是在nginx內部自己定義的一套狀態碼，但是在nginx日志中，卻經常出現

請求錯誤類（客戶端錯誤）

400

400的英文含義400 Request Header Or Cookie Too Large，顧名思義，頭信息或者Cookie信息太多了 復現這個狀態碼只需要添加夠長的頭信息或者Cookie信息即可，構造一個curl請求：

  curl --header "Cookie:sidisisidisidisisidisidisisidisidisisidisidisisidisidisisidisidisidisisidisisidisidisisidisidisisidisidisisidisidisisidisidisisidisidissidisisidisidisisidisidisisidisidisisidisidisisidisidisisidisidissidisisidisidisisidisidisisidisidisisidisidisisidisidisisidisidissidisisidisidisisidisidisisidisidisisidisidisisidisidisisidisidissidisisidisidisisidisidisisidisidisisidisidisisidisidisisi....." http://localhost:80

執行這個curl命令可以看到提示：

401

401的含義是401 Authorization Required,顧名思義，就是需要權限認證，但是客戶端又沒有通過認證。復現這個狀態碼必須對nginx調整成認證模式。現在，將nginx調成認證模式，nginx的server模塊配置如下

  location / {    auth_basic "secret";#認證模式    auth_basic_user_file /usr/local/nginx/passwd.db;#密碼文件    root   html2;    index  index.html index.htm;}

接下來生成密碼文件

  sh-3.2# htpasswd -c /usr/local/nginx/passwd.db yongxiongzhongNew password: Re-type new password: Adding password for user yongxiongzhong

更改權限

  chmod 400 /usr/local/nginx/passwd.db

平滑重啟nginx之后，再次訪問網頁可以看到認證界面 點擊取消按鈕，則可以看到以下這個頁面

403

403的出現，大部分是沒有對文件進行授權。403 Forbidden顧名思義就是禁止訪問，重現這個狀態碼只需要修改訪問文件的權限，比如給nginx網站根目錄中的index文件減少權限

  chmod 0 /usr/local/nginx/html/index.html

當我們再次訪問這個文件是，就會出現403錯誤

404

404算是我們經常碰到的狀態碼，404 Not Found當我們訪問一個不存在的文件時，就會出現這個錯誤 在URL地址欄上隨便訪問一個不存在的文件，就會出現 在實際生產環境中，這樣的404頁面并不好看，所以可以通過在server中配置自定義404頁面：

  error_page  404              /my_404.html;

其中在網站根目錄新建my_404.html然后寫入自定義內容。平滑重啟nginx之后，再次訪問一些不存在的頁面時會提示如下：

405

405狀態碼并不算常見，它表示405 Not Allowed。http請求可以支持GET，POST，PUT，DELETE方式。默認情況下，如果你對一個html靜態文件進行post請求的話，就會出現405錯誤

413

413也是比較容易出現的一種狀態碼，413的出現常常伴隨著413 Request Entity Too Large表示請求實體過大導致。用戶上傳的Content-Length大于nginx設定的最大值時。比如上傳一張很大的圖片，就會出現413錯誤碼 這個是由參數client_max_body_size控制的，默認是1M。有點小，所以一般線上環境調成以下配置即可消除上面的問題

  client_max_body_size 8m;

414

一般出現這個錯誤的時候，也伴隨著一段英文提示414 Request-URI Too Large，也就是說我們請求的url太長了，如果我們把一個很長的url放在瀏覽器地址欄上，瀏覽器的保護措施，并不會出現414報錯。所以要重現這個414錯誤碼，只能通過curl命令。申請如下一個很長的url,篇幅問題，最后用…代替：

  curl http://localhost:8080/?key=abcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefg....

運行這個curl命令，就可以看到414錯誤 在nginx中，以下兩個參數共同決定這個問題

  client_header_buffer_sizelarge_client_header_buffers

499(nginx status)

499這個狀態碼并不是http協議中定義的status code，而是nginx自己定義的一個狀態碼。 當客戶端主動斷開連接的時候，nginx就會返回499的狀態碼。按照這個狀態碼的定義，復現這個狀態碼很容易，只要在nginx返回結果之前斷開客戶端連接。所以，下一個data.php文件

  <?phpsleep (10);//睡覺10秒鐘

然后在瀏覽器訪問http://localhost:8000/data.php,注意，在10秒之內關閉瀏覽器以斷開客戶端連接。然后在查看nginx訪問日志就能看到499錯誤 值得一提的是，在線上環境中，如果并發量大的話，nginx未能及時處理完請求，導致客戶端“不干了”，這是會大量爆發499錯誤。這種情況可以用ab工具測試，ab工具中，-n為請求次數，-c為并發量：

  ab -n 100 -c 100 http://127.0.0.1:8000/data.php

再觀察我們的nginx訪問日志，會發現大量的499

服務端錯誤

500

http狀態碼500表示內部服務器錯誤，這個錯誤一般是php代碼出現error導致，如果你沒有關閉php錯誤提示，當寫一個錯誤的php腳本時，網頁上會出現以下錯誤提示 但是一般情況下這些錯誤我們并不希望就這樣暴露給客戶端，因為將這些錯誤信息暴露是一件很危險的事情，別人可以通過你的錯誤猜測系統漏洞。所以在線上一般是關閉錯誤顯示，關閉方式為：編輯php-fpm.conf關閉錯誤信息，保存php-fpm以下設置項

  php_flag[display_errors] = off

平滑重啟php-fpm進程之后，再次訪問一個包含錯誤語法的php錯誤的時候，會報500錯誤。

502

當出現502這個錯誤的時候，也伴隨著一句英文502 bad geteway，很醒目的一段問題，出現這個錯誤的時候，因為這是服務端錯誤，可以定位掛掉了。Nginx 502錯誤的原因比較多，是因為在代理模式下后端服務器出現問題引起的。這些錯誤一般都不是nginx本身的問題，一定要從后端找原因。比如這里復現一種后端php-fpm進程掛掉的情況，關閉php-fpm

  kill -9 `ps aux | grep php-fpm | grep -v grep | awk -F ' ' '{print $2}'`

再次訪問我們的php文件時候，然后就可以看到網站掛掉的情況

503

注意，出現503的時候服務沒掛，出現503的時候伴隨著503 Service Temporarily Unavailable,這句話告訴我們服務是暫時性不可用，nginx官方文檔上有說明這一點，

?

Sets the shared memory zone and the maximum allowed number of connections for a given key value. When this limit is exceeded, the server will return the 503 (Service Temporarily Unavailable) error in reply to a request.

簡單的說，就是在控制請求頻率和并發數，詳細配置可以參考nginx官方文檔：http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html#limit_conn 這里只復現一種可能的情況，將nginx配置如下(兩個核心配置，省去了很多)：

  http {    limit_conn_zone $binary_remote_addr zone=addr:10m;    server {        limit_conn addr 1;#并發數為1，好測試

注意測試的時候，不是所有的連接都算進去，也就是并發數為1，并不代表只能并發1，nginx說明：

?

Not all connections are counted. A connection is counted only if it has a request processed by the server and the whole request header has already been read.

然后采用ab測試工具，運行如下命令

  ab -n 2 -c 2 http://127.0.0.1:8000/data.php

查看nginx訪問日志，可以看到503報錯信息

504

當出現504的時候也伴隨著一段英文，504 Gateway Time-out，顧名思義，就是超時了，復現這個錯誤碼也很簡單。讓你的php程序模擬耗時請求，比如把php腳本里添加以下內容

  <?phpsleep (70);//模擬耗時，睡70秒echo "睡醒了";

然后通過域名訪問這個腳本文件，就會出現超時的界面

重定向和緩存

301和302

之所以將這兩個狀態碼放到一起，因為他們都是重定向，其中，301永久重定向，302暫時重定向。不管是暫時還是臨時，對用戶而言，這兩者沒什么區別，都是在訪問A網站的時候跳轉到了B網站，并看到瀏覽器上的地址欄變成了B網站的地址。有區別的是搜索引擎，搜索引擎是要建立索引規則和權重的，如果網站A被設定為永久重定向到B，那搜索引擎可以確定A的地址永久改變了，就會把B當做唯一有效的目標地址，這是搜索引擎會把老地址的PageRank等信息帶到新地址，同時在搜索引擎索引庫中徹底廢棄掉原先的老地址。所以，所以只要網站不是臨時性遷移，都會做301重定向。 在nginx的rewrite語法中有兩個關鍵字 permanent——永久重定向 redirect——臨時重定向 如果我們想要將.asp文件永久重定向到index頁面

  location ~ \.asp$ {    rewrite ^(.*)$ /index.html permanent;}

如果只想臨時重定向到index頁面。

  location ~ \.asp$ {    rewrite ^(.*)$ /index.html redirect;}

再次訪問頁面是可以看到302沖重定向了,同樣，瀏覽器地址欄上的地址變成了重定向后的地址

304

304 Not Modified,默認情況下，nginx會對靜態文件進行緩存。為了節省網絡寬帶，nginx和瀏覽器會產生如下交互

  1. 瀏覽器客戶端想請求一個文檔，如果瀏覽器本地已經有緩存了，發送If-Modified-Since給Web服務器2. 服務器將文件最后修改時間將服務器的文檔修改時間Last-Modified和瀏覽器發送過來的If-Modified-Since比較，如果兩者一致，返回304給瀏覽器，告訴瀏覽器用本地緩存就好了，如果兩者不一致，返回200給瀏覽器，告訴瀏覽器使用最新的文檔

在默認情況下，在瀏覽器中輸入http://localhost:8000/test.css請求css文件兩次就會出現304

如果在服務器端編輯test.css文件，由于這個時間文件最后修改時間發生了變更，這時服務器不會返回304狀態碼了。這時返回200狀態碼,兩個的時間不一樣了，瀏覽器采用最新的。