Nginx error_log 默认不记录404（文件不存在），仅记录系统级错误如(13: Permission denied)、磁盘满、inode耗尽等；需设log_not_found off或启用debug日志（编译含--with-debug，配置error_log debug）才能捕获路径查找细节。
Nginx 的 error_log 默认不会记录静态资源读取失败（比如文件不存在、权限不足）的详细信息，这类问题通常只在 access_log 中体现为 404 或 403 状态码，而 error_log 往往保持沉默——除非配置得当或触发了真正意义上的错误事件。
哪些静态资源失败会写入 error_log
并非所有静态请求失败都会进 error_log。只有当 Nginx 在尝试读取文件时遇到系统级错误（而非 HTTP 语义错误），才会记录：
- 文件存在但 Nginx 进程无读取权限（
Permission denied） - 目录不可执行（无法进入路径，
Permission denied） - 磁盘满、inode 耗尽等导致 open() 失败
- 符号链接循环、路径过长等系统调用失败
-
注意：单纯的
ENOENT（文件不存在）默认不记入error_log，这是设计使然——404 是预期行为，不是错误
如何让 404 也出现在 error_log 中
如果确实需要将“文件不存在”这类情况记入 error_log（例如用于调试或监控缺失资源），可通过 log_not_found off 关闭默认抑制行为，并配合 try_files 或自定义 location 触发日志：
- 在相关
location块中添加：log_not_found off; - 搭配
try_files $uri =404;，当$uri未命中时，Nginx 会主动抛出 404 并可能触发更明确的日志路径 - 更可靠的做法是用
if (!-f $request_filename) { return 404; }，此时缺失判断由 if 指令触发，部分版本会在 error_log 中留下 trace 级别记录（需开启 debug 日志）
启用 debug 日志定位真实原因
当静态资源行为异常（如该返回 404 却返回空白、或偶发 500），标准 error_log 级别（warn/error）信息不足，可临时启用 debug 日志：
- 编译时需含
--with-debug；运行时在error_log指令中指定debug级别：error_log /var/log/nginx/error.log debug; - debug 日志会详细打印文件查找过程，例如：
open() "/usr/share/nginx/html/missing.js" failed (2: No such file or directory) - 注意：debug 日志量极大，仅用于临时排查，切勿长期开启
检查权限与路径的真实瓶颈
很多“读取失败”表面是 404，实则是权限或路径配置问题。排查时应聚焦：
- 确认 Nginx worker 进程用户（如
www-data）对整个路径（目录 + 文件）有x（执行/进入）和r（读取）权限 - 检查 SELinux 或 AppArmor 是否拦截（常见于 CentOS/RHEL 或 Ubuntu）：
ausearch -m avc -ts recent | grep nginx - 用
strace -p $(pgrep nginx) -e trace=openat,stat实时观察 Nginx 实际尝试访问的路径和返回码
