Unix Socket 权限与 FPM 连接排障

Nginx 与 PHP-FPM 使用 Unix Socket 通信时，站点出现 502，不一定是 FPM 没有启动。上游路径不一致、Socket 文件权限不足或目录无法访问，都可能导致连接失败。排障应先确认连接目标，再检查实际运行状态和权限，避免一上来就放宽权限。

先确认双方指向同一处

检查 FPM 池配置中的 listen，再核对 Nginx 的 fastcgi_pass。两者必须指向同一个 Socket 路径；如果站点使用多个服务块、多个 PHP 版本，或通过变量选择上游，应逐一检查，不能只看一份配置。

配置文件一致仍不足以证明连接正常：修改可能尚未重载，也可能存在多个池，或由 systemd 接管 Socket。还需检查进程当前实际监听的路径，以及目标 Socket 文件是否存在。若路径不存在，应先排查 FPM 池是否正常运行、配置是否生效，不要急于修改文件权限。

按访问身份检查权限

Socket 连接依赖文件权限。应核对 Socket 的所有者、所属组和权限，以及实际发起连接的 Nginx 工作进程身份。FPM 的 listen.owner、listen.group 和 listen.mode 用于设置 Socket 的相应属性；配置是否合适，要以 Nginx 的实际运行身份为依据，而不是只看配置项名称。

路径中的目录也需要检查：即使 Socket 文件本身允许访问，进程无法通过目录到达该文件，连接仍会失败。应修正具体的身份或目录访问问题，而不是把 Socket 或目录权限放宽到所有用户均可访问。

修改后验证连接与业务

保留原配置副本，修改后检查配置并重载相关服务，再确认实际监听路径和 Socket 权限已经变化。如果 Nginx 上游也有调整，应确认其配置检查通过并完成重载。随后访问首页、后台登录和媒体上传等实际业务路径；若仍有 502 或 504，结合 Nginx 错误日志与 FPM 日志继续定位。

Socket 路径和权限应按本机实际情况设置，不宜照搬其他服务器的示例。若确认故障由本次变更引起，应恢复备份并重新验证业务，同时保留排障记录，避免下次重载后重复出现同一问题。