最直接有效的方式是在 location 块中显式配置 access_log off;，针对高频静态资源（如 .js、.css、/favicon.ico、/static/ 等）关闭日志，避免系统调用与 I/O 开销，需置于具体 location 内且位置靠前，禁用 log_if 或 /dev/null 等无效写法。
最直接有效的方式，是在 location 块中显式配置 access_log off;，从源头跳过日志格式化与写入流程，而不是事后过滤或重定向到空设备。这能显著减少 write 系统调用、磁盘 I/O 和 worker 进程 CPU 开销，尤其在高并发静态请求场景下效果明显。
哪些路径该关日志
重点关闭高频、低业务价值、强缓存的请求：
- 常见静态资源后缀：.js、.css、.png、.jpg、.gif、.ico、.woff2、.ttf、.eot、.svg、.webp
- 固定系统路径：/favicon.ico、/robots.txt、/healthz、/metrics
- 统一前缀路径：/static/、/assets/、/dist/（若这些路径全部托管静态内容）
- 已由 CDN 或浏览器强制缓存的资源（如 Cache-Control: public, immutable）
正确写法：location + access_log off
必须在具体 location 块内配置，且位置要靠前，避免被更宽泛的规则覆盖：
- 使用大小写不敏感正则：
location ~* \.(js|css|png|jpg|gif|ico|woff2?|ttf|eot|svg|webp)$ - 该块需放在
location /或proxy_pass规则之前 - 同一块中写
access_log off;，可同步加缓存头提升性能
示例：
location ~* \.(js|css|png|jpg|gif|ico|woff2?|ttf|eot|svg|webp)$ {access_log off;
expires 1y;
add_header Cache-Control "public, immutable";
}
容易失效的错误写法
看似简单，但几个细节常导致配置无效：
- 只在
server块写access_log off;—— 子 location 会继承默认日志配置，除非显式关闭 - 用
log_if $uri ~* \.js$—— 日志格式化仍执行，不省 CPU，仅跳过写入 - 写
access_log /dev/null;—— 仍打开文件句柄并尝试写入，不如off彻底 - 忽略
log_not_found off;—— 静态资源 404（如前端路由缺失）会持续刷日志
验证是否真正生效
reload 后需确认日志写入确实停止：
- 发起测试请求：
curl -I https://yoursite.com/app.js - 观察
tail -f /var/log/nginx/access.log是否无新增行 - 检查 worker 进程是否还持有日志句柄：
lsof -p $(pidof nginx) | grep access，应无输出 - 压测时对比磁盘 %util 和 await 指标是否下降
