error_log 是定位 Nginx 403 Forbidden 问题最直接、最可靠的依据，尤其含 (13: Permission denied) 时直指权限故障，并精准记录被拒路径、客户端 IP、请求方法等；它可区分权限拒绝、索引缺失或配置拦截，且是验证修复效果及避免盲目操作的关键依据。
error_log 是定位 Nginx 403 Forbidden 问题最直接、最可靠的依据，尤其当错误明确带 (13: Permission denied) 时，它直接指向权限类故障，而非配置或网络问题。
能精准锁定出错路径和触发条件
日志中会完整记录被拒绝访问的绝对路径、客户端 IP、请求方法、server_name 和时间戳。例如：
2026/07/08 04:32:15 [error] 1234#0: *7 open() "/var/www/myapp/index.html" failed (13: Permission denied), client: 192.168.1.100, server: example.com, request: "GET / HTTP/1.1"
这说明 Nginx 尝试打开 /var/www/myapp/index.html 失败，而不是泛泛地“无法访问网站”。你无需猜测 root 是否写错，直接验证该路径即可。
区分真实权限拒绝与配置拦截
403 可能来自权限不足，也可能来自显式 deny 规则或缺少 index 文件。error_log 会给出不同线索：
- 含 (13: Permission denied) → 文件系统权限或 SELinux 限制
- 含 directory index of "/path/" is forbidden → 目录无索引文件且未启用 autoindex
- 含 access forbidden by rule → location 或 server 块中存在 deny / allow 控制
验证修复是否生效的客观标准
每次调整（改权限、换 user、关 SELinux）后，重启 Nginx 并刷新页面，再看 error_log 是否还有新报错。没有新增的 403 相关记录，基本说明问题已解；若仍有相同错误，说明改动未覆盖根本原因。
避免盲目操作的关键依据
很多用户一见 403 就 chmod 777 或直接改 user 为 root，既不安全也未必有效。error_log 能告诉你：是父目录缺 x 权限？是文件属主不是 nginx？还是 SELinux 的 context 不对？——每一条日志都对应一个可验证的具体动作，而不是靠猜。
