我們 fail oca ini 還需要 系統 rup file 同時

一、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改成一個時間

二、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

三、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錯誤，那這次就一定是出現服務器掛掉或其它嚴重問題的了。

NGINX 502錯誤排查（轉）