Nginx 502 错误触发条件与解决办法汇总

Question

一些运行在 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 的内存不足了。

如果这样修改了还解决不了问题，可以参考下面这些方案：

3、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

调大以下两个参数（根据服务器实际情况，过大也不行）

<value name=”max_children”>5120</value>
<value name=”max_requests”>600</value>

然后重启 php-fpm。

5、增加缓冲区容量大小

将 nginx 的 error log 打开，发现 pstream sent too big header while reading response header from upstream 这样的错误提示。查阅了一下资料，大意是 nginx 缓冲区有一个 bug 造成的,我们网站的页面消耗占用缓冲区可能过大。参考老外写的修改办法增加了缓冲区容量大小设置，502 问题彻底解决。后来系统管理员又对参数做了调整只保留了 2 个设置参数：client head buffer，fastcgi buffer size。

6、request_terminate_timeout

如果主要是在一些 post 或者数据库操作的时候出现 502 这种情况，而不是在静态页面操作中常见，那么可以查看一下 php-fpm.conf 设置中的一项：request_terminate_timeout

这个值是 max_execution_time，就是 fast-cgi 的执行脚本时间。0s 为关闭，就是无限执行下去。（当时装的时候没仔细看就改了一个数字）发现，问题解决了，执行很长时间也不会出错了。优化 fastcgi 中，还可以改改这个值 5s 看看效果。

php-cgi 进程数不够用、php 执行时间长、或者是 php-cgi 进程死掉，都会出现 502 错误。