快捷導(dǎo)航

nginx 502、413和404錯(cuò)誤原因排查和解決辦法總結(jié)

更新時(shí)間：2023年12月08日 11:44:03 作者：初心@_@

這篇文章主要給大家介紹了NGINX 502錯(cuò)誤排查,辦法總結(jié),Nginx 413錯(cuò)誤的排查以及Nginx 400錯(cuò)誤排查,文中通過(guò)代碼示例給出了詳細(xì)的排查方法和解決方案,需要的朋友可以參考下

一、NGINX 502錯(cuò)誤排查

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

1.FastCGI進(jìn)程是否已經(jīng)啟動(dò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í)行時(shí)間過(guò)長(zhǎng)

根據(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ā)配置錯(cuò)誤

正確的配置方法

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，我用過(guò)的有php-fpm，流量約為單臺(tái)機(jī)器40萬(wàn)PV(動(dòng)態(tài)頁(yè)面), 現(xiàn)在基本上沒有碰到502。

7.php腳本執(zhí)行時(shí)間過(guò)長(zhǎng)

將php-fpm.conf的0s的0s改成一個(gè)時(shí)間

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

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

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

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

post_max_size = 8M

upload_max_filesize = 2M

三、Nginx 400錯(cuò)誤排查：HTTP頭/Cookie過(guò)大

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

解決方法是不要在cookie里記錄過(guò)多數(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ù)說(shuō)明如下：

請(qǐng)求行如果超過(guò)buffer，就會(huì)報(bào)HTTP 414錯(cuò)誤(URI Too Long)

nginx接受最長(zhǎng)的HTTP頭部大小必須比其中一個(gè)buffer大，否則就會(huì)報(bào)400的HTTP錯(cuò)誤(Bad Request)。

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

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

解決這兩個(gè)問(wèn)題其實(shí)是需要綜合思考的，一般來(lái)說(shuō)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人左右同時(shí)在線。

但是在線的人大都需要請(qǐng)求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ā)送和讀取的時(shí)間，300秒足夠用了，因此我的服務(wù)器很少出現(xiàn)504 Gateway Time-out這個(gè)錯(cuò)誤。最關(guān)鍵的是php-fpm.conf的設(shè)置，這個(gè)會(huì)直接導(dǎo)致502 Bad Gateway和504 Gateway Time-out。

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

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

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

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

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

一般nginx搭配php都采用這樣的方式：

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

這個(gè)方式只能連接到一組spawn-fcgi開啟的fastcgi，在服務(wù)器負(fù)載稍高時(shí)常常出現(xiàn)502 bad gateway錯(cuò)誤。

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

zend_mm_heap corrupted

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

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

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

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

照著這個(gè)思路，用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é)果正確，能跑起來(lái)；同時(shí)在服務(wù)器上netstat -n|grep 9000和grep 9001都有記錄，證明連接無(wú)誤；在前臺(tái)查閱頁(yè)面，一切運(yùn)行正常。

這個(gè)配置是最簡(jiǎn)單的配置，既然能連接上upstream，那么很顯然upstream的一些東西都可以拿來(lái)用，比如ip_hash、weight、max_fails等。

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

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

fastcgi_next_upstream error timeout invalid_header http_500;

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

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

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

您可能感興趣的文章: