一、NGINX 502錯誤排查

NGINX 502 Bad Gateway錯誤是FastCGI有問題，造成NGINX 502錯誤的可能性比較多。將網(wǎng)上找到的一些和502 Bad Gateway錯誤有關(guān)的問題和排查方法列一下，先從FastCGI配置入手：

1.FastCGI進(jìn)程是否已經(jīng)啟動

2.FastCGI worker進(jìn)程數(shù)是否不夠

運(yùn)行 netstat -anpo | grep “php-cgi” | wc -l 判斷是否接近FastCGI進(jìn)程，接近配置文件中設(shè)置的數(shù)值，表明worker進(jìn)程數(shù)設(shè)置太少

3.FastCGI執(zhí)行時間過長

根據(jù)實(shí)際情況調(diào)高以下參數(shù)值

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

4.FastCGI Buffer不夠

nginx和apache一樣，有前端緩沖限制，可以調(diào)整緩沖參數(shù)

fastcgi_buffer_size 32k;

fastcgi_buffers 8 32k;

5.Proxy Buffer不夠

如果你用了Proxying，調(diào)整

proxy_buffer_size 16k;

proxy_buffers 4 16k;

6.https轉(zhuǎn)發(fā)配置錯誤

正確的配置方法

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;
}

當(dāng)然，還要看你后端用的是哪種類型的FastCGI，我用過的有php-fpm，流量約為單臺機(jī)器40萬PV(動態(tài)頁面), 現(xiàn)在基本上沒有碰到502。

7.php腳本執(zhí)行時間過長

將php-fpm.conf的0s的0s改成一個時間

二、Nginx 413錯誤的排查:修改上傳文件大小限制

在上傳時nginx返回了413錯誤，查看log文件，顯示的錯誤信息是:”413 Request Entity Too Large”, 于是在網(wǎng)上找了下“nginx 413錯誤”發(fā)現(xiàn)需要做以下設(shè)置：

在nginx.conf增加 client_max_body_size的相關(guān)設(shè)置, 這個值默認(rèn)是1m，可以增加到8m以增加提高文件大小限制；

如果運(yùn)行的是php，那么還要檢查php.ini，這個大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，這樣就不會因?yàn)樘峤粩?shù)據(jù)大小不一致出現(xiàn)的錯誤。

post_max_size = 8M

upload_max_filesize = 2M

三、Nginx 400錯誤排查：HTTP頭/Cookie過大

今天有人匯報nginx的HTTP400錯誤，而且這個HTTP400錯誤并不是每次都會出現(xiàn)的，查了一下發(fā)現(xiàn)nginx400錯誤是由于request header過大，通常是由于cookie中寫入了較長的字符串所引起的。

解決方法是不要在cookie里記錄過多數(shù)據(jù)，如果實(shí)在需要的話可以考慮調(diào)整在nginx.conf中的client_header_buffer_size(默認(rèn)1k)

若cookie太大，可能還需要調(diào)整large_client_header_buffers(默認(rèn)4k)，該參數(shù)說明如下：

請求行如果超過buffer，就會報HTTP 414錯誤(URI Too Long)

nginx接受最長的HTTP頭部大小必須比其中一個buffer大，否則就會報400的HTTP錯誤(Bad Request)。

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經(jīng)執(zhí)行，但是由于某種原因（一般是讀取資源的問題）沒有執(zhí)行完畢而導(dǎo)致PHP-CGI進(jìn)程終止。

Nginx 504 Gateway Time-out的含義是所請求的網(wǎng)關(guān)沒有請求到，簡單來說就是沒有請求到可以執(zhí)行的PHP-CGI。

解決這兩個問題其實(shí)是需要綜合思考的，一般來說Nginx 502 Bad Gateway和php-fpm.conf的設(shè)置有關(guān)，而Nginx 504 Gateway Time-out則是與nginx.conf的設(shè)置有關(guān)。

而正確的設(shè)置需要考慮服務(wù)器自身的性能和訪客的數(shù)量等多重因素。

以我目前的服務(wù)器為例子CPU是奔四1.5G的，內(nèi)存1GB，CENTOS的系統(tǒng)，訪客大概是50人左右同時在線。

但是在線的人大都需要請求PHP-CGI進(jìn)行大量的信息處理，因此我將nginx.conf設(shè)置為：

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;

這里最主要的設(shè)置是前三條，即

fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;

這里規(guī)定了PHP-CGI的連接、發(fā)送和讀取的時間，300秒足夠用了，因此我的服務(wù)器很少出現(xiàn)504 Gateway Time-out這個錯誤。最關(guān)鍵的是php-fpm.conf的設(shè)置，這個會直接導(dǎo)致502 Bad Gateway和504 Gateway Time-out。

下面我們來仔細(xì)分析一下php-fpm.conf幾個重要的參數(shù)：

