nginx 502 Bad Gateway 錯誤解決辦法

nginx出現502有不少緣由，但大部分緣由能夠歸結爲資源數量不夠用,也就是說後端PHP-fpm處理有問題，nginx將正確的客戶端請求發給了後端的php-fpm進程，可是由於php-fpm進程的問題致使不能正確解析php代碼，最終返回給了客戶端502錯誤。

nginx+php出現502 bad gateway，通常這都不是nginx的問題，而是因爲 fastcgi或者php的問題致使的，常見的有如下幾種(其實解決問題的最好的方式仍是本身去看nginx和fastcgi的errorlog):

 

1. php.ini的memory_limit 太小（若是有個別php程序進程須要佔用極大內存時這個必須注意）

2. php-fpm.conf中max_children或者max_requests  設置不合理（設置太小會由於沒有足夠的cgi進程處理請求，設置過大會出現一下子有響應正常，一下子等好久纔有響應的狀況，通常狀況下children按 照內存計算，好比說1G設置64，2G128。這個根據實際狀況自行調整。另外查看當前的PHP FastCGI進程數是否夠用的命令爲：netstat  -anpo |grep 「php-cgi」 | wc -l   若是實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，須要增大。）

3. 查看nginx錯誤日誌，發現 pstream sent too big header while reading response  headerfrom upstream ，則檢查client head buffer，fastcgi buffer  size是否太小，可設置爲32K。

4. php程序執行時間過長而超時，檢查nginx和fastcgi中各類timeout設置。（nginx 中的  fastcgi_connect_timeout 300;fastcgi_send_timeout 300  ：fastcgi_read_timeout300; keepalive_timeout ；  php-fpm中的request_terminate_timeout，php.ini中的max_execution_time）

 

5. php-fpm有一個參數 max_requests ，該參數指明瞭每一個children最多處理多少個請求後便會被關閉。在大量處理請求下，若是該值設置太小會致使children頻繁的自殺和創建而浪費 大量時間，若全部的children差很少都在這個時候自殺，則重建前將沒有children響應請求，因而出現502  。能夠將該值設置大一些或者是0[無限]。

若是你服務器併發量很是大，那隻能先增長機器，而後按如下方式優化會取得更好效果;但若是你併發不大卻出現502，通常均可以歸結爲配置問題，腳本超時問題。

1.php-fpm進程數不夠用

使用netstat -napo |grep "php-fpm" | wc -l查看一下當前fastcgi進程個數，若是個數接近conf裏配置的上限，就須要調高進程數。

但也不能無休止調高，能夠根據服務器內存狀況，能夠把php-fpm子進程數調到100或以上，在4G內存的服務器上200就能夠。

2. 調高調高Linux內核打開文件數量

可使用這些命令(必須是root賬號)

echo 'ulimit -HSn 65536'>> /etc/profile

echo 'ulimit -HSn 65536'>> /etc/rc.local

source /etc/profile

 3.腳本執行時間超時

若是腳本由於某種緣由長時間等待不返回，致使新來的請求不能獲得處理，能夠適當調小以下配置。

nginx.conf裏面主要是以下

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

php-fpm.conf裏如要是以下

request_terminate_timeout =10s

4.緩存設置比較小

修改或增長配置到nginx.conf

proxy_buffer_size 64k;
proxy_buffers  512k;
proxy_busy_buffers_size 128k;

5. recv()failed (104: Connection reset by peer) while reading response header fromupstream

可能的緣由機房網絡丟包或者機房有硬件防火牆禁止訪問該域名

但最重要的是程序裏要設置好超時，不要使用php-fpm的request_terminate_timeout，

最好設成request_terminate_timeout=0;

由於這個參數會直接殺掉php進程，而後重啓php進程，這樣前端nginx就會返回104: Connection reset by peer。這個過程是很慢，整體感受就是網站很卡。

May 01 10:50:58.044162[WARNING] [pool www] child 4074, script'/usr/local/nginx/html/quancha/sameip/detail.php' execution timed out(15.129933 sec), terminating
May 01 10:50:58.045725 [WARNING] [pool www] child 4074 exited on signal 15SIGTERM after 90.227060 seconds from start
May 01 10:50:58.046818 [NOTICE] [pool www] child 4082 started

說一千道一萬最重要的就是程序裏控制好超時，gethostbyname、curl、file_get_contents等函數的都要設置超時時間。

另外一個就是多說，這個東西是增長了網站的交互性，可是使用的多了反應就慢了，若是你網站超時且使用了多說是，能夠關閉它。

六、本身遇到502的解決辦法：
調整增大php 和Nginx 的backlog數。

PHP-FPM高負載的解決辦法
Postedon 2011/09/02

這裏只是介紹了php-fpm的優化方法的，但通常狀況下和nginx組合使用的時候，單獨優化其中一項的話，做用不是特別的大，同時還須要對nginx進行優化．nginx的作法方法參考：http://blog.haohtml.com/archives/6213.上面的優化前和優化後的圖，看得出先後差距仍是特別的大的．

