不推荐在http块中设log_not_found off，因其会全局屏蔽所有location的“文件未找到”warn日志，掩盖真实路径错误；应按需在具体location中关闭，如favicon、SPA路由、静态资源等，并配合map过滤access_log中的无关404。
直接在 http 块中设 log_not_found off 并不推荐——它会全局抑制所有 location 下的“文件未找到”日志，容易掩盖真实路径错误或配置疏漏，失去关键排查线索。
为什么 http 块级关闭风险高
该指令在 http 块中生效后，所有 server 和 location（除非显式覆盖）都将不再记录任何 open() "/xxx" failed (2: No such file or directory) 类型 warn 日志。这意味着：
- 前端引用了已删除的 JS 文件，error_log 不再提示，问题难定位
- CDN 回源请求了带错误哈希的 CSS 路径，运维无法从 error_log 快速发现版本不一致
- alias 配置路径写错、root 目录权限异常等本该告警的情况，也会被一并静默
更安全的替代方案：按需精准关闭
真正要解决的是“高频、可预期、无业务价值”的 404 日志刷屏，比如 favicon.ico、SPA 路由回退、爬虫乱扫。应把 log_not_found off 放在具体匹配块中：
-
处理 favicon.ico：
location = /favicon.ico {<br> log_not_found off;<br> return 204;<br>} -
保护 SPA 主入口（如 Vue/React history 模式）：
location / {<br> log_not_found off;<br> try_files $uri $uri/ /index.html;<br>} -
屏蔽静态资源缺失日志：
location ~* \.(js|css|png|jpg|gif|svg|woff2?)$ {<br> log_not_found off;<br>}
配合 access_log 实现分层监控
log_not_found off 只影响 error_log，不影响 access_log 中的 404 记录。你可以保留 access_log，再用 map 过滤无关路径：
- 定义过滤变量：
map $request_uri $log_404 {<br> ~^/(favicon\.ico|robots\.txt|healthz) 0;<br> default 1;<br>} - 条件写入访问日志：
access_log /var/log/nginx/404.log main if=$log_404;
这样既避免 error_log 被刷屏，又能集中分析真正需要修复的 404 请求来源。
验证是否生效的关键动作
重载配置后执行三步检查：
- 手动请求
curl -I http://your-site/favicon.ico，确认返回状态码（如 204）且无重定向 - 查看
error.log是否不再新增对应路径的No such file行 - 观察日志文件体积增长趋势，尤其对比高峰时段前后变化
