如何利用 $sent_http_content_length 变量识别并排查响应内容截断的难点-Nginx-PHP中文网

$sent_http_content_length不可靠——它仅表示nginx实际发送的字节数，需结合$upstream_response_length等变量交叉验证截断；推荐后端注入x-orig-length头并比对。

如何利用 $sent_http_content_length 变量识别并排查响应内容截断的难点

直接用 $sent_http_content_length 判断响应是否被截断，不可靠——它只反映 Nginx 实际发送的字节数，而非后端本应返回的完整长度。真正有效的排查，要结合该变量与其他信号交叉验证。

理解 $sent_http_content_length 的真实含义

这个变量是 Nginx 在响应发送完毕后才填充的，值等于它真正写入下游（如客户端或上游代理）的响应体字节数。它不等于后端应用设置的 Content-Length 头，也不代表后端生成的内容长度。如果响应被 Nginx 自身截断（如超时、缓冲区满、proxy_buffering 关闭时流式响应异常中断），$sent_http_content_length 就会小于预期。

若后端返回 1024 字节并正确关闭连接，Nginx 通常填入 1024
若 Nginx 在发送中途因 proxy_read_timeout 断开与后端连接，该值可能只有 300
若启用 chunked 编码且后端未完整发送所有 chunk，Nginx 可能提前终止并记录偏小的值

配合 access_log 定制字段定位截断行为

在 log_format 中加入 $sent_http_content_length 和关键状态变量，形成可分析的行为快照：

log_format debug_truncate
  '$time_iso8601 | $status | $bytes_sent | $sent_http_content_length |
   $upstream_response_length | $request_time | $upstream_connect_time';

重点关注三组差值：

$sent_http_content_length 明显小于 $upstream_response_length → 截断发生在 Nginx 与后端之间（如 proxy buffer 不足、超时）
$sent_http_content_length 接近 $bytes_sent 但远小于业务预期 → 响应体本身被裁剪，非传输问题
$sent_http_content_length 为 0 但 $status 是 200 → 后端可能未输出任何 body（如 FastCGI 脚本 exit 前未 flush）

区分真实截断与协议/编码干扰

某些场景下 $sent_http_content_length 偏小不是故障，而是协议特性：

后端返回 Transfer-Encoding: chunked 时，Nginx 默认不计算总长，$sent_http_content_length 可能为 0 或不准确
启用 gzip on 且后端未设 Vary: Accept-Encoding，Nginx 可能因缓存复用导致长度错配
使用 sub_filter 修改响应体时，Nginx 重写后重新计算长度，$sent_http_content_length 反映修改后大小

此时需关掉 gzip/sub_filter 临时验证，或改用 $body_bytes_sent（不含响应头）作辅助比对。

主动注入响应长度用于端到端校验

最可靠的方式，是在后端响应中嵌入真实内容长度（如自定义 header X-Orig-Length: 12345），再在 Nginx 中用 map 或 log_format 提取比对：

map $sent_http_x_orig_length $length_mismatch {
  default "";
  "~^(?<orig>\d+)$" "${orig} ${sent_http_content_length}";
}</orig>

在日志中输出 $length_mismatch，格式如 "12345 9876"，一眼识别差值。这种方式绕过了协议不确定性，把判断权交还给业务层。