NGINX 502錯誤排查（轉）

1、NGINX 502錯誤排查
NGINX 502 Bad Gateway錯誤是FastCGI有問題，形成NGINX 502錯誤的可能性比較多。將網上找到的一些和502 Bad Gateway錯誤有關的問題和排查方法列一下，先從FastCGI配置入手：
1.FastCGI進程是否已經啓動
2.FastCGI worker進程數是否不夠
運行 netstat -anpo | grep 「php-cgi」 | wc -l 判斷是否接近FastCGI進程，接近配置文件中設置的數值，代表worker進程數設置太少
3.FastCGI執行時間過長
根據實際狀況調高如下參數值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.FastCGI Buffer不夠
nginx和apache同樣，有前端緩衝限制，能夠調整緩衝參數
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
5.Proxy Buffer不夠
若是你用了Proxying，調整
proxy_buffer_size   16k;
proxy_buffers    4 16k;
參見：http://www.server110.com
6.https轉發配置錯誤
正確的配置方法
server_name www.mydomain.com;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}
固然，還要看你後端用的是哪一種類型的FastCGI，我用過的有php-fpm，流量約爲單臺機器40萬PV(動態頁面), 如今基本上沒有碰到502。

7.php腳本執行時間過長
將php-fpm.conf的<value name="request_terminate_timeout">0s</value>的0s改爲一個時間

2、Nginx 413錯誤的排查:修改上傳文件大小限制
在上傳時nginx返回了413錯誤，查看log文件，顯示的錯誤信息是:」413 Request Entity Too Large」, 因而在網上找了下「nginx 413錯誤」發現須要作如下設置：
在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

3、Nginx 400錯誤排查：HTTP頭/Cookie過大
今天有人彙報nginx的HTTP400錯誤，並且這個HTTP400錯誤並非每次都會出現的，查了一下發現nginx400錯誤是因爲request header過大，一般是因爲cookie中寫入了較長的字符串所引發的。
解決方法是不要在cookie裏記錄過多數據，若是實在須要的話能夠考慮調整在nginx.conf中的client_header_buffer_size(默認1k)
若cookie太大，可能還須要調整large_client_header_buffers(默認4k)，該參數說明以下：
請求行若是超過buffer，就會報HTTP 414錯誤(URI Too Long)
nginx接受最長的HTTP頭部大小必須比其中一個buffer大，不然就會報400的HTTP錯誤(Bad Request)。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經執行，可是因爲某種緣由（通常是讀取資源的問題）沒有執行完畢而致使PHP-CGI進程終止。
Nginx 504 Gateway Time-out的含義是所請求的網關沒有請求到，簡單來講就是沒有請求到能夠執行的PHP-CGI。

解決這兩個問題實際上是須要綜合思考的，通常來講Nginx 502 Bad Gateway和php-fpm.conf的設置有關，而Nginx 504 Gateway Time-out則是與nginx.conf的設置有關。
而正確的設置須要考慮服務器自身的性能和訪客的數量等多重因素。
以我目前的服務器爲例子CPU是奔四1.5G的，內存1GB，CENTOS的系統，訪客大概是50人左右同時在線。
可是在線的人大都須要請求PHP-CGI進行大量的信息處理，所以我將nginx.conf設置爲：
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;#8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
這裏最主要的設置是前三條，即
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
這裏規定了PHP-CGI的鏈接、發送和讀取的時間，300秒足夠用了，所以個人服務器不多出現504 Gateway Time-out這個錯誤。最關鍵的是php-fpm.conf的設置，這個會直接致使502 Bad Gateway和504 Gateway Time-out。
下面咱們來仔細分析一下php-fpm.conf幾個重要的參數：
php-fpm.conf有兩個相當重要的參數，一個是」max_children」,另外一個是」request_terminate_timeout」
個人兩個設置的值一個是」40″，一個是」900″，可是這個值不是通用的，而是須要本身計算的。
計算的方式以下：
若是你的服務器性能足夠好，且寬帶資源足夠充足，PHP腳本沒有系循環或BUG的話你能夠直接將」request_terminate_timeout」設置成0s。0s的含義是讓PHP-CGI一直執行下去而沒有時間限制。而若是你作不到這一點，也就是說你的PHP-CGI可能出現某個BUG，或者你的寬帶不夠充足或者其餘的緣由致使你的PHP-CGI可以假死那麼就建議你給」request_terminate_timeout」賦一個值，這個值能夠根據你服務器的性能進行設定。通常來講性能越好你能夠設置越高，20分鐘-30分鐘均可以。因爲個人服務器PHP腳本須要長時間運行，有的可能會超過10分鐘所以我設置了900秒，這樣不會致使PHP-CGI死掉而出現502 Bad gateway這個錯誤。

