最快定位权限类403是查/var/log/nginx/error.log中“(13: Permission denied)”，它明确表示系统级权限拒绝；再用namei -l逐级验证路径x权限，结合sudo -u worker用户模拟访问确认。
直接看 /var/log/nginx/error.log 里的报错原文，是定位权限类 403 最快的方式。关键不是“有没有 403”，而是括号里那个系统错误码。
盯住错误日志里的 (13: Permission denied)
这是 Linux 系统级权限拒绝的明确信号，代表 Nginx 工作进程被操作系统拦在了门外：
- 出现
open() "/path/to/file" failed (13: Permission denied)→ 文件或其任一上级目录缺执行（x）权限 - 出现
stat() "/path/to/dir" failed (13: Permission denied)→ 目录本身或父级路径缺 x 权限，Nginx 连“走进去”都做不到 - 出现
directory index of "/path/" is forbidden→ 不是权限问题，是没找到 index 文件且未开启 autoindex，别误判为权限不足
用 namei 一次性看清整条路径的权限断点
别手动一层层 ls -ld，用这个命令直击要害：
namei -l /var/www/myapp/index.html
输出会逐行列出从 / 到目标文件每一级的权限、属主、属组。重点找哪一级的权限列里没有 x（尤其是 other 或 group 位），比如：
-
drwxr-x--- nginx nginx /var/www→ 其他用户（others）没 x，而 Nginx 若以www-data运行，就卡在这儿 -
dr-xr-xr-x root root /root→/root默认对非 root 用户无 x，放网站进去必 403
用 Nginx 真实工作用户模拟访问
别信配置文件里的 user 行是否生效，要看实际 worker 进程跑在谁名下：
ps aux | grep "nginx: worker process" → 记下 USER 列（如 www-data）
然后用它去试：
sudo -u www-data ls -l /your/root/path/index.html
如果报 “Permission denied” 或 “No such file or directory”，说明权限链确实不通——这比看日志更直观，也排除了配置路径拼写错误的干扰。
注意符号链接和安全模块的干扰
符号链接不是“存在就能用”。日志里若出现 readlink() failed (2: No such file or directory)，说明链接文件本身被删了；若出现 stat() failed (13)，问题出在链接路径或目标路径的某一级缺 x 权限。
SELinux（CentOS/RHEL）或 AppArmor（Ubuntu）也可能静默拦截。即使 namei 和 sudo -u 都通过，仍需检查：
-
sestatus或aa-status | grep nginx - 临时禁用测试：
sudo setenforce 0或sudo systemctl stop apparmor
