最直接线索是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--

快速验证命令：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

namei -l /var/www/html/index.html

它会把每级权限和属主都列出来，一眼看出哪一级断了。

确认 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，大概率就是它在作祟。