宝塔面板下 Nginx + PHP-FPM 502 Bad Gateway 的排查与修复

一、问题背景

2026 年 8 月 5 日晚，我的个人博客站点 qianjiyu.com 突然全站无法访问，浏览器统一返回 502 Bad Gateway。

服务器环境如下：

系统：CentOS（腾讯云轻量应用服务器）
面板：宝塔（BT-Panel）
Web 服务：Nginx
运行环境：PHP 7.4（PHP-FPM）
架构：Nginx + PHP-FPM（Unix Socket 模式）

由于该服务器已稳定运行 2 年多未重启，此次故障具有一定的代表性，特此记录排查过程，以供参考。

二、故障现象

所有访客访问站点均返回 502 Bad Gateway；
服务器 IP 可 Ping 通；
服务器端口（80/443）可 Telnet 通；
宝塔面板可正常打开，服务状态显示异常；
搜索引擎蜘蛛抓取失败，影响 SEO。

三、初步排查

1. 检查后端服务状态

首先怀疑 PHP-FPM 是否存活，执行：

systemctl status php-fpm-74

结果显示：

Active: active (running) since Wed 2024-05-29

PHP-FPM 主进程和 Worker 进程均存在，说明 PHP-FPM 并未崩溃。

2. 检查 Nginx 全局错误日志

查看 Nginx 全局错误日志：

tail -n 50 /www/server/nginx/logs/error.log

日志中仅有大量：

[notice] signal process started

这些都是正常的重载日志，没有任何 502 相关的错误信息，一度让排查陷入僵局。

3. 查看站点独立错误日志（关键一步）

在宝塔环境中，502 错误通常记录在站点独立日志中，而非 Nginx 全局日志。

执行：

tail -n 50 /www/wwwlogs/qianjiyu.com.error.log

终于看到了关键报错：

connect() to unix:/tmp/php-cgi-74.sock failed (2: No such file or directory)
while connecting to upstream

四、问题根因分析

1. 什么是 `.sock` 文件？

.sock（Unix Domain Socket）文件是 Linux 下用于 本机进程间通信 的特殊文件。

在宝塔默认配置中，Nginx 通过以下配置与 PHP-FPM 通信：

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

可以理解为：

Nginx 是前台接待
PHP-FPM 是后台客服
.sock 文件是两者之间的“内部电话线”

2. 为什么会“消失”？

在 CentOS / Rocky / AlmaLinux 系统中：

/tmp 是系统级临时目录
systemd-tmpfiles 会定期清理 /tmp 目录
服务器长时间运行（2 年未重启）
PHP-FPM 启动时创建的 sock 文件被系统清理
但 PHP-FPM 主进程仍在运行，未重建 sock 文件

最终导致：

Nginx 想打电话，却发现“电话线”被保洁阿姨拔掉了。

五、解决方案

✅ 方案一：紧急恢复（立竿见影）

依次执行以下命令：

# 停止 PHP-FPM
systemctl stop php-fpm-74

# 强制清理残留进程
pkill -9 php-fpm

# 删除失效的 sock 文件
rm -f /tmp/php-cgi-74.sock

# 启动 PHP-FPM（会自动重建 sock）
systemctl start php-fpm-74

# 重启 Nginx
systemctl restart nginx

执行完成后，网站 立即恢复正常。

✅ 方案二：彻底根治（生产环境推荐）

为了避免 /tmp 被系统再次清理，将 sock 文件迁移至 PHP 专属目录。

1. 修改 PHP-FPM 配置

宝塔面板 → 软件商店 → PHP-7.4 → 配置修改

将：

listen = /tmp/php-cgi-74.sock

修改为：

listen = /www/server/php/74/var/run/php-cgi-74.sock

2. 修改 Nginx 站点配置

宝塔 → 网站 → 你的站点 → 配置文件

将所有：

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

修改为：

fastcgi_pass unix:/www/server/php/74/var/run/php-cgi-74.sock;

3. 重载服务

systemctl restart php-fpm-74
systemctl restart nginx

✅ 此后 sock 文件不会再被系统清理，从根本上杜绝同类 502 问题。

六、经验总结

本次故障的核心原因

PHP-FPM 的 Unix Socket 文件被系统清理，但 PHP-FPM 主进程未重建，导致 Nginx 无法转发请求，最终返回 502。

排查 502 的标准思路（可直接复用）

确认是源站问题还是 CDN 问题
检查 PHP-FPM 是否存活
查看 Nginx 站点独立错误日志（不是全局日志）
确认 .sock 文件是否存在
必要时重启 PHP-FPM

宝塔运维建议

✅ 不建议将 sock 文件放在 /tmp 目录
✅ 长期运行的服务器应定期检查磁盘空间
✅ 关注 df -h 和 PHP-FPM 日志
✅ 高并发站点建议适当调整 pm.max_children

七、写在最后

这次故障虽然表象是“全站 502”，但本质上是一个非常经典的 Linux 进程通信 + 系统机制 问题。

通过这次排查，我也更加深刻地理解了：

“服务显示 Running，不代表它能正常工作。”

希望这篇文章能帮助到遇到同样问题的同学们，少走弯路，快速恢复业务。

📌 关键词：宝塔、502 Bad Gateway、PHP-FPM、Unix Socket、Nginx、CentOS、运维排障

转载请注明：路飞博客 » 宝塔面板下 Nginx + PHP-FPM 502 Bad Gateway 的排查与修复

标签：502 Bad Gateway PHP-FPM Unix Socket

路飞博客

宝塔面板下 Nginx + PHP-FPM 502 Bad Gateway 的排查与修复

一、问题背景

二、故障现象

三、初步排查

1. 检查后端服务状态

2. 检查 Nginx 全局错误日志

3. 查看站点独立错误日志（关键一步）

四、问题根因分析

1. 什么是 `.sock` 文件？

2. 为什么会“消失”？

五、解决方案

✅ 方案一：紧急恢复（立竿见影）

✅ 方案二：彻底根治（生产环境推荐）

1. 修改 PHP-FPM 配置

2. 修改 Nginx 站点配置

3. 重载服务

六、经验总结

本次故障的核心原因

排查 502 的标准思路（可直接复用）

宝塔运维建议

七、写在最后

热门推荐

路飞博客

搜索

随机推荐

热门标签

一、问题背景

二、故障现象

三、初步排查

1. 检查后端服务状态

2. 检查 Nginx 全局错误日志

3. 查看站点独立错误日志（关键一步）

四、问题根因分析

1. 什么是 .sock 文件？

2. 为什么会“消失”？

五、解决方案

✅ 方案一：紧急恢复（立竿见影）

✅ 方案二：彻底根治（生产环境推荐）

1. 修改 PHP-FPM 配置

2. 修改 Nginx 站点配置

3. 重载服务

六、经验总结

本次故障的核心原因

排查 502 的标准思路（可直接复用）

宝塔运维建议

七、写在最后

热门推荐

路飞博客

搜索

随机推荐

热门标签

1. 什么是 `.sock` 文件？