Nginx无“压缩命中率”指标，实际监控重点是压缩是否按预期触发与生效：通过日志变量（如$brotli_ratio）、统计压缩生效率、结合响应头（Content-Encoding: br）实时验证三步落地。
Nginx 本身不提供“压缩命中率”这一指标——它不像缓存那样有 HIT/MISS 状态。所谓“压缩命中率”，实际是指 Brotli 或 gzip 是否对请求成功执行了压缩，核心是看：
✅ 该请求是否满足压缩条件（如 MIME 类型、大小、客户端支持）
✅ 压缩模块是否生效并输出了更小的响应体
因此，监控重点不是“命中”，而是 验证压缩是否按预期触发、生效、且效果达标。以下是可落地的三步法：
用日志变量直接记录压缩行为
在 http 块中定义带压缩指标的日志格式（以 ngx_brotli 为例，gzip 同理）：
log_format brotli '$remote_addr [$time_local] "$request" '
'$status $body_bytes_sent '
'brotli=$brotli_ratio '
'orig=$request_length '
'sent=$bytes_sent '
'ua="$http_user_agent"';
access_log /var/log/nginx/brotli.log brotli;-
$brotli_ratio：原始响应大小 ÷ 压缩后大小（>1 表示压缩生效；=1 表示未压缩） -
$request_length：请求头+体总长（辅助判断是否为小资源被跳过） -
$bytes_sent：实际发送字节数（含响应头，但主体压缩效果清晰可见）
✅ 示例日志行：
192.168.1.100 [12/Jun/2026:07:20:33 +0000] "GET /static/app.js HTTP/1.1" 200 124560 brotli=3.2 orig=398200 sent=124560
→ 明确显示压缩比 3.2，压缩有效。
区分压缩生效与未生效的请求
通过日志快速统计压缩覆盖率：
# 统计最近1万行中压缩生效（ratio > 1）的比例
awk '$10 > 1 {hit++} NR<=10000 {total++} END {printf "压缩生效率: %.1f%%\n", hit/total*100}' /var/log/nginx/brotli.log
# 查看哪些文件类型没被压缩（ratio == 1 且是 js/css 等应压缩类型）
awk '$10 == 1 && $4 ~ /\.(js|css|svg)$/ {print $4}' /var/log/nginx/brotli.log | sort | uniq -c | sort -nr常见未压缩原因包括：
- 客户端不支持
br或gzip（检查Accept-Encoding请求头） - 响应体小于
gzip_min_length（默认 20 字节，太小不压） - MIME 类型未列入
gzip_types或brotli_types - 启用了
gzip_disable且匹配了 UA（如旧版 IE）
结合响应头做实时验证
在静态资源 location 中添加明确标识：
location ~* \.(js|css|svg|json)$ {
brotli on;
brotli_types application/javascript text/css image/svg+xml application/json;
# 强制暴露压缩状态
add_header X-Content-Compressed "brotli" always;
add_header X-Content-Length-Orig "$content_length" always;
}然后用 curl 快速验证：
curl -H "Accept-Encoding: br" -I https://yoursite.com/static/app.js # 查看返回头是否含 X-Content-Compressed: brotli 且 Content-Encoding: br
不复杂但容易忽略
