$body_bytes_sent是nginx实际发送给客户端的响应体字节数（不含响应头），反映真实下行流量；$content_length是客户端请求头中声明的请求体长度，仅用于上传大小初筛，二者分属响应与请求阶段，不可混用。
$body_bytes_sent 和 $content_length 看起来都跟“字节数”有关，但它们代表完全不同的阶段、来源和用途。监控时若混淆二者，容易误判流量、掩盖真实问题，甚至干扰限流或日志分析逻辑。
body_bytes_sent 是 Nginx 实际发出去的响应体字节数
这个变量由 Nginx 在响应真正写入 TCP 连接后才统计完成，只包含响应正文（body）部分，不包括响应头。它反映的是客户端最终收到的有效内容大小。
- 适用于监控真实下行带宽、用户实际接收量、CDN 回源流量估算
- 对 chunked 编码响应也准确 —— Nginx 会在所有分块发送完毕后累加得出最终值
- 若连接中断（如用户关闭页面、超时断连），该值可能小于完整响应体大小，Nginx 不会补全
- 注意：该计数按连接重置，不是全局累计；复用 TCP 连接时，每个请求独立计数
content_length 是请求头里声明的请求体长度
$content_length 是从客户端请求的 Content-Length 请求头中直接提取的数值，仅存在于非 chunked 的 POST/PUT 请求中。它代表客户端声称要上传的数据大小，Nginx 并不校验其真实性。
- 用于前置判断是否触发
client_max_body_size限制（比如上传超限返回 413） - 对无
Content-Length的请求（如 chunked 编码或 GET 请求），该变量为空或 0 - 如果客户端伪造或填错该值（比如填 1000 但实际只发了 200 字节），Nginx 仍以它为依据做初步检查，可能导致异常或丢包
- 它与响应无关，不能用来衡量服务端输出了多少数据
典型监控误用场景与建议
把 $body_bytes_sent 当作请求大小来限流，或拿 $content_length 去算响应带宽，都是常见错误。
- 想限制上传文件大小？依赖
client_max_body_size+$content_length初筛，再配合后端校验 - 想统计 API 平均响应体积？用
$body_bytes_sent记录 access_log，聚合分析更可靠 - 发现日志中大量
$content_length为 0 或空？说明大量请求是 GET、HEAD 或用了 chunked 编码，需确认是否符合业务预期 - 对比监控图表中
$body_bytes_sent总和远小于入口流量？可能是代理层提前截断、gzip 开启导致压缩后体积变小，或存在大量 304/204 等无 body 响应
在日志和 Prometheus 中怎么用
在 log_format 中可直接引用：
这样就能在同一行里比对请求声明大小与响应实际发出大小。接入 Prometheus 时，建议将 $body_bytes_sent 作为直方图指标（如 nginx_response_body_bytes），而 $content_length 更适合做标签维度（如 request_content_length_bucket）辅助分析上传行为分布。
