今天遇到一个比较常见的网站故障：页面突然提示 502 Bad Gateway。

这种错误在使用 Nginx + PHP 环境的网站上比较常见，尤其是网站程序依赖 PHP-FPM 运行时，只要 PHP 服务异常，前端访问就可能直接出现 502。

刚开始看到 502 的时候，第一反应不是立刻重启服务器，而是先判断到底是 Nginx 问题，还是 PHP-FPM 问题。

一、问题出现时的表现

当时网站的表现是：

• 首页打开直接显示 502 Bad Gateway

• 后台也无法登录

• SSH 可以正常连接服务器

• 服务器没有宕机

• ping 服务器 IP 正常

• 域名解析也正常

从这些表现来看，服务器本身是在线的，域名解析也没有问题。

所以这次问题大概率出现在 Web 服务层。

也就是说，浏览器能访问到服务器，但 Nginx 没有成功把请求转交给后端 PHP 程序。

二、第一步：先确认 Nginx 是否正常

我先登录服务器，检查 Nginx 服务状态。

systemctl status nginx

结果显示 Nginx 是运行状态，并没有停止。

然后我又测试了一下配置文件：

nginx -t

返回结果正常，没有语法错误。

这一步基本可以说明：

• Nginx 服务本身没有停止

• Nginx 配置文件没有明显语法错误

• 502 不太像是 Nginx 主服务挂掉导致的

所以接下来重点排查 PHP-FPM。

三、第二步：检查 PHP-FPM 服务状态

继续检查 PHP-FPM 状态。

不同服务器环境里 PHP-FPM 的服务名称可能不一样，比如：

systemctl status php-fpm

有些版本可能是：

systemctl status php7.4-fpm

或者：

systemctl status php8.0-fpm

我这里检查后发现 PHP-FPM 状态异常，服务并没有正常运行。

这就基本解释了为什么网站会出现 502。

因为 Nginx 还在运行，但 PHP-FPM 没有响应，Nginx 转发 PHP 请求失败，就会返回 502 Bad Gateway。

四、第三步：尝试重启 PHP-FPM

为了先恢复网站，我尝试重启 PHP-FPM。

systemctl restart php-fpm

但是重启后并没有马上恢复，而是提示启动失败。

这时候不能只反复执行重启命令，因为如果 PHP-FPM 启动失败，背后一定有原因。

下一步需要看错误日志。

五、第四步：查看 PHP-FPM 错误日志

我查看了 PHP-FPM 相关日志。

常见日志位置可能在：

/var/log/php-fpm/error.log

也可能在：

/www/server/php/版本号/var/log/php-fpm.log

如果使用宝塔环境，也可以直接到对应 PHP 版本的日志目录查看。

日志里出现了比较关键的信息：

PHP-FPM 进程启动失败，原因和配置文件有关。

继续检查后发现，是之前调整 PHP 配置时，某个参数设置不合理，导致 PHP-FPM 无法正常启动。

六、第五步：检查 Nginx 与 PHP-FPM 的连接方式

除了 PHP-FPM 本身状态，我还检查了 Nginx 配置里连接 PHP-FPM 的方式。

常见有两种：

一种是通过端口连接：

fastcgi_pass 127.0.0.1:9000;

另一种是通过 sock 文件连接：

fastcgi_pass unix:/tmp/php-cgi.sock;

如果 PHP-FPM 实际监听的是端口，但 Nginx 配置写的是 sock 文件，就会出现连接失败。

反过来也一样。

所以排查 502 时，不能只看服务有没有启动，还要看 Nginx 和 PHP-FPM 是否连接到了同一个位置。

七、问题真正原因

这次问题最终定位为：

• Nginx 服务正常

• 域名解析正常

• 服务器网络正常

• PHP-FPM 服务异常

• PHP-FPM 配置参数不合理导致启动失败

• Nginx 无法把 PHP 请求交给后端处理

所以网站才会出现 502 Bad Gateway。

这类问题表面看是网站打不开，实际上是后端 PHP 运行环境没有正常响应。

八、实际处理过程

处理时我主要做了几步。

1. 恢复 PHP-FPM 配置

先把刚刚修改过的 PHP-FPM 配置恢复到正常值。

如果不确定是哪一项导致问题，可以先恢复最近一次修改前的备份配置。

2. 测试 PHP-FPM 是否能启动

systemctl restart php-fpm

然后查看状态：

systemctl status php-fpm

确认 PHP-FPM 已经正常运行。

3. 重新加载 Nginx

systemctl reload nginx

如果 reload 不生效，也可以重启 Nginx：

systemctl restart nginx

4. 再次访问网站

处理完成后，重新打开网站首页和后台。

页面恢复正常，502 错误消失。

九、恢复后的检查

网站恢复后，我又做了一些确认：

• 首页是否正常打开

• 后台是否可以登录

• 动态页面是否正常加载

• PHP 页面是否可以访问

• Nginx 错误日志是否还在报错

• PHP-FPM 日志是否还有异常

确认这些都正常后，才算真正处理完成。

因为有时候 502 看似恢复了，但如果 PHP-FPM 仍然频繁重启，后续还可能继续出现问题。

十、这次问题的经验总结

这次 502 问题给我的经验是：

遇到 502 Bad Gateway，不要第一时间认为服务器宕机。

正确排查顺序可以按下面来：

1. 先检查服务器是否在线

2. 再检查 Nginx 是否正常运行

3. 再检查 Nginx 配置是否正确

4. 再检查 PHP-FPM 是否运行

5. 再检查 Nginx 与 PHP-FPM 的连接方式

6. 最后查看错误日志定位具体原因

502 的本质通常是：前端服务接收到了请求，但后端服务没有正确响应。

在 Nginx + PHP 网站环境里，PHP-FPM 异常是非常常见的原因。

十一、后续优化措施

为了避免类似问题再次出现，我后面做了几个优化：

• 修改 PHP 配置前先备份

• 修改后先测试再重启服务

• 定期查看 PHP-FPM 错误日志

• 控制 PHP-FPM 最大进程数

• 避免随意调整不熟悉的参数

• 记录每次服务配置修改时间

网站环境稳定，不是靠出问题后反复重启，而是要知道每一层服务之间的关系。

Nginx、PHP-FPM、MySQL 这些组件只要其中一个出现异常，网站都可能表现为打不开、变慢或者报错。

写在最后

这次 502 Bad Gateway 的问题，最终不是 Nginx 挂了，也不是服务器宕机，而是 PHP-FPM 配置异常导致服务无法正常启动。

所以以后遇到 502，不要只盯着页面报错。

先看服务状态，再看日志，再看 Nginx 与 PHP-FPM 的连接方式，基本就能快速定位问题。