403错误需按错误日志→请求类型→用户权限→配置陷阱四步排查：先查error.log中“directory index forbidden”“Permission denied”等报错类型；再区分静态资源或proxy_pass引发；接着用sudo -u nginx模拟访问验证权限链；最后检查index缺失、root路径斜杠、autoindex作用域等常见配置问题。
看到访问日志里大量 403，别急着改配置，先看错误日志——它才是真正的“故障说明书”。403 不是服务挂了，而是 Nginx 明确拒绝了请求，背后一定有具体原因。排查要聚焦在“谁在拒访”和“为什么拒访”上，按线索深挖比盲目重启更高效。
第一步：盯紧 error.log 里的具体报错类型
访问日志（access.log）只告诉你“返回了 403”，真正原因全在错误日志（error.log）里。运行：
sudo tail -n 100 /var/log/nginx/error.log
重点识别三类典型报错：
- "directory index of /xxx/ is forbidden" → 表示目录存在，但没找到 index 文件，且未启用 autoindex。问题出在配置逻辑或文件缺失，不是权限问题。
- "open() "/path/to/file" failed (13: Permission denied)" → 系统级权限拦截，Nginx 工作用户无法读取文件或进入某一级父目录，需查属主、权限、SELinux。
- "no resolver defined to resolve ..." 或代理相关拒绝 → 多见于反向代理场景，可能是后端校验 Host、Referer、Token 或 IP 白名单导致的 403，非静态资源问题。
第二步：区分是静态资源还是代理转发引发的 403
根据请求路径判断流量走向：
- 如果 403 集中在 /、/css/、/images/ 这类路径 → 属于静态文件服务问题，按“根目录权限 + index 配置 + SELinux”主线排查。
- 如果 403 集中在 /api/、/v1/、/proxy/ 这类路径 → 很可能走的是 proxy_pass，问题在后端服务侧：检查后端是否校验 Host 头、是否要求认证头（Authorization/Cookie）、是否做了 Referer 或来源 IP 限制。
快速验证：用 curl 直连后端地址（绕过 Nginx），看是否同样返回 403。如果是，问题不在 Nginx 配置，而在后端策略。
第三步：验证 Nginx 用户对路径的实际访问能力
别猜，直接模拟。先确认 worker 进程用户：
ps aux | grep "nginx: worker" | head -1 | awk '{print $1}'
假设输出是 nginx，那就用这个用户身份测试关键路径：
sudo -u nginx ls -l /your/configured/root/
sudo -u nginx cat /your/configured/root/index.html
任何一步报 “Permission denied”，就说明权限链断在某处。这时用 namei -l /your/configured/root/index.html 查每级目录的属主和权限，特别注意中间某层（比如 /root 或 /home/deploy）是否缺少 x 权限——这是最常被忽略的环节。
第四步：批量排查常见配置陷阱
大量 403 往往不是单点故障，而是配置模式性失误：
- location 块里漏写 index 指令：比如 root 设在 /data/app，但 location /admin/ { } 里没配 index，Nginx 就不会去找 /data/app/admin/index.html。
- root 路径末尾多斜杠或少斜杠：root /var/www/ 和 root /var/www 在某些 location 匹配下会导致实际拼接路径偏差。
- autoindex on; 写在错误作用域：比如写在 server 块却期望对某个子目录生效，而该子目录 location 里没继承也没重写，就会失效。
- 使用了 satisfy any 但未配 auth_basic 或 allow/deny：这类混合鉴权配置一旦逻辑写错，容易整块返回 403。
建议用 nginx -t 检查语法后，再用 nginx -T 输出全部生效配置，人工核对关键 location 的指令是否如你所想。
