真正起作用的是错误日志（error.log），需用sudo tail -f /var/log/nginx/error.log实时监控，重点抓(13: permission denied)报错、client/server标识及request上下文，并用namei -l检查路径各级x权限。
查访问日志本身不能直接定位 403 权限拒绝的根本原因，真正起作用的是 错误日志（error.log）。访问日志（access.log）只记录“谁、什么时候、访问了什么、返回了什么状态码”，它告诉你“发生了 403”，但不解释“为什么”。而 error.log 才是 Nginx 写下失败细节的地方——尤其是带 (13: Permission denied) 的那行，就是权限问题的铁证。
先盯住 error.log，别被 access.log 带偏
运行以下命令实时观察错误日志变化：
-
sudo tail -f /var/log/nginx/error.log（全局日志） - 或查看你站点配置中指定的
error_log路径，例如：error_log /var/log/nginx/myapp_error.log warn;
刷新页面触发 403 后，立刻能看到新增日志行。重点抓三类信息：
-
错误描述原文：如
open() "/var/www/html/index.html" failed (13: Permission denied)—— 这说明系统层面拒绝读取该文件；又如directory index of "/var/www/app/" is forbidden—— 这说明目录存在但没索引文件且未启用浏览。 -
client 和 server 字段：确认是全站报错，还是仅某个域名（
server: example.com）或某 IP（client: 192.168.1.105）异常，排除 IP 限制或虚拟主机配置错位。 -
request 上下文：如
request: "GET /api/data HTTP/1.1"，若路径含/api/，大概率不是静态文件权限问题，而是 location 规则 deny 或后端返回的 403。
用 namei 检查路径权限断点
当 error.log 提示 Permission denied，别只看目标文件权限。Linux 要求从根目录开始，每一级父目录都必须有 x（执行）权限，Nginx 才能“进入”路径。用 namei 一次性看清整条路径的权限链：
namei -l /var/www/html/index.html
输出中若某一级（比如 /var/www）显示权限为 drwxr-x---（即 others 无 x），而 Nginx 进程用户不属于该目录属组，就卡在这里——哪怕 index.html 本身权限完全正确。
对比 access.log 验证请求是否真进了 Nginx
如果 error.log 完全没新增记录，但 access.log 里却有对应 403 行，说明请求确实到达了 Nginx 并被它主动拒绝（比如因 location 中写了 deny all）。反之，如果 access.log 也无记录，那问题不在 Nginx 层：可能是防火墙拦截、CDN 返回缓存 403、或 DNS/端口监听配置错误。
区分是 Nginx 拒绝还是后端服务拒绝
如果你用 Nginx 做反向代理（比如 proxy_pass 到 Node.js 或 PHP-FPM），access.log 和 error.log 都出现 403，需进一步验证：
- 绕过 Nginx 直连后端：
curl http://127.0.0.1:3000/api/test，看是否同样返回 403； - 检查 Nginx error.log 中是否有
upstream sent no valid HTTP/1.0 header或connection refused等提示，这指向后端未响应，而非权限问题。
