Nginx 502 bad gateway高频出现

Nginx 502 Bad Gateway 的本质是 Nginx 作为反向代理，无法从后端进程（如 PHP-FPM、Java、Python 等）拿到有效响应。
高频出现一般有两个方向：后端进程频繁崩溃或卡死，以及 Nginx 等待后端的超时时间设置不合理。
本文按先看进程、再调超时的顺序，带你从零完成排查和修复。

第一步：确认后端进程状态

502 出现时，先不要急着改配置文件。
用下面命令看 PHP-FPM 是否在运行：

ps -ef | grep php-fpm
systemctl status php-fpm

如果服务已经挂了，会看到进程不存在或状态显示 failed。
此时先启动服务：

systemctl restart php-fpm

如果重启后不久又挂掉，说明后端进程自身不稳定。
查看 PHP 错误日志通常能直接定位原因：

tail -n 100 /var/log/php-fpm/error.log

对于 Java 应用，则检查对应服务的端口监听状态：

ss -lntp | grep 8080

进程存在但端口不监听，同样会触发 502。

第二步：查 Nginx 错误日志锁定方向

进程正常仍然高频 502，就走日志排查。
Nginx 错误日志路径通常在 /var/log/nginx/error.log，先看尾部最新报错：

tail -n 50 /var/log/nginx/error.log

常见两种提示：

• connect() failed (111: Connection refused)：后端端口没在监听，或监听地址与 Nginx 配置不一致。
• upstream timed out (110: Connection timed out)：后端进程活着但响应太慢，需要调大超时时间。

如果同一个请求批量报 111，优先检查后端监听的是 127.0.0.1 还是 Unix Socket，并确认 fastcgi_pass 或 proxy_pass 写的目标一致。
Socket 路径错误时，Nginx 会直接连接失败。

第三步：调整 Nginx 超时参数

确认后端服务正常、日志也指向超时，就去调整超时配置。
以 PHP-FPM 最常见的 fastcgi 转发为例，打开站点配置文件：

vim /etc/nginx/conf.d/your-site.conf

在 location ~ \.php$ 或 location / 块内加入：

fastcgi_connect_timeout 30s;
fastcgi_send_timeout 60s;
fastcgi_read_timeout 60s;

• fastcgi_connect_timeout：Nginx 与 PHP-FPM 建立连接的超时时间，默认 60 秒，通常保持 5-30 秒即可。
• fastcgi_read_timeout：Nginx 等待 PHP-FPM 返回数据的超时时间。接口或脚本执行较慢时，建议调到 60-120 秒。

反向代理到 Java、Python 等后端时，对应调整：

proxy_connect_timeout 10s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

修改完成后先测试配置再重载：

nginx -t
nginx -s reload

注意 -s reload 只是平滑重载配置，不是重启进程，不会中断现有连接。

避坑：这些情况改超时无效

• 改了配置文件但没重载：nginx -t 通过后必须执行 nginx -s reload 才会生效。
• 混淆 PHP 超时和 Nginx 超时：PHP-FPM 侧也有 request_terminate_timeout，默认 30 秒，接口执行超过这个时间会被强制终止，Nginx 再等也没用。可在 PHP-FPM 配置中适当调大并观察效果。
• 盲目把超时调成几分钟：超时越大，用户等待越久，也越容易堆积连接。建议先定位慢请求是 MySQL 慢查询、第三方接口还是代码本身，再针对性优化，而不是无限加大超时。

验证 502 是否真正恢复

完成以上操作后，用命令行直接模拟请求，观察返回状态码：

curl -I http://127.0.0.1/your-page

正常情况会返回 200。
然后持续访问一段时间，确认高频 502 不再复现。
如果仍偶发，反复查看 Nginx 错误日志和后端状态，把进程挂掉的具体时间点和日志条数对应上，多半能发现是资源耗尽还是代码异常导致的后端进程退出。

回到最初的问题：Nginx 502 Bad Gateway 高频出现时，优先确认后端进程存活、连接配置一致，再按日志提示调整 fastcgi_read_timeout 或 proxy_read_timeout。
遇到异常不要急着重启，先记录日志，再做针对性修改，才能把问题真正解决。