Nginx报“(13: Permission denied)”本质是worker进程用户在OS层面被拒绝访问，需依次确认运行用户、路径r/x权限、SELinux/AppArmor策略、临时目录及socket文件权限。
看到 error_log 里出现 (13: Permission denied)，基本就是文件或目录权限不匹配导致的访问失败。排查不靠猜，而要顺着日志里的路径、用户、权限三层线索一步步验证。
盯住 error_log 中的报错路径和错误码
打开 /var/log/nginx/error.log，重点找含以下结构的行：
- open() "/path/to/file" failed (13: Permission denied) → 文件不可读，检查该文件权限（需 r）及父目录执行权（需 x）
- stat() "/path/to/dir" failed (13: Permission denied) → 目录不可进入或不可读，问题大概率出在某一级父目录缺 x 权限
- connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied) → PHP-FPM 套接字属主/权限不匹配，常与 Nginx 用户不一致有关
确认 Nginx 实际运行用户
配置文件里写的 user 指令不一定生效，必须查真实进程：
- 运行 ps aux | grep nginx，找到 master process 行第二列的用户（如 www-data）
- 再核对 /etc/nginx/nginx.conf 开头的 user 指令是否一致；若用 systemd 启动，还要看 /lib/systemd/system/nginx.service 中的 User= 设置
- 最终以 worker 进程实际运行用户为准
逐级检查目标路径的归属与权限
拿到报错路径后，从根开始一级级验证：
- 执行 namei -l /var/www/html/wp-config.php，查看每层目录的属主、属组和权限，特别注意中间某级是否缺失 x（执行）权限
- 确保 Nginx 用户对目录有 x（进入）、对文件有 r（读取），上传目录还需 w（写入）
- 常见合理权限：目录 755（drwxr-xr-x），普通文件 644（rw-r--r--），私钥文件 600
- 用 chown -R www-data:www-data /var/www/html 统一归属，避免混杂
排除 SELinux 或 AppArmor 干扰
传统权限看似正确却仍报 13 错误时，可能是安全模块拦截：
- CentOS/RHEL 系统运行 getenforce 查 SELinux 状态，临时设为 permissive 模式测试：setenforce 0
- Ubuntu/Debian 系统检查 AppArmor：aa-status，临时禁用对应 profile 验证
- 若确认是安全模块导致，需用 audit2why 或 aa-logprof 生成合规策略，而非长期关闭