致使nginx 502 bad gateway的PHP-CGI(FASTCGI)

NGINX頻爆502 BAD GATEWAY的錯誤，看了網上的教程，仍沒有完全解決。
目前我總結的解決502 BAD GATEWAY的方式有：

1.視服務器的性能，在php-fmp.conf裏增長max_children的值:

max_children是PHP-FPM Pool 最大的子進程數,他數值取決於你的服務器內存。 假設你打算給10G內存給當前配置的PHP-FPM Pool，通常一個PHP請求佔用內存10M-40M，咱們按站點每一個PHP請求佔用內存25M，這樣max_children = 10G/25M = 409。因此，這個值能夠根據狀況算出來

max_requests是每一個子進程重生以前處理的請求數， 默認值爲unlimited（默認爲1024），能夠設置小一點（如500左右），這樣能夠避免內存泄露帶來的問題

Nginx代理過程，將業務服務器請求數據緩存到本地文件，再將文件數據轉發給請求客戶端。高併發的客戶端請求，必然要求服務器文件句柄的併發打開限制。使用ulimit命令（ulimit -n），查看Linux系統文件句柄併發限制，默認是1024，咱們能夠改成65535（2 的 16 次方，這是系統端口的極限）。修改的方法爲：修改系統文件/etc/security/limits.conf，添加以下信息，並從新啓動系統生效。

* soft   nofile  65535

 

* hard   nofile  65535

而後在Nginx配置文件中，把文件限制及鏈接數信息改成65535：

worker_rlimit_nofile 65535;

events {

    use epoll;

    worker_connections  65535;

}

 

2.用reload參數定時重載php-fpm。這個主要緣由是php腳本執行時間過長形成的，重載php-fpm能杜絕這個問題。如何完全解決php-cgi腳本佔用大量內存從而致使502錯誤的產生還值得進一步探討，目前該作法不失爲一種好辦法。
具體的作法是，用crontab讓php-fpm平滑重啓，從而不影響PHP腳本的運行。

*/10* * * * /usr/local/php/sbin/php-fpm reload

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 優化設置＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

 

若是您高負載網站使用PHP-FPM管理FastCGI，這些技巧也許對您有用：)

1.Compile PHP’s modules as less as possible, the simple the best (fast);
1.儘可能少安裝PHP模塊，最簡單是最好（快）的

2. Increas PHP FastCGI child number to 100 and even more.Sometime, 200 is OK! ( On 4GB memory server);

2.把您的PHP FastCGI子進程數調到100或以上，在4G內存的服務器上200就能夠
注：個人1g測試機，開64個是最好的，建議使用壓力測試獲取最佳值

3.Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;
3.使用socket鏈接FastCGI，linux操做系統能夠放在/dev/shm中
注：在php-fpm.cnf裏設置<valuename=」listen_address」>/tmp/nginx.socket</value>就能夠經過socket鏈接FastCGI了，/dev/shm是內存文件系統，放在內存中確定會快了.記得這時也要在nginx裏的配置裏進行修改，保持一致．

location~ .*/.(php|php5)?$

{

#

將Nginx與FastCGI的通訊方式由TCP改成UnixSocket。TCP在高併發訪問下比UnixSocket穩定，但Unix Socket速度要比TCP快。

fastcgi_pass  unix:/tmp/php-cgi.sock;

#fastcgi_pass  127.0.0.1:9000;

fastcgi_index index.php;

include fcgi.conf;

}

4. Increase Linux 「max open files」, using the following command(must be root):

# echo ‘ulimit -HSn 65536′>> /etc/profile

# echo ‘ulimit -HSn 65536 >> /etc/rc.local

# source /etc/profile 

4.調高linux內核打開文件數量，可使用這些命令(必須是root賬號

)

echo ‘ulimit -HSn 65536′ >> /etc/profile

echo ‘ulimit -HSn 65536′ >> /etc/rc.local

source /etc/profile 

注：我是修改/etc/rc.local，加入ulimit -SHn 51200的

5.Increase PHP-FPM open file description rlimit:

# vi /path/to/php-fpm.conf

Find 「<value name=」rlimit_files」>1024</value>」

Change 1024 to 4096 or higher number.

Restart PHP-FPM.

5.增長 PHP-FPM 打開文件描述符的限制

# vi /path/to/php-fpm.conf

找到

「<value name=」rlimit_files」>1024</value>」

把1024更改成4096或者更高

.

重啓PHP-FPM.

6. Using PHP code accelerator,e.g eAccelerator, XCache. And set 「cache_dir」 to /dev/shm on Linux.6.使用php代碼加速器，例如eAccelerator, XCache.在linux平臺上能夠把`cache_dir`指向/dev/shm原文：https://blog.csdn.net/u011007133/article/details/54908335