Nginx 502错误发生原因与办理步伐总结

一些运行在Nginx上的网站有时候会呈现“502 BadGateway”错误，有些时候甚至频繁的呈现。有些站长是在方才转移到Nginx之后就呈现了这个问题，所以常常会猜疑这是不是Nginx的问题，但事实上这是个误区。

以下是从张宴和Ayou的博客汇集整理的一些Nginx 502错误的排查要领，供各人参考：

Nginx502错误的原因较量多，是因为在署理模式下后端处事器呈现问题引起的。这些错误一般都不是nginx自己的问题，必然要从后端找原因！但nginx把这些堕落都揽在本身身上了，着实让nginx的推广者备受置疑，究竟从字眼上领略，badgateway？不就是badnginx吗？让不相识的人看到，会直接把责任推在nginx身上，但愿nginx下一个版本会把堕落提示写稍微友好一些，至少不会是此刻简朴的一句502Bad Gateway，别的还不忘附上本身的台甫。

Nginx 502的触发条件

502错误最凡是的呈现环境就是后端主机当机。在upstream设置里有这么一项设置：proxy_next_upstream，这个设置指定了nginx在从一个后端主机取数据碰着何种错误时会转到下一个后端主机，里头写上的就是会呈现502的所有环境拉，默认是errortimeout。error就是当机、断线之类的，timeout就是读取堵塞超时，较量容易领略。我一般是全写上的：

proxy_next_upstreamerrortimeoutinvalid_headerhttp_500http_503;

不外此刻大概我要去掉http_500这一项了，http_500指定后端返回500错误时会转一个主机，后端的jsp堕落的话，原来会打印一堆stacktrace的错误信息，此刻被502代替了。但公司的措施员可不这么认为，香港云服务器美国云主机，他们认定是nginx呈现了错误，我实在没空跟他们表明502的道理了……

503错误就可以保存，因为后端凡是是apacheresin，假如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_timeout300;fastcgi_send_timeout300;fastcgi_read_timeout300;......}......

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的日志文件发明白一些线索

Sep3008:32:23.289973[NOTICE]fpm_unix_init_main(),line271:getrlimit(nofile):max:51200,cur:51200Sep3008:32:23.290212[NOTICE]fpm_sockets_init_main(),line371:usinginheritedsocketfd=10,“127.0.0.1:9000″Sep3008:32:23.290342[NOTICE]fpm_event_init_main(),line109:libevent:usingepollSep3008:32:23.296426[NOTICE]fpm_init(),line47:fpmisrunning,pid30587

在这几句的前面，是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