Nginx出现502但PHP-FPM正常怎么办？

Nginx突然返回502，执行 systemctl status php-fpm 却显示服务正在运行，这两条信息并不矛盾。PHP-FPM进程存在，只能证明它没有退出，不能证明Nginx有权限连接它正在监听的Unix Socket。

这类故障最有价值的证据不在服务状态的绿色提示里，而在Nginx错误日志。先确认502发生时间，再判断是路径不存在、权限拒绝，还是连接后被上游提前关闭。

错误日志先决定排查方向

在502出现后立即查看对应站点错误日志，或从Nginx主错误日志筛选相同时间段。典型的权限问题可能出现下面这类记录：

connect() to unix:/run/php/php-fpm.sock failed (13: Permission denied) while connecting to upstream

Permission denied 指向Nginx工作进程无法访问Socket或其上级目录。No such file or directory 更接近路径写错、FPM尚未创建Socket或版本切换后路径变化。Connection refused、upstream prematurely closed connection 又是其他证据，不能照搬权限修复。

先按错误码分支，不要看到502就调大超时时间。 连接权限被拒绝发生在请求进入PHP之前，增加 fastcgi_read_timeout 不会让权限自动正确。

核对Nginx实际使用的Socket路径

配置文件里可能残留多个PHP版本，真正生效的 fastcgi_pass 不一定是刚才打开的那一份。先让Nginx输出合并后的有效配置：

sudo nginx -T 2>/dev/null | grep -n fastcgi_pass

Nginx官方文档允许 fastcgi_pass 指向IP加端口，也可以指向Unix Socket。这里需要把有效配置中的路径，与PHP-FPM池配置里的 listen 完整对照，字符和版本号都要一致。

再确认Socket确实存在：

sudo stat /run/php/php-fpm.sock
sudo ss -xlpn | grep php

示例路径必须替换为日志里的真实路径。路径不存在时，不能通过修改权限解决，应检查FPM池是否加载、服务启动日志以及运行目录是否创建。

权限不只看Socket文件本身

Nginx要连接Socket，除了文件本身需要读写权限，还必须能穿过路径上的每一级目录。可以执行：

sudo namei -l /run/php/php-fpm.sock

同时确认Nginx工作进程实际使用的账号：

ps -eo user,group,comm | grep nginx

Ubuntu和Debian常见Web账号是 www-data，Rocky Linux、AlmaLinux及面板环境可能使用 nginx、apache 或自定义账号。不要直接复制别人的用户名，配置必须与本机进程身份对应。

SELinux启用时，传统文件权限看起来正确仍可能被安全上下文拦截。Rocky Linux、AlmaLinux等环境需要结合审计日志确认，不能一看到权限拒绝就永久关闭SELinux。

FPM池配置才是持久修复位置

PHP-FPM池配置可以通过 listen.owner、listen.group 和 listen.mode 设置Unix Socket权限。PHP官方文档说明，Linux上Web服务器需要具备Socket读写权限；支持POSIX ACL的环境启用 listen.acl_users 或 listen.acl_groups 后，传统的owner和group设置会被忽略。

常见配置思路如下，账号和路径需按实际环境调整：

listen = /run/php/php-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

修改前先备份当前池配置，并用对应PHP-FPM命令测试配置语法。多版本PHP环境的服务名和配置路径不同，编辑错误版本不会改变线上Socket。

chmod 777为什么不是修复

直接对Socket执行 chmod 777 可能让页面马上恢复，因此很容易被误认为已经解决。它扩大了本地进程访问权限，而且FPM重启后Socket会重新创建，手工权限通常随之丢失。

更危险的做法是递归修改 /run、PHP配置目录或网站目录权限。这会影响其他服务，还会掩盖真正的账号关系。最小改动应落在正确的FPM池配置、Nginx运行用户或必要的ACL上，并在重启后验证权限能够自动重建。

按最小范围应用变更

先测试PHP-FPM和Nginx配置语法，再重启对应FPM服务并平滑重载Nginx。操作命令中的服务名应以本机版本为准：

sudo systemctl restart php-fpm
sudo nginx -t
sudo systemctl reload nginx

线上存在多个PHP版本时，重启前要确认站点使用的服务。数据库和Nginx本身没有必要跟随FPM全部重启。修改后立即查看Socket属主、属组和模式，确认它来自配置而不是一次性的手工命令。

旧环境长期叠加面板、多个PHP版本和手工权限后，继续追补规则可能越来越难维护。准备并行迁移时，可以用 萤光云 建立规格清楚的新环境，也可以用按小时计费的 LightNode 保留短期对照服务器。迁移的价值在于重建可解释的用户与权限关系，不能把原服务器的混乱配置原样复制过去。

重启FPM后仍正常才算通过验收

先在服务器本机携带正确Host头访问站点，确认动态页面返回正常，再从外部检查前台、后台登录和表单提交。随后观察Nginx错误日志，确保没有新增相同的权限拒绝。

最后再重启一次对应PHP-FPM服务，确认Socket重新创建后的路径和权限仍正确。验收应同时满足Nginx配置指向正确Socket、FPM池监听正常、动态请求成功、错误日志不再出现权限记录。只靠一次 chmod 让页面暂时打开，不算故障关闭。