共计 5069 个字符，预计需要花费 13 分钟才能阅读完成。
一些运行在 Nginx 上的网站有时候会出现“502 Bad Gateway”错误，有些时候甚至频繁的出现。以下是小编搜集整理的一些 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 调大以下两个参数 (根据服务器实际情况，过大也不行）
复制代码 代码如下:
<value>5120</value><value>600</value>
然后重启 php-fpm。
二、增加缓冲区容量大小
将 nginx 的 error log 打开，发现“pstream sent too big header while reading response header from upstream”这样的错误提示。查阅了一下资料，大意是 nginx 缓冲区有一个 bug 造成的, 我们网站的页面消耗占用缓冲区可能过大。参考老外写的修 改办法增加了缓冲区容量大小设置，502 问题彻底解决。后来系统管理员又对参数做了调整只保留了 2 个设置参数：client head buffer，fastcgi buffer size。
三、request_terminate_timeout
如果主要是在一些 post 或者数据库操作的时候出现 502 这种情况，而不是在静态页面操作中常见，那么可以查看一下 php-fpm.conf 设置中的一项：
request_terminate_timeout
这个值是 max_execution_time，就是 fast-cgi 的执行脚本时间。
0s
0s 为关闭，就是无限执行下去。（当时装的时候没仔细看就改了一个数字）问题解决了，执行很长时间也不会出错了。优化 fastcgi 中，还可以改改这个值 5s 看看效果。
php-cgi 进程数不够用、php 执行时间长、或者是 php-cgi 进程死掉，都会出现 502 错误。Nginx 502 Bad Gateway 错误的解决办法 2
今天，我的 VPS 频繁提示 Nginx 502 Bad Gateway 错误了，重启了 VPS 解决之后又出现，很烦。有点想不通，前两天网站达到了 1290 的访问量都没有出什么问题，怎么这次就出现了 502 Bad Gateway？郁闷啊！！！在搜索了很久，终于找到了不少相关的答案，希望修改之后不会再出现这个错误了。唉，既然在网上找了那么久的答案，那当然得把有用的东西记录下，免得我下次再去谷歌~
由于我是采用了 LNMP 一键安装包，出了问题肯定要先到官方论坛去搜索下了，真好，官方有个这样的置顶帖，大家先瞧瞧。
LNMP 一键安装包官方的：
第一种原因：目前 lnmp 一键安装包比较多的问题就是 502 Bad Gateway，大部分情况下原因是在安装 php 前，脚本中某些 lib 包可能没有安装上，造成 php 没有编译安装成功。解决办法：可以尝试根据 lnmp 一键安装包中的脚本手动安装一下，看看是什么错误导致的。
第二种原因：
在 php.ini 里，eaccelerator 配置项一定要放在 Zend Optimizer 配置之前，否则也可能引起 502 Bad Gateway
第三种原因：
在安装好使用过程中出现 502 问题，一般是因为默认 php-cgi 进程是 5 个，可能因为 phpcgi 进程不够用而造成 502，需要修改 /usr/local/php/etc/php-fpm.conf 将其中的 max_children 值适当增加。
第四种原因：
php 执行超时，修改 /usr/local/php/etc/php.ini 将 max_execution_time 改为 300
第五种原因：
磁盘空间不足，如 mysql 日志占用大量空间
第六种原因：
查看 php-cgi 进程是否在运行
也有网友给出了另外的解决办法：
Nginx 502 Bad Gateway 的含义是请求的 PHP-CGI 已经执行，但是由于某种原因（一般是读取资源的问题）没有执行完毕而导致 PHP-CGI 进程终止，一般来说 Nginx 502 Bad Gateway 和 php-fpm.conf 的设置有关。
php-fpm.conf 有两个至关重要的参数，一个是 max_children，另一个是 request_terminate_timeout，但是这个值不是通用的，而是需要自己计算的。在安装好使用过程中出现 502 问题，一般是因为默认 php-cgi 进程是 5 个，可能因为 phpcgi 进程不够用而造成 502，需要修改 /usr/local/php/etc/php-fpm.conf 将其中的 max_children 值适当增加。
计算的方式如下：
如果你的服务器性能足够好，且宽带资源足够充足，PHP 脚本没有系循环或 BUG 的话你可以直接将 request_terminate_timeout 设置成 0s。0s 的含义是让 PHP-CGI 一直执行下去而没有时间限制。而如果你做不到这一点，也就 是说你的 PHP-CGI 可能出现某个 BUG，或者你的宽带不够充足或者其他的原因导致你的 PHP-CGI 假死那么就建议你给 request_terminate_timeout 赋一个值，这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高，20 分钟 -30 分 钟都可以。而 max_children 这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi 的进程多了就会处理的很快，排队的请求就会很少。设置 max_children 也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个 php-cgi 所耗费的内存在 20M 左右。
按照官方的答案，排查了相关的可能，并结合了网友的答案，得出了下面的解决办法。
1、查看 php fastcgi 的进程数（max_children 值）
代码：netstat -anpo | grep“php-cgi”| wc -l
5（假如显示 5）
2、查看当前进程
代码：top 观察 fastcgi 进程数, 假如使用的进程数等于或高于 5 个，说明需要增加（根据你机器实际状况而定）
3、调整 /usr/local/php/etc/php-fpm.conf 的相关设置
max_children 10
request_terminate_timeout 60s
max_children 最多 10 个进程，按照每个进程 20MB 内存，最多 200MB。
request_terminate_timeout 执行的时间为 60 秒，也就是 1 分钟。
nginx.conf 这个改动较少。
worker_rlimit_nofile 100000;
events
{
use epoll;
worker_connections 100000;
multi_accept on;
}
php-fpm.conf 这个改动较多，可以对比自己的文件修改参数
listen = /tmp/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www
pm = dynamic
pm.max_children = 600
pm.start_servers = 30
pm.min_spare_servers = 20
pm.max_spare_servers = 500
request_terminate_timeout = 100
pm.max_requests = 10240
request_slowlog_timeout = 60s
slowlog = var/log/slow.log
