nginx 通过 $gzip_ratio 变量（1−压缩后大小/原始大小）配合日志记录统计静态资源压缩比，需在 location 块中启用 access_log 并记录 $gzip_ratio 与 $body_bytes_sent，再通过日志分析推算原始大小及节省量。
要在 Nginx 中统计静态资源响应的压缩比，核心是利用 $gzip_ratio 变量配合日志记录与后续分析，而不是靠实时接口或监控面板直接输出。它不提供“实时压缩率仪表盘”，但能精准回溯每次压缩的实际效果。
关键前提：只对真正被压缩的响应生效$gzip_ratio 是 Nginx 内置变量，定义为 1 - 压缩后大小 / 原始大小（小数形式），比如 0.68 表示体积减少了 68%。但它仅在满足全部压缩条件时才有数值：
- 请求头含
Accept-Encoding: gzip - 文件 MIME 类型匹配
gzip_types - 原始大小 ≥
gzip_min_length（建议设为1024） -
gzip on已启用，且未被gzip_disable排除
不满足任一条件时，该字段日志中显示为-，不可用于计算。
第一步：在日志格式中显式记录压缩相关字段
必须手动将 $gzip_ratio 和 $body_bytes_sent 加入 log_format，二者缺一不可：
log_format gzip_stat '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$gzip_ratio $request_time "$http_referer" "$http_user_agent"';
access_log /var/log/nginx/static_gzip.log gzip_stat;
注意：
-
$body_bytes_sent是实际发给客户端的字节数（即压缩后大小） -
$gzip_ratio与$body_bytes_sent必须在同一行日志中成对出现，才能反推原始大小
第二步：确保只对静态资源启用该日志
避免动态请求干扰统计，在匹配静态资源的 location 块中单独启用：
location ~* \.(js|css|json|html|xml|txt)$ {
access_log /var/log/nginx/static_gzip.log gzip_stat;
# 其他 gzip 配置（gzip on; gzip_types; 等）
}
第三步：从日志中提取并计算压缩比与节省量
用脚本或命令行聚合典型资源（例如 app.js）的平均压缩效果：
- 找出某文件的平均
$body_bytes_sent和平均$gzip_ratio（过滤掉-行） - 推算原始平均大小：
原始大小 ≈ $body_bytes_sent / (1 - $gzip_ratio) - 单次节省 = 原始大小 −
$body_bytes_sent - 总节省 = 单次节省 × 该路径请求次数
例如：app.js 日志样本中，$body_bytes_sent = 82300，$gzip_ratio = 0.68 →
原始大小 ≈ 82300 / (1 − 0.68) ≈ 257188 字节 → 单次节省约 174888 字节
第四步：验证压缩是否真正在工作
单纯看 $gzip_ratio 数值不够，还需交叉检查：
- 查看响应头是否含
Content-Encoding: gzip（用 curl 或浏览器开发者工具确认） - 检查
gzip_types是否包含对应 MIME 类型（如application/javascript，而非仅text/javascript） - 确认
gzip_min_length不过小（小于 1KB 的文件压缩后可能更大）
不复杂但容易忽略
