一些运行在Nginx上的网站有时候会呈现“502 Bad Gateway”错误，有些时候甚至频繁的呈现。有些站长是在方才转移到Nginx之后就呈现了这个问题，所以常常会猜疑这是不是Nginx的问题，但事实上这是个误区。
以下是从张宴和Ayou的博客汇集整理的一些Nginx 502错误的排查要领，供各人参考：
Nginx 502错误的原因较量多，是因为在署理模式下后端处事器呈现问题引起的。这些错误一般都不是nginx自己的问题，必然要从后端找原因！但nginx把这些堕落都揽在本身身上了，着实让nginx的推广者备受置疑，究竟从字眼上领略，bad gateway？不就是bad nginx吗？让不相识的人看到，会直接把责任推在nginx身上，但愿nginx下一个版本会把堕落提示写稍微友好一些，至少不会是此刻简朴的一句502 Bad Gateway，别的还不忘附上本身的台甫。
Nginx 502的触发条件
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的道理了……
503错误就可以保存，因为后端凡是是apache resin，假如apache死机就是error，但resin死机，仅仅是503，所以照旧有须要保存的。
办理步伐
碰着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;
......
}
......
php.ini中memory_limit设低了会堕落，修改了php.ini的memory_limit为64M，重启nginx，发明好了，本来是PHP的内存不敷了。
假如这样修改了还办理不了问题，可以参考下面这些方案：
一、max-children和max-requests
一台处事器上运行着nginx php(fpm) xcache，会见量日均 300W pv阁下
最近常常会呈现这样的环境： php页面打开很慢，cpu利用率溘然降至很低，系统负载溘然升至很高，查察网卡的流量，也会发明溘然降到了很低。这种环境只一连数秒钟就规复了
查抄php-fpm的日志文件发明白一些线索
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″
Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll
Sep 30 08:32:23.296426 [NOTICE] 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的数量，而且将 max_requests 配置未 0 可能一个较量大的值：
打开 /usr/local/php/etc/php-fpm.conf