php-fpm.conf有兩個至關(guān)重要的參數(shù)，一個是”max_children”,另一個是”request_terminate_timeout”
我的兩個設(shè)置的值一個是”40″，一個是”900″，但是這個值不是通用的，而是需要自己計算的。

計算的方式如下：
如果你的服務(wù)器性能足夠好，且寬帶資源足夠充足，PHP腳本沒有系循環(huán)或BUG的話你可以直接將”request_terminate_timeout”設(shè)置成0s。0s的含義是讓PHP-CGI一直執(zhí)行下去而沒有時間限制。而如果你做不到這一點(diǎn)，也就是說你的PHP-CGI可能出現(xiàn)某個BUG，或者你的寬帶不夠充足或者其他的原因?qū)е履愕腜HP-CGI能夠假死那么就建議你給”request_terminate_timeout”賦一個值，這個值可以根據(jù)你服務(wù)器的性能進(jìn)行設(shè)定。一般來說性能越好你可以設(shè)置越高，20分鐘-30分鐘都可以。由于我的服務(wù)器PHP腳本需要長時間運(yùn)行，有的可能會超過10分鐘因此我設(shè)置了900秒，這樣不會導(dǎo)致PHP-CGI死掉而出現(xiàn)502 Bad gateway這個錯誤。

而”max_children”這個值又是怎么計算出來的呢？這個值原則上是越大越好，php-cgi的進(jìn)程多了就會處理的很快，排隊(duì)的請求就會很少。設(shè)置”max_children”也需要根據(jù)服務(wù)器的性能進(jìn)行設(shè)定，一般來說一臺服務(wù)器正常情況下每一個php-cgi所耗費(fèi)的內(nèi)存在20M左右，因此我的”max_children”我設(shè)置成40個，20M*40=800M也就是說在峰值的時候所有PHP-CGI所耗內(nèi)存在800M以內(nèi)，低于我的有效內(nèi)存1Gb。而如果我的”max_children”設(shè)置的較小，比如5-10個，那么php-cgi就會“很累”，處理速度也很慢，等待的時間也較長。如果長時間沒有得到處理的請求就會出現(xiàn)504 Gateway Time-out這個錯誤，而正在處理的很累的那幾個php-cgi如果遇到了問題就會出現(xiàn)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，在服務(wù)器負(fù)載稍高時常常出現(xiàn)502 bad gateway錯誤。

起先懷疑這是php-cgi的進(jìn)程開得太少，增加后仍然有反映時常有錯，偶然間發(fā)現(xiàn)php-cgi會報出這樣的錯誤：

zend_mm_heap corrupted

看來是php-cgi在執(zhí)行某些代碼時有問題，以致于該線程中止。

在服務(wù)器上可能還會看到php-cgi進(jìn)程在不斷變少，估計是出現(xiàn)錯誤的php-cgi的進(jìn)程自動退出了。

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

在nginx的proxy中，規(guī)避莫名其妙錯誤的辦法無非是proxy到一個upstream的服務(wù)器組中，然后配置 proxy_next_upstream，讓nginx遇到某種錯誤碼時，自動跳到下一個后端上。這樣，應(yīng)用服務(wù)器即使不穩(wěn)定，但是在nginx后面就變成了穩(wěn)定服務(wù)。想到nginx的fastcgi和proxy是一路東西，所以proxy能用的經(jīng)驗(yàn)，移植到fastcgi也能跑得起來。

照著這個思路，用spawn-fcgi多開同樣一組php進(jìn)程，所不同的僅僅是端口：

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;
}

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

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

這樣的配置在單機(jī)下不知能不能共享session，沒有測試，如果有問題，可以加上ip_hash，或者配置php把session存進(jìn)memcached中。

然后就是fastcgi_next_upstream的配置，nginx wiki中沒有介紹到這個配置，查了一下，在nginx的CHANGES中有提到，而且出生年月是和proxy_next_upstream一樣的。既然如此，那就照proxy_next_upstream一樣配吧。一般按默認(rèn)的值error timeout就可以工作，因?yàn)閜hp出現(xiàn)502錯誤的異常是返回的500錯誤，所以我把fastcgi_next_upstream定為：

fastcgi_next_upstream error timeout invalid_header http_500;

通過這個配置，就可以基本杜絕任何時常性的500錯誤，出問題的幾率會變小很多，如果客戶反映仍然激烈，那么就多增加幾組fastcgi進(jìn)程。

以上配置能夠杜絕由于php所引起的“莫名其妙”的時常性的502錯誤，同時可使nginx搭配php比從前方式更為強(qiáng)悍。假如nginx還是返回502錯誤，那這次就一定是出現(xiàn)服務(wù)器掛掉或其它嚴(yán)重問題的了。

到此這篇關(guān)于nginx 502、413和404錯誤原因排查和解決辦法總結(jié)的文章就介紹到這了,更多相關(guān)nginx 502、413和404內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論