$bytes_sent 是Nginx发送的总字节数（含状态行、响应头和响应体），$body_bytes_sent 仅统计响应体字节数；监控真实下行流量必须用后者，因其准确反映内容交付成本，避免协议开销干扰。
$bytes_sent 和 $body_bytes_sent 都出现在 Nginx 日志中，但代表完全不同的流量含义。混淆二者会导致监控失真、容量误判甚至告警失效。关键区别在于：前者是“发出去的全部字节”，后者是“真正给客户端的内容体字节”。
一、两个变量的本质差异
$bytes_sent 是 Nginx 发送给客户端的总字节数，包含状态行（如 HTTP/1.1 200 OK）、所有响应头（Content-Type、Server、Set-Cookie 等）以及响应体。它反映的是 TCP 层实际写出的数据量。
$body_bytes_sent 仅统计响应体部分，即 Content-Length 所指的实际内容大小（不含任何头部），也不含分块传输中的 chunk header。它是衡量“用户真正下载了什么”的最准确指标。
举例说明：一个返回 JSON 的接口，响应头共 286 字节，响应体为 1532 字节：
- $bytes_sent = 1818（286 + 1532）
- $body_bytes_sent = 1532
若启用 gzip 压缩，$body_bytes_sent 仍为压缩后响应体长度（Nginx 内部已计算），而 $bytes_sent 还额外包含压缩后的传输开销（如 gzip trailer）。
二、为什么监控真实下行流量必须用 $body_bytes_sent
业务侧关心的是内容交付成本（带宽计费、CDN 流量包消耗、用户下载耗时），这些都只与有效载荷相关。使用 $bytes_sent 会把协议开销、冗余 header、重定向跳转等噪声计入，造成以下问题：
- 同一站点在不同客户端（如移动端 vs PC）因 User-Agent 长度差异，$bytes_sent 波动明显，但 $body_bytes_sent 更稳定
- 开启 HSTS、CSP、Referrer-Policy 等安全头后，$bytes_sent 显著上升，但实际内容未变
- 302 重定向响应体为空，$body_bytes_sent = 0，但 $bytes_sent 可能达数百字节（含 Location 头等）
云厂商计费模型（如 CDN 流量包、对象存储回源带宽）也基本以“响应体内容大小”为依据，而非总传输字节数。
三、如何在日志和监控中正确使用
确保日志格式中显式声明 $body_bytes_sent，并搭配可靠站点标识字段（如 $host）：
log_format main '$host $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';
避免仅依赖 $http_host，建议配合 underscores_in_headers on; 防止自定义 host header 解析异常。
采集后推荐实时聚合路径：
- 轻量级：GoAccess 启用自定义字段解析，按 $host 汇总 $body_bytes_sent，支持终端实时刷新
- 生产级：Nginx VTS 模块 + Telegraf，直接暴露
bytesOut（等价于 $body_bytes_sent 总和），每 5 秒上报 InfluxDB - 平台化：Filebeat 收集日志 → Logstash grok 提取 $host 和 $body_bytes_sent → metrics 插件按分钟聚合 → 输出至 Prometheus 或 ES
可视化时，优先绘制「各 host 每分钟 $body_bytes_sent 总和」趋势图，并叠加 95 分位响应体大小（用于识别大文件上传或异常 dump 接口）。
四、HTTP/2 与 HTTP/3 下的注意事项
$body_bytes_sent 在 HTTP/2 中依然准确，因为它是 Nginx 应用层写入 frame payload 前的最终字节数；但在 HTTP/3（QUIC）下需谨慎——Nginx 当前版本不原生支持 QUIC，若通过 Caddy 或 Envoy 做前端，则需改用其对应指标（如 Caddy 的 http.response.body.bytes）。
此时 $bytes_sent 已失去意义：QUIC 数据报含 UDP 头、QUIC header、加密帧开销，无法与应用层字节一一映射。真实传输监控应转向链路层抓包（如 eBPF）或服务端 QUIC 统计接口。
