nginx报502 Bad Gateway怎么排查？一套流程走到底

502 Bad Gateway是nginx最经典的报错之一。后台几乎每天都有人问这个问题。整理一套排查流程，按这个顺序走，95%的情况都能定位到原因。

第一步：确认后端服务还活着

502的意思是nginx收到了请求，转发给后端（PHP-FPM、Node、Gunicorn等），但后端没给正常响应。先看看后端进程在不在：

PHP站点：ps aux | grep php-fpm。如果没有进程在跑，启动它：systemctl start php7.4-fpm（版本号换你实际的）。

Node站点：pm2 list 或者 systemctl status node-app。

如果进程在跑但还是502，看下一步。

第二步：检查nginx和后端的通信方式

nginx通过两种方式跟后端通信：TCP端口或Unix socket。打开nginx配置文件，找到fastcgi_pass或proxy_pass那一行：

fastcgi_pass 127.0.0.1:9000; → TCP方式，检查9000端口是不是被别的程序占了：netstat -tlnp | grep 9000。

fastcgi_pass unix:/run/php/php7.4-fpm.sock; → Socket方式，检查socket文件存不存在，权限对不对：ls -la /run/php/php7.4-fpm.sock。权限不对的话nginx没法往里写数据。

最常见的坑：PHP-FPM配置里监听的端口是9000，但nginx里去连了socket文件，或者反过来。两边必须一致。

第三步：看日志

502的原因通常写在日志里，很多人不看日志就瞎改配置。

nginx错误日志：tail -50 /var/log/nginx/error.log

PHP-FPM日志：tail -50 /var/log/php7.4-fpm.log（路径可能不同，去php-fpm.conf里找error_log那一行）

常见日志信息及含义：

"connect() failed (111: Connection refused)" → 后端进程没在监听nginx配置的端口或socket。

"upstream timed out (110: Connection timed out)" → 后端进程在跑但处理请求太慢，超时了。需要检查你的PHP/Node应用是否卡在某个慢查询或死循环。

"recv() failed (104: Connection reset by peer)" → 后端进程崩溃了。检查PHP/Python的错误日志，可能是代码出bug导致进程直接挂掉。

第四步：调超时参数

如果日志显示"upstream timed out"，而且确认后端没有死循环，那可能是某个请求确实需要更长时间（比如导出大文件、处理图片）。在nginx的location块里加大超时时间：

fastcgi_read_timeout 300s;

proxy_read_timeout 300s;

PHP-FPM那边也要调：在php-fpm.conf里把request_terminate_timeout调大或设成0（不限制）。

第五步：检查资源耗尽

服务器内存满了或者PHP-FPM进程数达到上限也会导致502。top看一下内存使用，free -h看可用内存。ps aux | grep php-fpm | wc -l 看当前PHP-FPM进程数，对比配置文件里pm.max_children的值——如果接近上限了，需要调大max_children（前提是内存够用）。

万一这些全试了还不行，把nginx和PHP-FPM的错误日志贴到评论区，我帮你看看。

标签： Nginx 502错误 故障排查 PHP-FPM 服务器运维