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。

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

1.查看FastCGI進(jìn)程是否已經(jīng)啟動(dòng)
NGINX 502錯(cuò)誤的含義是sock、端口沒被監(jiān)聽造成的。我們先檢查fastcgi是否在運(yùn)行
2.檢查系統(tǒng)Fastcgi進(jìn)程運(yùn)行情況
除了第一種情況，fastcgi進(jìn)程數(shù)不夠用、php執(zhí)行時(shí)間長、或者是php-cgi進(jìn)程死掉也可能造成nginx的502錯(cuò)誤
運(yùn)行以下命令判斷是否接近FastCGI進(jìn)程，如果fastcgi進(jìn)程數(shù)接近配置文件中設(shè)置的數(shù)值，表明worker進(jìn)程數(shù)設(shè)置太少
netstat -anpo | grep "php-cgi" | wc -l
3.FastCGI執(zhí)行時(shí)間過長
根據(jù)實(shí)際情況調(diào)高以下參數(shù)值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

4.頭部太大這種情況可能是由于nginx默認(rèn)的fastcgi進(jìn)程響應(yīng)的緩沖區(qū)太小造成的, 這將導(dǎo)致fastcgi進(jìn)程被掛起, 如果你的fastcgi服務(wù)對這個(gè)掛起處理的不好, 那么最后就極有可能導(dǎo)致504 Gateway Time-out
現(xiàn)在的網(wǎng)站, 尤其某些論壇有大量的回復(fù)和很多內(nèi)容的, 一個(gè)頁面甚至有幾百K
默認(rèn)的fastcgi進(jìn)程響應(yīng)的緩沖區(qū)是8K, 我們可以設(shè)置大點(diǎn)：                                fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
如果你使用的是nginx的負(fù)載均衡Proxying，調(diào)整
proxy_buffer_size  16k;   這里參數(shù)調(diào)大
proxy_buffers   4 16k;
5.https轉(zhuǎn)發(fā)配置錯(cuò)誤
正確的配置方法
server_name www.xok.la;
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;
}

下面我們來仔細(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)，也就是說你的PHP-CGI可能出現(xiàn)某個(gè)BUG，或者你的寬帶不夠充足或者其他的原因?qū)е履愕腜HP-CGI能夠假死那么就建議你給”request_terminate_timeout”賦一個(gè)值，這個(gè)值可以根據(jù)你服務(wù)器的性能進(jìn)行設(shè)定。一般來說性能越好你可以設(shè)置越高，20分鐘-30分鐘都可以。由于我的服務(wù)器PHP腳本需要長時(shí)間運(yùn)行，有的可能會(huì)超過10 分鐘因此我設(shè)置了900秒，這樣不會(huì)導(dǎo)致PHP-CGI死掉而出現(xiàn)502 Bad gateway這個(gè)錯(cuò)誤。

我在CentOS下配置lnmp組合基本上用的都是同樣的配置文件，一直都沒出現(xiàn)過問題，可最近在一個(gè)vps上安裝同樣的環(huán)境之后，網(wǎng)站在線10多人就出現(xiàn)了打開速度非常緩慢的情況，有好幾次都是直接達(dá)到了nginx中設(shè)置的腳本最大超時(shí)時(shí)間300秒，結(jié)果導(dǎo)致nginx往客戶端瀏覽器發(fā)送了一個(gè)504 Gateway Time-out的錯(cuò)誤代碼，分析了之后改動(dòng)了幾處配置文件，終于避免了該情況的出現(xiàn)。

從錯(cuò)誤代碼基本可以確定跟nginx本身無關(guān)，主要是提交給php-fpm的請求未能正確反饋而導(dǎo)致，一般情況下，提交動(dòng)態(tài)請求的時(shí)候，nginx會(huì)直接把請求轉(zhuǎn)交給php-fpm，而php-fpm再分配php-cgi進(jìn)程來處理相關(guān)的請求，之后再依次返回，最后由nginx把結(jié)果反饋給客戶端瀏覽器，但我這個(gè)vps目前跑的是個(gè)純php應(yīng)用內(nèi)容，實(shí)際上用戶所有的請求都是php請求，有的耗費(fèi)時(shí)間比較久，php-cgi進(jìn)程就一直都被用滿，而php- fpm本身的配置文件只打開了10組php-cgi進(jìn)程，這樣的話在線用戶稍微多的話就會(huì)導(dǎo)致請求無法被正常處理而出錯(cuò)。

大概分析出了原因，下面做就比較容易了，首先是更改php-fpm的幾處配置：

把max_children由之前的10改為現(xiàn)在的30，這樣就可以保證有充足的php-cgi進(jìn)程可以被使用；
把request_terminate_timeout由之前的0s改為60s，這樣php-cgi進(jìn)程處理腳本的超時(shí)時(shí)間就是60秒，可以防止進(jìn)程都被掛起，提高利用效率。

接著再更改nginx的幾個(gè)配置項(xiàng)，減少FastCGI的請求次數(shù)，盡量維持buffers不變：

fastcgi_buffers由 4 64k 改為 2 256k；
fastcgi_buffer_size由 64k 改為 128K；
fastcgi_busy_buffers_size 由 128K 改為 256K；
fastcgi_temp_file_write_size 由 128K 改為 256K。

好了，重新加載php-fpm和nginx的配置，再次測試，至今兩周時(shí)間內(nèi)沒有再出現(xiàn)504 Gateway Time-out的情況，算是達(dá)到效果了。

另一例子：

使用ie正常.其他人用FF也正常.但是有個(gè)人使用FF瀏覽報(bào)錯(cuò)502
查看后臺(tái)error日志,發(fā)現(xiàn)一句
upstream sent too big header while reading response header from upstream
就是反饋回來的頭部信息太大
一般應(yīng)該是cookie里面帶的
懷疑是FF里面的某個(gè)插件引起返回太多的頭部信息
一個(gè)個(gè)排查.最后發(fā)現(xiàn)是FireBug導(dǎo)致的
既然是fastcgi返回的頭部太大.應(yīng)該可以配置
查找資料后發(fā)現(xiàn)應(yīng)該是和fastcgi_buffer_*有關(guān)的
將相關(guān)配置增大.發(fā)現(xiàn)問題解決
這邊使用的是
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
比原來的默認(rèn)4k/8k要大許多

http400錯(cuò)：
nginx的HTTP400錯(cuò)誤，而且這個(gè)HTTP400錯(cuò)誤并不是每次都會(huì)出現(xiàn)的，查了一下發(fā)現(xiàn)nginx 400錯(cuò)誤是由于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，就會(huì)報(bào)HTTP 414錯(cuò)誤(URI Too Long)
nginx接受最長的HTTP頭部大小必須比其中一個(gè)buffer大，否則就會(huì)報(bào)400的HTTP錯(cuò)誤(Bad Request)。
 
http413錯(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的設(shè)置, 這個(gè)值默認(rèn)是1m，可以增加到8m