Nginx 502 的常见原因与排查顺序

502 Bad Gateway 的含义很明确：Nginx 本身活着，但它身后的应用没有给出有效响应。问题通常不在 Nginx，在后端。排查按从进程到权限的顺序逐层看，别一上来就改配置。 一、后端进程还活着吗 ``` ps -ef | grep php-fpm # 换成 node / java / gunicorn 同理 systemctl status php-fpm ss -lntp | grep 9000 # 端口在监听吗 ``` 进程不存在或端口没监听，直接看应用自己的日志和 systemctl 报错。这是最常见的原因：内存不足被内核杀掉（dmesg | grep -i oom 可确认）、应用启动失败、监听端口和 Nginx 转发目标对不上。 二、进程数是不是满了 PHP-FPM 场景高发： ``` pm = dynamic pm.max_children = 50 ``` 观察 pm.status_path 输出的 active 数值，或直接数进程数。达到 max_children 后新请求排队，Nginx 等不到响应就报 502。处理办法：适当调大 max_children，但要先算内存账——每个进程约 80 MB 的话，50 个就是 4 GB，内存不够先扩配置。更重要的是查为什么单个请求这么慢，慢请求吃光进程才是根因。还有一种隐蔽情况：后端脚本随机崩溃后被 systemd 拉起，表现为 502 间歇出现，把报错时间和访问高峰对上时间轴，比盯单个请求有效。 三、error.log 说了什么 看 Nginx 错误日志的具体一行，三种典型： ``` connect() failed (111: Connection refused) # 端口没服务，回到第一步 upstream timed out # 慢，往超时配置方向查 connect() failed (13: Permission denied) # 权限问题，往下看 ``` 一行日志对应一个方向，比盲猜快得多。502 频发但后端进程明明在跑时，去翻应用自己的日志，多数应用在拒绝连接或内部出错时都会写明原因。 四、socket 与权限对不对 PHP-FPM 走 unix socket 时常见两个坑：socket 文件属主不对，listen.owner 与 listen.group 要和 Nginx worker 用户一致（通常是 www-data 或 nginx）；SELinux 开启时 Nginx 无权连上游，setsebool -P httpd_can_network_connect 1 可解。权限类报错在改过运行用户或刚升级之后高发，对照变更记录看，往往一句话就能定位。改完 nginx -t && nginx -s reload，再 curl 一次验证。 预防动作：给关键服务配 systemctl 自动重启（Restart=on-failure），加每分钟一次的首页探针告警。502 与 504 混着出现时，多半是进程池在满负荷边缘反复横跳，方向仍然是查慢请求。问题要靠告警发现，不能靠用户反映。