而」max_children」這個值又是怎麼計算出來的呢？這個值原則上是越大越好，php-cgi的進程多了就會處理的很快，排隊的請求就會不多。設置」max_children」也須要根據服務器的性能進行設定，通常來講一臺服務器正常狀況下每個php-cgi所耗費的內存在20M左右，所以個人」max_children」我設置成40個，20M*40=800M也就是說在峯值的時候全部PHP-CGI所耗內存在800M之內，低於個人有效內存1Gb。而若是個人」max_children」設置的較小，好比5-10個，那麼php-cgi就會「很累」，處理速度也很慢，等待的時間也較長。若是長時間沒有獲得處理的請求就會出現504 Gateway Time-out這個錯誤，而正在處理的很累的那幾個php-cgi若是遇到了問題就會出現502 Bad gateway這個錯誤。

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

nginx中配置php fastcgi組解決莫名其妙的502 Bad Gateway錯誤

通常nginx搭配php都採用這樣的方式：

location ~ .php$ {
proxy_pass        http://localhost:9000;
fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name;
include        fastcgi_params;
}

這個方式只能鏈接到一組spawn-fcgi開啓的fastcgi，在服務器負載稍高時經常出現502 bad gateway錯誤。

起先懷疑這是php-cgi的進程開得太少，增長後仍然有反映時常有錯，偶然間發現php-cgi會報出這樣的錯誤：

zend_mm_heap corrupted

看來是php-cgi在執行某些代碼時有問題，以至於該線程停止。

在服務器上可能還會看到php-cgi進程在不斷變少，估計是出現錯誤的php-cgi的進程自動退出了。

php的問題老是不太容易能解決，因此在nginx方面想一想辦法，nginx的好處是它老是能爆出一些稀奇古怪的作法出來。

在nginx的proxy中，規避莫名其妙錯誤的辦法無非是proxy到一個upstream的服務器組中，而後配置 proxy_next_upstream，讓nginx遇到某種錯誤碼時，自動跳到下一個後端上。這樣，應用服務器即便不穩定，可是在nginx後面就變成了穩定服務。想到nginx的fastcgi和proxy是一路東西，因此proxy能用的經驗，移植到fastcgi也能跑得起來。

照着這個思路，用spawn-fcgi多開一樣一組php進程，所不一樣的僅僅是端口：

spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f php-cgi -C 100
spawn-fcgi -a 127.0.0.1 -p 9001 -u nobody -f php-cgi -C 100

而後把fastcgi的這段配置改爲用upstream的方式：

upstream backend {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}

location ~ .php$ {
fastcgi_pass        backend;
fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name;
include        fastcgi_params;
}

檢查配置結果正確，能跑起來；同時在服務器上netstat -n|grep 9000和grep 9001都有記錄，證實鏈接無誤；在前臺查閱頁面，一切運行正常。

這個配置是最簡單的配置，既然能鏈接上upstream，那麼很顯然upstream的一些東西均可以拿來用，好比ip_hash、weight、max_fails等。

這樣的配置在單機下不知能不能共享session，沒有測試，若是有問題，能夠加上ip_hash，或者配置php把session存進memcached中。

而後就是fastcgi_next_upstream的配置，nginx wiki中沒有介紹到這個配置，查了一下，在nginx的CHANGES中有提到，並且出生年月是和proxy_next_upstream同樣的。既然如此，那就照proxy_next_upstream同樣配吧。通常按默認的值error timeout就能夠工做，由於php出現502錯誤的異常是返回的500錯誤，因此我把fastcgi_next_upstream定爲：

fastcgi_next_upstream error timeout invalid_header http_500;

經過這個配置，就能夠基本杜絕任什麼時候常性的500錯誤，出問題的概率會變小不少，若是客戶反映仍然激烈，那麼就多增長几組fastcgi進程。

以上配置可以杜絕因爲php所引發的「莫名其妙」的時常性的502錯誤，同時可以使nginx搭配php比從前方式更爲強悍。假如nginx仍是返回502錯誤，那此次就必定是出現服務器掛掉或其它嚴重問題的了。