应将 $gzip_ratio 作为数据源持续观测压缩收益，需显式配置日志格式并启用 gzip，清理脚本须在轮转后统计平均比值并记录趋势，用于识别配置失效或退化。

直接用日志里的 $gzip_ratio 配合定期清理脚本，不是为了“删日志时顺便看一眼”，而是把日志当数据源，持续观测压缩真实收益。关键在两点：日志得记对、分析得跟上清理节奏。

确保 $gzip_ratio 被稳定记录到可分析的日志中

它不会自动出现，必须显式配置：

• 在 http 块里定义带 $gzip_ratio 的日志格式，例如：
  log_format full_gzip '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $gzip_ratio';
• 在 server 或 location 中启用该格式：
  access_log /var/log/nginx/access_full.log full_gzip;
• 确认 gzip 已开启且 gzip_types 覆盖了目标资源（如 application/json、text/css），否则大量请求的 $gzip_ratio 会是 -，无法统计

让日志清理脚本“顺手”产出压缩效果快照

不要等日志攒满再处理。在 logrotate 或自定义清理脚本中，加入压缩前后分析环节：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 在 postrotate 阶段（logrotate）或压缩前（手动脚本），用 awk/grep 快速统计刚轮转出的日志：
  awk '$NF != "-" {sum += $NF; cnt++} END {if(cnt) print "avg_ratio:", sum/cnt, "count:", cnt}' /var/log/nginx/access_full.log.1
• 把结果追加进一个汇总文件，比如 /var/log/nginx/gzip_trend.log，格式如：
  2026-08-19 0.274 12489（日期、平均比值、有效样本数）
• 这样每次清理都留下一笔“压缩健康度”记录，不依赖临时人工抽查

用历史趋势识别压缩配置是否失效或退化

单次 $gzip_ratio = 0.32 意义有限，但连续一周从 0.26 涨到 0.35 就值得查：

• 检查是否新增了未纳入 gzip_types 的响应类型（比如新上线的 application/ld+json）
• 排查 gzip_min_length 是否偏高，导致大量小 JSON（如分页接口返回 800 字节）被跳过压缩
• 对比 CDN 缓存命中率变化——如果 $gzip_ratio 突然升高，但后端实际压缩没变，可能是缓存层返回了未压缩副本

避免把日志压缩和响应压缩混为一谈

清理脚本里用 gzip /var/log/nginx/access.log 是节省磁盘空间，和 Nginx 响应体的 $gzip_ratio 完全无关。后者只反映 HTTP body 经 Gzip 压缩后的体积比，不包含响应头，也不受日志文件是否被 gzip 压缩影响。