Unix Socket权限不足导致502的本质是Nginx Worker进程无法访问上游socket文件，因属主/属组不匹配、socket文件缺少写权限（如非srw-rw----）、或任一父目录缺失执行（x）权限，致使connect()失败并报“(13: Permission denied)”。
Unix Socket 权限不足导致的 502，本质是 Nginx Worker 进程无法访问上游服务监听的 socket 文件（如 /var/run/php/php8.2-fpm.sock 或自定义的 .sock 文件），从而在连接阶段失败，报出 connect() failed (13: Permission denied) —— 这类错误常被误判为后端没启或配置错端口，实则卡在文件系统权限层。
确认错误日志是否指向 socket 权限问题
Nginx error.log 中出现以下任一关键词，就高度提示 Unix Socket 权限异常：
connect() failed (13: Permission denied) while connecting to upstream-
Permission denied同时 upstream 地址是unix:/path/to/xxx.sock形式 - 没有
Connection refused (111)或No route to host (113)，排除网络/端口类问题
检查 socket 文件属主、属组与权限
进入 socket 所在目录（如 /var/run/php/），执行：
ls -l /var/run/php/php8.2-fpm.sock
重点关注三部分：
-
属主（User）：应与 Nginx Worker 进程用户一致（通常是
www-data、nginx或php） - 属组（Group）：若 Nginx Worker 不是属主，至少需属于该组，且组有读写权限
-
权限位：socket 文件需有
srw-rw----或更宽松（如srw-rw-rw-），其中s表示 socket 类型，rw-对应用户/组的读写权；缺少w（写权限）即无法 connect
核对 Nginx Worker 进程的实际运行用户
别只看 nginx.conf 里的 user 指令，要确认真实身份：
- 查当前 Worker 进程 UID：
ps aux | grep nginx | grep -v master | head -1 | awk '{print $1}' - 查进程详细用户信息：
ps -o pid,user,group,comm -C nginx - 若用 systemd 启动，还可看：
systemctl show nginx --property=SupplementaryGroups（确认补充组）
常见陷阱：Nginx 配置 user www-data;，但 PHP-FPM sock 属主是 root、权限为 srw-------，此时 www-data 用户既不是属主、也不在属组、更无权限，必然 Permission denied。
同步检查 socket 目录的执行（x）权限
Unix Socket 路径中的**每一级父目录**都必须对 Nginx Worker 用户有 x（执行）权限，否则无法“进入”路径到达 socket 文件：
- 例如 socket 是
/var/run/php/php8.2-fpm.sock，则/var、/var/run、/var/run/php都需有x - 检查命令：
namei -l /var/run/php/php8.2-fpm.sock（显示各级目录权限和属主） - 典型问题：
/var/run/php属主root、权限drwx------→ 其他用户进不去 → Permission denied
验证与修复建议
临时验证可改权限（仅用于测试）：
- 放宽 socket 目录权限：
sudo chmod 755 /var/run/php - 调整 socket 文件属组并加组写权限：
sudo chgrp www-data /var/run/php/php8.2-fpm.sock && sudo chmod 660 /var/run/php/php8.2-fpm.sock
长期方案优先走标准实践：
- PHP-FPM 配置中设置
listen.owner = www-data、listen.group = www-data、listen.mode = 0660 - 确保
systemd启动 PHP-FPM 时未覆盖权限（检查/lib/systemd/system/php*-fpm.service中是否有DynamicUser=yes冲突） - 避免用
root启动 FPM 并生成 socket，除非明确配置了降权参数
