Nginx常見錯誤程式碼總結和處理方案
目錄
302定義
302 redirect: 302 代表暫時性轉移(Temporarily Moved )。
意思就是你訪問網址A，但是網址A因為伺服器端的攔截器或者其他後端程式碼處理的原因，會被重定向到網址B。
我這裡出現302錯誤的原因是由於我的後端程式碼寫了攔截器Filter，當從網站A訪問帶有某關鍵詞路徑的介面時就會被攔截，因而我將網站A要訪問的介面的關鍵詞進行了修改，使其不會被攔截器攔截，就能正常從後端獲取資料了。
作者：weberweber
連結：https://www.jianshu.com/p/ad4f8ab8bbd6
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。
403錯誤
403是很常見的錯誤程式碼，一般就是未授權被禁止訪問的意思。
可能的原因有兩種：
Nginx程式使用者無許可權訪問web目錄檔案
Nginx需要訪問目錄，但是autoindex選項被關閉
修復方法：
授予Nginx程式使用者許可權讀取web目錄檔案
設定autoindex目錄為on
location /path/to/website/folder {
...
autoindex on;
... }
413錯誤
在上傳時Nginx返回了413錯誤：“413 Request Entity Too Large”，這一般就是上傳檔案大小超過Nginx配置引起。
修復方法：
在Nginx.conf增加client_max_body_size的設定，這個值預設是1M，可以增加到8M以提高檔案大小限制；
如果執行的是php，那麼還要檢查php.ini，這個大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，這樣就不會因為提交資料大小不一致出現的錯誤。
post_max_size = 8M
upload_max_filesize = 2M
499錯誤
日誌記錄中HTTP狀態碼出現499錯誤有多種情況，我遇到的一種情況是nginx反代到一個永遠打不開的後端，就這樣了，日誌狀態記錄是499、傳送位元組數是0。
給業務部門做一個代理使用google docs 。總是莫名奇妙的反饋打不開，發現nginx日誌下報了很多499 。
499錯誤是什麼？讓我們看看NGINX的原始碼中的定義：
ngx_string(ngx_http_error_495_page), /* 495, https certificate error */
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string, /* 499, client has closed connection */
可以看到，499對應的是 “client has closed connection”。這很有可能是因為伺服器端處理的時間過長，客戶端“不耐煩”了。
Nginx 499錯誤的原因及解決方法
開啟Nginx的access.log發現在最後一次的提交是出現了HTTP1.1 499 0 -這樣的錯誤，在百度搜索nginx 499錯誤，結果都是說客戶端主動斷開了連線。
但經過我的測試這顯然不是客戶端的問題，因為使用埠+IP直接訪問後端伺服器不存在此問題，後來測試nginx發現如果兩次提交post過快就會出現499的情況，看來是nginx認為是不安全的連線，主動拒絕了客戶端的連線.
但搜尋相關問題一直找不到解決方法，最後終於在google上搜索到一英文論壇上有關於此錯誤的解決方法：
proxy_ignore_client_abort on;
Don’t know if this is safe.
就是說要配置引數 proxy_ignore_client_abort on;
表示代理服務端不要主動關閉客戶端連線。
以此配置重啟nginx,問題果然得到解決。只是安全方面稍有欠缺，但比總是出現找不到伺服器好多了。
還有一種原因是 我後來測試發現 確實是客戶端關閉了連線,或者說連線超時 ,無論你設定多少超時時間多沒用 原來是php程序不夠用了 改善一下php程序數 問題解決 預設測試環境才開5個子程序。
502錯誤
Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經執行，但是由於某種原因（一般是讀取資源的問題）沒有執行完畢而導致PHP-CGI程序終止。一般來說Nginx 502 Bad Gateway和php-fpm.conf的設定有關。
修復方法：
1、檢視FastCGI程序是否已經啟動
ps -aux | grep php-cgi
2、檢查系統Fastcgi程序執行情況
除了第一種情況，fastcgi程序數不夠用、php執行時間長、或者是php-cgi程序死掉也可能造成Nginx的502錯誤。
執行以下命令判斷是否接近FastCGI程序，如果fastcgi程序數接近配置檔案中設定的數值，表明worker程序數設定太少。
netstat -anpo | grep "php-cgi" | wc -l
3、FastCGI執行時間過長
根據實際情況調高以下引數值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
504錯誤
Nginx 504 Gateway Time-out的含義是所請求的閘道器沒有請求到，簡單來說就是沒有請求到可以執行的PHP-CGI。
Nginx 504 Gateway Time-out一般與Nginx.conf的設定有關。
頭部太大這種情況可能是由於Nginx預設的fastcgi程序響應的緩衝區太小造成的， 這將導致fastcgi程序被掛起，如果你的fastcgi服務對這個掛起處理的不好，那麼最後就極有可能導致504 Gateway Time-out。
預設的fastcgi程序響應的緩衝區是8K，可以調大以下引數：
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
fastcgi_busy_buffers_size 由 128K 改為 256K；
fastcgi_temp_file_write_size 由 128K 改為 256K。
此外，也可能是php-cgi的問題，需要修改php.ini的配置：
將max_children由之前的10改為30，這樣操作是為了保證有充足的php-cgi程序可以被使用。
將request_terminate_timeout由之前的0秒改成60秒，這樣使php-cgi程序處理指令碼的超時時間提高到60秒，可以防止程序被掛起以提高利用效率。