最直接有效的方式是在 Nginx 的 location 块中配置 access_log off;，针对 .js、.css、.png 等静态资源及 /favicon.ico、/robots.txt、/static/ 等路径，配合 expires 和 Cache-Control 提升性能，避免 log_if 或 /dev/null 等错误写法，并通过日志观察与 lsof 验证生效。
最直接有效的方式，是在 Nginx 配置中对静态资源路径明确设置 access_log off;，从源头阻止日志写入，而不是等日志生成后再过滤或清理。这能显著减少 write 系统调用、磁盘 I/O 和 worker 进程 CPU 开销，尤其在高并发静态请求场景下效果明显。
哪些静态资源该关日志
重点关闭高频、低业务价值、强缓存的资源访问记录：
- .js、.css、.png、.jpg、.gif、.ico、.woff2、.ttf、.eot、.svg、.webp 等常见前端静态后缀
- /favicon.ico 和 /robots.txt —— 几乎每次页面访问都触发，但无分析价值
- /static/、/assets/、/dist/ 等前缀路径下的全部内容（若统一托管）
- 已由 CDN 或浏览器强制缓存（Cache-Control: public, immutable）的资源
正确配置 location + access_log off
必须在 location 块内配置，且确保它不被更宽泛的规则覆盖：
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 使用
location ~* \.(js|css|png|jpg|gif|ico|woff2?|ttf|eot|svg|webp)$进行大小写不敏感正则匹配 - 把该
location块放在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方式（如log_if $uri ~* \.js$），它仍执行日志格式化，不省 CPU - 不用
access_log /dev/null;替代access_log off;—— 前者仍打开文件句柄并尝试写入，后者彻底跳过日志流程 - 若同时有
error_log写入（比如 404），可加log_not_found off;进一步减少干扰
验证是否真正生效
改完配置 reload 后，需确认日志写入确实停止：
- 发起几次静态资源请求：
curl -I https://yoursite.com/app.js - 观察
tail -f /var/log/nginx/access.log是否无新增行 - 检查 worker 进程是否还持有日志句柄：
lsof -p $(pidof nginx) | grep access，应无输出 - 压测时对比
iostat -x 1中磁盘 %util 和 await 指标是否下降
