nginx无原生“brotli命中率”，实际指brotli是否对可压缩请求成功启用并返回br编码响应；验证需满足三条件：accept-encoding含br、响应头含content-encoding: br、brotli_ratio＞1且content-length显著减小。
Nginx 没有“Brotli 命中率”这个原生指标，它不像缓存那样有 HIT/MISS 状态。所谓“命中率”，实际是指：Brotli 是否对本该压缩的请求，成功执行了压缩并返回了 br 编码响应。因此，测试重点不是统计“命中次数”，而是验证压缩是否按预期触发、生效、且效果合理。
关键判断依据只有三个：
- 客户端请求头带 Accept-Encoding: br（或包含 br）
- 服务端响应头含 Content-Encoding: br
- 响应体实际被压缩（Content-Length 显著变小，且 brotli_ratio > 1）
以下是在生产环境中可直接落地的测试方法：
用日志变量实时观测压缩行为
在http 块中启用带压缩指标的日志格式（需已加载 ngx_brotli 模块）：
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 表示未压缩）。
✅ 示例日志行：192.168.1.50 [30/Sep/2026:17:45:22 +0000] "GET /static/main.js HTTP/1.1" 200 98240 brotli=4.1 orig=402100 sent=98240 → 清晰显示压缩比为 4.1，压缩有效。
快速统计“压缩生效率”（即你想要的“命中率”近似值）
运行以下命令，统计最近 1 万条日志中压缩实际生效的比例：awk '$10 > 1 {hit++} NR
再排查未压缩原因：
<pre class="brush:php;toolbar:false;">awk '$10 == 1 && $4 ~ /\.(js|css|html)$/ {print $4}' /var/log/nginx/brotli.log | sort | uniq -c | sort -nr
常见导致 brotli_ratio == 1 的原因包括：
- 请求头没带 Accept-Encoding: br（如旧版浏览器或爬虫）
- 响应体小于 brotli_min_length（默认仅 20 字节，建议调至 1024）
- MIME 类型不在 brotli_types 列表中（比如漏了 application/javascript）
- 启用了 brotli_static on 但对应 .br 文件不存在，又没 fallback 到动态压缩
线上实时验证单个资源是否走 Brotli
用curl 模拟现代浏览器请求：
curl -sI -H "Accept-Encoding: br" https://yoursite.com/app.css | grep "Content-Encoding"若返回
Content-Encoding: br，说明链路通畅。
再对比不带 br 的请求：
curl -sI -H "Accept-Encoding: gzip" https://yoursite.com/app.css | grep "Content-Encoding"可验证协商逻辑是否正常（例如是否因配置冲突导致回了 gzip 而非 br）。
浏览器 DevTools 辅助交叉验证
打开 Chrome 或 Firefox 的 Network 面板，刷新页面，筛选 JS/CSS/HTML 类资源，检查： - Headers → Response Headers 中是否有Content-Encoding: br
- Size 列显示 “transferred” 明显小于 “resource”（例如 transferred 124 KB，resource 480 KB）
- 若看到 content-encoding: identity 或为空，则未压缩
不复杂但容易忽略
