最直接线索是error.log中“(13: Permission denied)”，表明系统级权限拒绝；需用sudo tail -n 30 /var/log/nginx/error.log定位失败路径，再以namei -l逐级验证x权限，并用sudo -u nginx模拟访问确认。
看 error.log 里是不是 (13: Permission denied)
这是最直接的线索。Nginx 返回 403 不一定代表配置错，而是系统明确拒绝了文件访问——错误日志会告诉你具体卡在哪一级路径。open() 调用失败并带 (13: Permission denied) 的行，就是排查起点。
执行：
sudo tail -n 30 /var/log/nginx/error.log找类似这行：
open() "/var/www/html/index.html" failed (13: Permission denied)
- 如果没看到
(13: Permission denied)，问题可能出在 index 文件缺失、root 路径拼写错误或 location 匹配逻辑上，不是权限问题 - 如果看到的是
(2: No such file or directory)，说明路径根本不存在或拼错了，别在权限上浪费时间
检查从 / 到目标文件的每一级目录 x 权限
Linux 中，Nginx 用户必须对 整个路径链 每一级目录都有 x（执行）权限，才能进入并遍历下去。缺任意一级 x，哪怕文件本身 644 可读，也会 403。
以 /var/www/html/index.html 为例，需逐级验证：
-
ls -ld /→ 通常没问题（dr-xr-xr-x） -
ls -ld /var→ 必须含x，常见错误是drw-r--r--（无 x） -
ls -ld /var/www→ 同上 -
ls -ld /var/www/html→ 同上 -
ls -l /var/www/html/index.html→ 文件需有r，如-rw-r--r--
快速验证命令：
namei -l /var/www/html/index.html它会把每级权限和属主都列出来，一眼看出哪一级断了。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
确认 nginx worker 进程实际用谁跑，并手动模拟访问
别只信 /etc/nginx/nginx.conf 里的 user 指令。进程实际身份可能被覆盖或未生效。
- 查真实用户：
ps aux | grep "nginx: worker process"看 USER 列（常见值：nginx或www-data） - 查配置是否加载：
grep "^user" /etc/nginx/nginx.conf - 手动测试：
sudo -u nginx cat /var/www/html/index.html—— 如果报Permission denied，说明权限还没调通；成功则说明问题在别处（比如 SELinux）
注意：如果 sudo -u nginx 提示用户不存在，说明你系统用的是 www-data（Ubuntu/Debian），换对应用户名重试。
SELinux 或 AppArmor 是否在背后拦截
尤其在 CentOS/RHEL（默认启用 SELinux）或某些 Ubuntu（启用 AppArmor）上，即使传统权限全对，安全模块仍可拦截 Nginx 访问。
- 查 SELinux 状态：
sestatus→ 若为enforcing，就需怀疑 - 临时放行测试：
sudo setenforce 0，再刷新页面看 403 是否消失 - 若消失，说明是 SELinux 导致。长期方案不是关它，而是打标签：
sudo chcon -R -t httpd_sys_content_t /var/www/html - AppArmor 用户查：
aa-status | grep nginx，日志通常在/var/log/syslog或/var/log/audit/audit.log
这个环节最容易被跳过——因为 ls -l 和 sudo -u nginx cat 全部成功，但网页还是 403，大概率就是它在作祟。
