nginx 502的解决办法
解决Nginx+ PHP（FastCGI）遇到的502 Bad Gateway错误出现这种情况大多是php-cgi超时没有返回信息,php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉，都会出现502错误
查找原因：
1、查看当前的PHP FastCGI进程数是否够用：(张宴)
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”，那么，说明“FastCGI进程数”不够用，需要增大
2、部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间，例如：
......
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
3、查看php.ini配置文件中php可以使用的内存：memory_limit 改大，比方说设置为128M
4、php-fpm.conf问题
request_terminate_timeout 真正能够控制 PHP 脚本最大执行时间 。默认值为 0 秒，也就是说，PHP 脚本会一直执行下去。如果
代码有问题。而这里设置为0，则这台nginx+php将无法在处理新的php请求了，并返回502 。可以将这个时间更改，比方说为
30s
5 php-fpm.conf问题 案例：
一台服务器上运行着nginx php(fpm) xcache，访问量日均 300W pv左右
最近经常会出现这样的情况： php页面打开很慢，cpu使用率突然降至很低，系统负载突然升至很高，查看网卡的流量，也会发现突然降到了很低。这种情况只持续数秒钟就恢复了
检查php-fpm的日志文件发现了一些线索
Sep 30 08:32:23.289973 fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
Sep 30 08:32:23.290212 fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″
Sep 30 08:32:23.290342 fpm_event_init_main(), line 109: libevent: using epoll
Sep 30 08:32:23.296426 fpm_init(), line 47: fpm is running, pid 30587
在这几句的前面，是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无法生成数据传输给客户端)
解决问题很简单，增加children的数量(每个php-cgi 大概消耗20M内存)，例如：140
并且将 max_requests 设置未 0 或者一个比较大的值，比方说10240，重启php-fpm
6 php.ini 问题
php.ini 禁用函数，而php页面包含这个函数可能造成这个问题。
查看php.ini disable_functions = system,passthru,exec,shell_exec,popen,phpinfo,chdir,chroot,dir,getcwd,opendir,readdir,scandir,chgrp,chmod,chown
比方说出问题的界面为test.php 可以用grep -E "system|passthru|exec|shell_exec|popen|phpinfo|chdir|chroot|dir|getcwd|opendir|readdir|scandir|chgrp|chmod|chown" test.php 查看页面是否包含这些函数，如果包含，只要去掉对应函数，重启 php-fpm即可
页:
[1]