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的設定有關。
1.檢視FastCGI程序是否已經啟動
NGINX 502錯誤的含義是sock、埠沒被監聽造成的。我們先檢查fastcgi是否在執行
2.檢查系統Fastcgi程序執行情況
除了第一種情況，fastcgi程序數不夠用、php執行時間長、或者是php-cgi程序死掉也可能造成nginx的502錯誤
執行以下命令判斷是否接近FastCGI程序，如果fastcgi程序數接近配置檔案中設定的數值，表明worker程序數設定太少
netstat -anpo | grep "php-cgi" | wc -l
3.FastCGI執行時間過長
根據實際情況調高以下引數值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.頭部太大這種情況可能是由於nginx預設的fastcgi程序響應的緩衝區太小造成的, 這將導致fastcgi程序被掛起, 如果你的fastcgi服務對這個掛起處理的不好, 那麼最後就極有可能導致504 Gateway Time-out
現在的網站, 尤其某些論壇有大量的回覆和很多內容的, 一個頁面甚至有幾百K
預設的fastcgi程序響應的緩衝區是8K, 我們可以設定大點：                                fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
如果你使用的是nginx的負載均衡Proxying，調整
proxy_buffer_size  16k;   這裡引數調大
proxy_buffers   4 16k;
5.https轉發配置錯誤
正確的配置方法
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;
}
下面我們來仔細分析一下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這個錯誤。


一個例項：
http://www.levil.cn/post/29/
我在CentOS下配置lnmp組合基本上用的都是同樣的配置檔案，一直都沒出現過問題，可最近在一個vps上安裝同樣的環境之後，網站線上10多人就出 現了開啟速度非常緩慢的情況，有好幾次都是直接達到了nginx中設定的指令碼最大超時時間300秒，結果導致nginx往客戶端瀏覽器傳送了一個504 Gateway Time-out的錯誤程式碼，分析了之後改動了幾處配置檔案，終於避免了該情況的出現。


從 錯誤程式碼基本可以確定跟nginx本身無關，主要是提交給php-fpm的請求未能正確反饋而導致，一般情況下，提交動態請求的時候，nginx會直接把 請求轉交給php-fpm，而php-fpm再分配php-cgi程序來處理相關的請求，之後再依次返回，最後由nginx把結果反饋給客戶端瀏覽器，但 我這個vps目前跑的是個純php應用內容，實際上使用者所有的請求都是php請求，有的耗費時間比較久，php-cgi程序就一直都被用滿，而php- fpm本身的配置檔案只打開了10組php-cgi程序，這樣的話線上使用者稍微多的話就會導致請求無法被正常處理而出錯。


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


把max_children由之前的10改為現在的30，這樣就可以保證有充足的php-cgi程序可以被使用；
把request_terminate_timeout由之前的0s改為60s，這樣php-cgi程序處理指令碼的超時時間就是60秒，可以防止程序都被掛起，提高利用效率。


接著再更改nginx的幾個配置項，減少FastCGI的請求次數，儘量維持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的配置，再次測試，至今兩週時間內沒有再出現504 Gateway Time-out的情況，算是達到效果了。


另一例子：
使用ie正常.其他人用FF也正常.但是有個人使用FF瀏覽報錯502
檢視後臺error日誌,發現一句
upstream sent too big header while reading response header from upstream
就是反饋回來的頭部資訊太大
一般應該是cookie裡面帶的
懷疑是FF裡面的某個外掛引起返回太多的頭部資訊
一個個排查.最後發現是FireBug導致的
既然是fastcgi返回的頭部太大.應該可以配置
查詢資料後發現應該是和fastcgi_buffer_*有關的
將相關配置增大.發現問題解決
這邊使用的是
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
比原來的預設4k/8k要大許多


 
http400錯：
nginx的HTTP400錯誤，而且這個HTTP400錯誤並不是每次都會出現的，查了一下發現nginx 400錯誤是由於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)。


 
http413錯：
在上傳時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

