113资讯网——NGINX 502 Bad Gateway——解决方案

NGINX 502 Bad Gateway错误出现的原因较多，对于后端连接PHP服务的场景下，常见的原因有php服务响应超时，php进程不足等引起的一类服务器错误。

发生原因：

1. 1. 1. PHP FastCGI的内存不够用：
         当nginx返回静态页面时，这个问题一般不会出现，因为nginx不需要php cgi的处理而直接返回静态页面。但是当网页需要处理大量的php复杂操作的时候，例如执行api采集，或者采集页面的时候，那对php的要求是相当高的，如果配置给他的内存太少，那很容易就会导致php崩溃。
      2. max-children和max-requests：
         主机上运行着nginx php(fpm) xcache的话，访问量日均 10000+ pv左右。如果是近期出现php页面打开很慢，cpu使用率突然降至很低，系统负载突然升至很高，查看网卡的流量，也会发现突然降到了很低这样的情况，而且这种情况只持续数秒钟就恢复，这时检查php-fpm的日志文件发现了一些线索：
         1. 1.Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main()， line 271: getrlimit(nofile): max:51200， cur:51200
         2. 2.Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main()， line 371: using inherited socket fd=10， “127.0.0.1:9000″
         3. 3.Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main()， line 109: libevent: using epoll
         4. 4.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，调大以下两个参数，但是要根据主机实际情况，数值过大也不行。

         1. <value name=”max_children”>5120</value>
         2.  
         3. <value name=”max_requests”>600</value>
      3. 在开启opcache的情况下，如果出现502错误，则是由于版本导致的问题:
         如果还在用php5版本建议升级php7，如果代码不支持php7，建议更换程序与模板文件！
      4. PHP FastCGI进程数不够用：
         当网站并发访问巨大时，php fastcgi的进程不一定能响应所有的访问，因为cgi是单线程多进程工作的，也就是说cgi需要处理完一个页面后再继续下一个页面。如果进程数不够，cgi按排队处理之前的请求，队列满之后的请求只有被放弃。这个时候nginx就会不时的出现502错误。这种情况下，开启Nginx的错误日志可以很清晰的看见相应的报错，例如”all backends could not serve”。
      5. （文章原文：https://www.113p.cn/231.html）