403 Forbidden (13: Permission denied) 根本原因是Nginx进程用户无权访问路径，须按错误日志→路径x/r权限→运行用户→SELinux/AppArmor四层排查：先查/var/log/nginx/error.log中“(13: Permission denied)”，再逐级验证目录x权限和文件r权限，确认nginx用户身份并sudo -u nginx实测访问，最后检查SELinux或AppArmor拦截。
遇到 Nginx 返回 403 Forbidden (13: Permission denied)，核心不是“网页打不开”，而是Nginx 进程被系统明确拒绝访问某个文件或目录。排查必须从日志出发，逐层验证权限链和策略限制。
看错误日志定位具体失败点
这是最不可跳过的一步。直接查错误日志：
sudo tail -n 30 /var/log/nginx/error.log- 重点找含
(13: Permission denied)的行，例如：open() "/var/www/html/index.html" failed (13: Permission denied)
这一行会明确告诉你：Nginx 尝试打开哪个路径失败了——这个路径就是你后续所有检查的起点。
检查整个路径的执行权限（x）和文件读权限（r）
Nginx 用户必须对从根目录到目标文件的每一级父目录都有 x 权限，对目标文件本身有 r 权限。比如路径是 /var/www/html/index.html，需依次检查：
-
ls -ld /→ 必须有x（通常默认有） -
ls -ld /var→ 必须有x -
ls -ld /var/www→ 必须有x -
ls -ld /var/www/html→ 必须有x -
ls -l /var/www/html/index.html→ 文件必须有r
修复示例（以 CentOS/RHEL 为例）：
-
sudo chmod 755 /var/www/html（目录设为 rwxr-xr-x） -
sudo chmod 644 /var/www/html/index.html（文件设为 rw-r--r--） - 避免用
chmod 777，存在安全风险
确认 Nginx 实际运行用户并手动验证
别只看配置文件里的 user 指令，要确认它真正在用谁跑：
- 查配置：
grep "^user" /etc/nginx/nginx.conf（常见值：nginx、www-data） - 查进程：
ps aux | grep "nginx: worker process"看 USER 列 - 手动模拟访问：
sudo -u nginx cat /var/www/html/index.html
如果这步报错 Permission denied，说明权限还没到位；成功则说明问题在其他层面。
检查 SELinux 是否拦截（CentOS/RHEL 默认启用）
即使文件权限全对，SELinux 也可能阻止 Nginx 访问 Web 目录：
- 查状态：
sestatus→ 若显示enforcing，就需排查 - 临时测试：
sudo setenforce 0，再刷新页面看 403 是否消失 - 若消失，说明是 SELinux 导致，应恢复并打标签：
sudo setenforce 1sudo chcon -Rt httpd_sys_content_t /var/www/html
Ubuntu/Debian 默认用 AppArmor，可查 aa-status，处理逻辑类似。