年底了事情真多，club伺服器有問必答 提交頁面 提交出這個問題
The page you are looking for is temporarily unavailable.Please try again later.
一看就知道是nginx的請求的錯誤，，惆悵啊。。
就開啟了 錯誤日誌檢視。。。
tail -f error.log
就具體錯誤是 ：
upstream sent too big header while reading response header from upstream
我們是nginx反向代理
proxy是nginx作為client轉發時使用的，如果header過大，超出了預設的1k，就會引發上述的upstream sent too big header （說白了就是nginx把外部請求給後端apache ，apache返回的header  太大nginx處理不過來就導致了。
 
  server {
        listen       80;
        server_name  *.xywy.com ;
        large_client_header_buffers 4 16k;
        #charset koi8-r;
        # access_log off;
        location / {
#新增這3行 ，
                proxy_buffer_size 64k;
                proxy_buffers   32 32k;
                proxy_busy_buffers_size 128k;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP       $remote_addr;
           proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
           set $baiduspider '';
           if ( $http_user_agent ~ Baiduspider) {
              set $baiduspider Baidu;
          }
............
 
 如果是 nginx+PHPcgi 就該 
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on
011/01/07 11:12:57 [error] 10770#0: *38585340 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.22.131.154, server: *.xywy.com, request: "GET /ysmp/index.php?did=124994 HTTP/1.0", upstream: "http://127.0.0.1:8080/ysmp/index.php?did=124994", host: "xywy.yn16.com"
後來原來那錯誤沒了出了新錯誤了 upstream timed out 超時？
server {
        listen       80;
        server_name  *.xywy.com ;
  large_client_header_buffers 4 16k;
        client_max_body_size 300m;
        client_body_buffer_size 128k;
        proxy_connect_timeout 600;
        proxy_read_timeout 600;
        proxy_send_timeout 600;
                proxy_buffer_size 64k;
                proxy_buffers   4 32k;
                proxy_busy_buffers_size 64k;
                proxy_temp_file_write_size 64k;
        #charset koi8-r;


        # access_log off;
後來引數我又改了下 就好了。。。
 可以參考：


http://wiki.nginx.org/NginxHttpProxyModule
http://blog.sina.com.cn/s/blog_5dc960cd0100i4mt.html

cookies的值超出了範圍我是說

看看了一下日誌

錯誤502 upstream sent too big header while reading response header from upstream

sudo gedit /var/log/nginx/error.log

檢視錯誤日誌

upstream sent too big header while reading response header from upstream

你去搜這個錯誤，網上的解釋都差不多，無外乎是cookie攜帶的header太多了，讓你設定：

fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;

逐步嘗試。其中fastcgi_buffers 8 128k 這句，fastcgi_buffers 32 32k 這樣更好，記憶體是整塊分配和釋放的，減少單位k數能儘可能利用。

另外，如果你用nginx做負載均衡的話，改了上述引數是沒用的，要在轉發的配置上，比如以下設定：

location @to_other {

                proxy_buffer_size  128k;

                proxy_buffers   32 32k;

                proxy_busy_buffers_size 128k;

                add_header X-Static transfer;

                proxy_redirect off;

                proxy_set_header Host $host;

                proxy_set_header X-Real-IP  $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_pass http://backend;    #請求轉發

        }

加粗的三行才會起作用。

fastcgi_* 可以理解成nginx接受client請求時的響應使用的。proxy是nginx作為client轉發時使用的，如果header過大，超出了預設的1k，就會引發上述的upstream sent too big header。

可以參考：

http://wiki.nginx.org/NginxHttpProxyModule

http://blog.sina.com.cn/s/blog_5dc960cd0100i4mt.html

其它搜尋結果可以無視，都是大同小異的。

location ~ \.php$ {

       fastcgi_buffer_size 128k;

       fastcgi_buffers 32 32k;

       include /etc/nginx/fastcgi_params;

       fastcgi_pass   127.0.0.1:9000;

       fastcgi_index index.php;

       fastcgi_param SCRIPT_FILENAME /host/web/$fastcgi_script_name;

    }

如題，最近網站頻繁出現502錯誤，簡直無法正常運轉，出現這種情況大多是php-cgi超時沒有返回資訊,或程序僵死等情況造成的。我們的nginx已經配置到極致這些都已經老早做過修改了，但現在又出然出現。
經過分析將nginx的error log開啟，發現”pstream sent too big header while reading response header from upstream”這樣的錯誤提示，查閱了一下資料，大意是nginx緩衝區有一個bug造成的,我們網站的頁面消耗佔用緩衝區可能過大。參考老外寫的修改辦法增加了緩衝區容量大小設定,502問題徹底解決，後來系統管理員又對引數做了調整隻保留了2個設定引數：client head buffer，fastcgi buffer size。

參考:代

http://www. sudone .com/nginx/nginx_400_bad_request.html
http://blog. rackcorp .com/?p=14

二、昨天裝上nginx後在高負載的時候，論壇上傳圖片或者執行較長時間指令碼的時候就不停的出現502 Bad Gateway ，網上搜了，大多數都是張大師的那篇解決方案，他的解決方案是

http
{
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
}

增加了fastcgi的相應請求時間。但是我在實際中碰到了這個問題，設定到500，還是會出現，只是比我設定120的時候要少一些。後來發現主要是在一些post或者資料庫操作的時候出現這種情況，靜態頁面是不會出現的

反覆的查問題，除錯，也加大了CGI的程序數。
務器,ip查詢,手機號,proxy,天氣預報,火車時刻,身份證號碼,飛機航班,新華字典查詢等  S6 b4 \) y& c( \! j) ]
256再加上去可能會變得很慢。佔用記憶體大了。123cha.com1 u& }. p1 [7 b% L/ \0 \
在php-fpm.conf設定中還有一項，可能當時沒注意到，無意中改了這個值。
request_terminate_timeout
這個值是max_execution_time，就是fast-cgi的執行指令碼時間。
0s 123cha.com* S( v, U9 D5 q6 T; i* z6 u- R
0s為關閉，就是無限執行下去。（當時裝的時候沒仔細看就改了一個數字）
發現，問題解決了，執行很長時間也不會出錯了。
優化fastcgi中，還可以改改這個值5s 。看看效果
終於發現502的錯誤其實不是nginx的問題，
php-cgi程序數不夠用、php執行時間長、或者是php-cgi程序死掉，都會出現502錯誤

三、
一臺伺服器上執行著nginx php(fpm) xcache，訪問量日均 300W pv左右

最近經常會出現這樣的情況： php頁面開啟很慢，cpu使用率突然降至很低，系統負載突然升至很高，檢視網絡卡的流量，也會發現突然降到了很低。這種情況只持續數秒鐘就恢復了
檢查php-fpm的日誌檔案發現了一些線索

在這幾句的前面，是1000多行的關閉children和開啟children的日誌
原來，php-fpm有一個引數 max_requests ，該引數指明瞭，每個children最多處理多少個請求後便會被關閉，預設的設定是500。因為php是把請求輪詢給每個children，在大流量下，每個childre到達max_requests所用的時間都差不多，這樣就造成所有的children基本上在同一時間被關閉。
在這期間，nginx無法將php檔案轉交給php-fpm處理，所以cpu會降至很低(不用處理php，更不用執行sql)，而負載會升至很高(關閉和開啟children、nginx等待php-fpm)，網絡卡流量也降至很低(nginx無法生成資料傳輸給客戶端)) O" ], O  w$ q/ v1 X* D
解決問題很簡單，增加children的數量，並且將 max_requests 設定未 0 或者一個比較大的值，重啟php-fpm

四、
nginx 502錯誤的原因比較多，是因為在代理模式下後端伺服器出現問題引起的。這些錯誤一般都不是nginx本身的問題，一定要從後端找原因！但nginx把這些出錯都攬在自己身上了，著實讓nginx的推廣者備受置疑，畢竟從字眼上理解，bad gateway？不就是bad nginx嗎？讓不瞭解的人看到，會直接把責任推在nginx身上，希望nginx下一個版本會把出錯提示寫稍微友好一些，至少不會是現在簡單的一句502 Bad Gateway，另外還不忘附上自己的大名。
502錯誤最通常的出現情況就是後端主機當機，當然還有。在upstream配置裡有這麼一項配置：proxy_next_upstream，這個配置指定了nginx在從一個後端主機取資料遇到何種錯誤時會轉到下一個後端主機，裡頭寫上的就是會出現502的所有情況拉，預設是error timeout，error就是當機、斷線之類的，timeout就是讀取堵塞超時，比較容易理解。我一般是全寫上的：
proxy_next_upstream error timeout invalid_header http_500 http_503;
不過現在可能我要去掉http_500這一項了，http_500指定後端返回500錯誤時會轉一個主機，後端的jsp出錯的話，本來會列印一堆stacktrace的錯誤資訊，現在被502取代了。但公司的程式設計師可不這麼認為，他們認定是nginx出現了錯誤，我實在沒空跟他們解釋502的原理了……
invalid_header我也沒認真查清到底指的什麼，我也很想先把它弄下來
503錯誤就可以保留，因為後端通常是apache resin，如果apache宕機就是error，但resin宕機，僅僅是503，所以還是有必要保留的

昨日，有朋友問我，他將Web伺服器換成Nginx 0.6.31  + PHP 4.4.7（FastCGI）後，有時候訪問會出現“502 Bad Gateway”錯誤，如何解決。

　　我讓按照以下兩個步驟去解決，最後在第2步中將FastCGI的timeout時間增加為300，問題解決：

　　PS：比較羨慕迅雷的Web伺服器，16G記憶體。

　　1、檢視當前的PHP FastCGI程序數是否夠用：

　　如果實際使用的“FastCGI程序數”接近預設的“FastCGI程序數”，那麼，說明“FastCGI程序數”不夠用，需要增大。

　　2、部分PHP程式的執行時間超過了Nginx的等待時間，可以適當增加nginx.conf配置檔案中FastCGI的timeout時間，例如：