Nginx 403 Forbidden（13: Permission denied）核心是权限链断裂：需逐级验证路径中每个目录的执行（x）权限、文件的读取（r）权限、Nginx worker用户匹配性，以及SELinux/AppArmor等安全模块拦截。
遇到 Nginx 返回 403 Forbidden 错误，且明确指向静态文件（如 /css/style.css、/img/logo.png）无法加载，核心问题不是“找不到”，而是“不让你读”——Nginx worker 进程被系统权限或安全策略拦在了门外。解决的关键是顺着访问链逐层确认：路径是否存在 → 是否可进入（x）→ 是否可读取（r）→ 是否被系统安全模块拦截。
查错误日志，锁定具体失败点
这是最快最准的第一步。Nginx 的 error.log 会直接告诉你卡在哪一级：
- 运行
sudo tail -n 30 /var/log/nginx/error.log（或你配置中error_log指定的路径） - 重点找含
(13: Permission denied)的行，例如：open() "/var/www/static/js/app.js" failed (13: Permission denied) - 这个报错说明 Nginx 尝试打开该文件时被拒绝，接下来只需检查这个路径本身和它的每一级父目录
检查路径权限与执行权限
Nginx 要读一个文件，必须能“走到它面前”。这意味着从根目录（/）开始，到目标文件的**每一级父目录**都必须对 Nginx 用户有 执行（x）权限；而文件本身必须有 读（r）权限：
- 用
ls -ld /var /var/www /var/www/static /var/www/static/js逐级检查目录权限 - 确保每个目录至少是
755（即属主 rwx，属组和其他人 rx） - 用
ls -l /var/www/static/js/app.js确认文件权限为644或更宽松（如644表示属主 rw，属组和其他人 r） - 常见错误：目录权限是
750，但 Nginx 用户不在属组里 → 无法进入；或目录是755，但文件是600→ 无法读取
确认 Nginx worker 用户与文件属主匹配
worker 进程不是以 root 身份干活的，它按 nginx.conf 中的 user 指令运行（如 user nginx; 或 user www-data;）。它只能访问自己有权限的文件：
- 用
ps aux | grep "nginx: worker"看实际运行用户 - 用
ls -ld /var/www/static查看目录属主和属组 - 若不一致，有两种稳妥做法：
– 把目录属主改为 Nginx 用户：sudo chown -R nginx:nginx /var/www/static
– 或让 Nginx 以你已有权限的用户运行（如user www-data;），再重启服务 - 验证方式（推荐）：
sudo -u nginx cat /var/www/static/js/app.js，如果报错，说明权限还没到位
排查 SELinux 或 AppArmor 干预
尤其在 CentOS/RHEL 或 Ubuntu 启用 AppArmor 的系统上，即使文件权限完全正确，强制访问控制也会拦截：
- 运行
sestatus（CentOS/RHEL）或aa-status（Ubuntu）确认是否启用 - 临时测试：运行
sudo setenforce 0（SELinux）或sudo systemctl stop apparmor（AppArmor），刷新页面看是否恢复 - 若恢复，说明是安全模块导致。长期方案不是关它，而是打标签：
sudo chcon -Rt httpd_sys_content_t /var/www/static（SELinux）
或调整 AppArmor profile 允许 Nginx 访问该路径
