关闭 log_not_found 可有效抑制 Nginx 对 404 静态资源请求的 error log 记录，避免日志刷屏；该指令默认 on，可在 location 或 server 块中设为 off，推荐精准配置于静态资源匹配块，并配合 access_log 分离记录与监控。
关闭 log_not_found 可以有效抑制 Nginx 对 404 静态资源请求的日志记录，避免日志被大量无效请求刷屏，同时不影响真实错误的排查。
log_not_found 是什么？
这是 Nginx 的一个指令，默认值为 on。当客户端请求一个不存在的文件（如图片、CSS、JS 路径错误或爬虫乱扫）时，Nginx 会返回 404 并在 error log 中记一条 open() "/path/to/file" failed (2: No such file or directory) 类型的警告。这类日志对调试意义有限，却极易撑爆日志文件。
如何关闭它？
在对应 server 或 location 块中添加：
log_not_found off;
常见推荐位置：
- 放在
location ~* \.(js|css|png|jpg|gif|ico|svg|woff2?)$这类静态资源匹配块内 —— 最精准，只屏蔽静态 404 - 放在根
server块中 —— 全局生效，但需注意：若后端应用依赖 404 日志定位缺失资源，可能影响问题回溯
关闭后还怎么查真实问题？
不记录 ≠ 不发生。关键是要区分“可预期的 404”和“需修复的 404”：
- 前端构建后引用了已删除的旧资源？—— 检查构建产物目录与 HTML 中的路径一致性
- CDN 缓存了过期 HTML，指向不存在的版本化文件？—— 清缓存 + 检查版本哈希是否同步
- 爬虫或扫描器高频请求随机路径？—— 结合 access log 的
status=404字段做统计（例如用 awk + sort），而非依赖 error log
真正需要关注的，是那些在 access log 中集中出现、有业务来源（如某页面跳转、某接口触发）的 404，而不是 error log 里零散重复的“找不到 favicon.ico”。
补充建议：配合其他策略更稳妥
单靠 log_not_found off 不够全面，建议组合使用：
- 对 favicon.ico、robots.txt 等通用路径单独配置
location = /favicon.ico { log_not_found off; return 204; }，直接响应空内容，省去磁盘查找开销 - 用
access_log /path/access.log main if=$log_404;实现 404 请求的独立记录（需提前定义 map 变量），兼顾监控与降噪 - 定期用脚本分析 access log 中高频 404 路径，自动推送告警或生成修复清单
