缓存节省带宽比例≈80.6%，通过对比$upstream_cache_status为HIT与MISS的$bytes_sent总和计算得出；需记录缓存状态、排除304/HEAD、校正gzip影响，并可用X-Orig-Size交叉验证。
$bytes_sent 是 Nginx 实际发给客户端的总字节数（含响应头和响应体），它真实反映网络链路层消耗的带宽。要评估缓存系统节省了多少流量，关键不是看单个请求，而是对比「缓存命中」与「缓存未命中」两类请求在 $bytes_sent 上的统计差异。
明确缓存命中标识，分离两类流量
必须在日志中记录缓存状态，才能分组对比。推荐使用 Nginx 内置变量 $upstream_cache_status：
- 在 log_format 中加入
$upstream_cache_status字段，例如：log_format cache_flow '$host $remote_addr [$time_local] "$request" $status $bytes_sent $upstream_cache_status'; - 该变量值常见为
HIT、MISS、EXPIRED、BYPASS等；只将HIT视为有效缓存命中（排除 stale 重验证或 proxy_buffering 导致的伪命中） - 确保后端响应中设置了
Cache-Control或Expires，且 Nginx 的proxy_cache_valid配置合理，否则HIT不稳定、不可信
按缓存状态聚合 bytes\_sent，计算节省比例
用日志分析工具（如 awk、Logstash 或 Prometheus + nginxlog-exporter）按 $upstream_cache_status 分组求和 $bytes_sent：
- 假设某小时日志中：HIT 总 $bytes_sent = 2.1 GB，MISS 总 $bytes_sent = 8.7 GB
- 则缓存节省带宽 = MISS 部分本需发送的流量 ≈ 8.7 GB（因为 HIT 请求无需再连后端取数据）
- 节省比例 = 8.7 / (2.1 + 8.7) ≈ 80.6%
- 注意：这个比例是「下行带宽节省率」，不等于后端负载降低率（因部分 MISS 请求可能被 CDN 或本地 proxy_buffer 缓解）
排除干扰项，让评估更贴近真实收益
以下情况会扭曲 $bytes_sent 对缓存收益的反映，需提前过滤或校正：
- gzip 开启时，$bytes_sent 是压缩后体积；而 MISS 请求若后端未压缩、Nginx 压缩后再缓存，则 HIT 的 $bytes_sent 会比原始 MISS 更小——这属于额外收益，应单独标记（如用 $sent_http_content_encoding 区分 gzip/br）
- HEAD 请求或 304 响应的 $bytes_sent 极小（甚至为 0），但它们也属 HIT；建议在聚合时排除 status = 304 或 request_method = HEAD 的记录，专注评估「完整响应体节省」
- 大文件下载（如视频、安装包）若被缓存，单次 $bytes_sent 很高，易拉高整体节省值；可加条件限定
$request_uri ~ \.(js|css|json|html|png|jpg)$，聚焦典型 Web 资源
结合 upstream_response_length 进行交叉验证
仅靠 $bytes_sent 无法知道后端原始响应有多大。若需评估「缓存压缩+传输优化」的综合收益，可引入后端透传的原始体长：
- 后端响应头中添加
X-Orig-Size: 1532（即未压缩、未 gzip 前的 body 大小） - Nginx 日志中用
$sent_http_x_orig_size捕获该值，并与 $bytes_sent 对齐 - 对 HIT 请求：若 $sent_http_x_orig_size = 1532，而 $bytes_sent = 412（gzip 后），说明单次节省 1120 字节；再乘以 HIT 次数，即可估算原始数据节省总量
- 该方式能区分「纯缓存节省」和「压缩增益」，更适合做成本归因分析
