Nginx 默认不解析或透传 HTTP/1.1 chunked 响应的 trailer 字段，$upstreamtrailer* 变量仅在启用 --with-http_upstream_trailer_module、开启 proxy_buffering、后端显式声明并发送 trailer 时才生效，且多数框架默认不支持；推荐改用常规响应头传递校验信息。
Nginx 本身不支持直接通过 $upstream_trailer_* 变量获取后端以分块传输（chunked transfer encoding）方式返回的 trailer 字段，因为标准 HTTP/1.1 协议中 trailer 字段在 chunked 编码末尾发送，而 Nginx 的 upstream 模块（截至 1.25.x）**默认不解析或透传 trailer**，$upstream_trailer_* 变量仅对明确声明的、且被 Nginx 主动接收并缓存的 trailer 头生效——这需要后端主动配合且 Nginx 配置启用特定支持。
trailer 在 HTTP/1.1 中的实际限制
HTTP/1.1 允许在 chunked 响应末尾附加 trailer 字段（如 Trailer: X-Signature, X-Duration），但前提是：
- 响应头中必须显式声明
Trailer: HeaderName； - 后端需严格按 RFC 7230 格式，在最后一个
0\r\n\r\n前发送 trailer 行（例如X-Signature: abc123\r\n）； - Nginx 默认将响应体全部缓冲或流式转发，**不解析 trailer 区域，也不将其提升为可读变量**。
当前 Nginx 版本（≤1.25）对 $upstream_trailer_* 的真实能力
$upstream_trailer_XXX 仅在满足以下全部条件时可用：
- 后端响应头包含
Trailer: XXX； - Nginx 与后端使用 HTTP/1.1 且未启用
proxy_buffering off（缓冲必须开启）； - 后端在响应结束前正确发送了
XXX: value作为 trailer； - Nginx 已编译启用
--with-http_upstream_trailer_module（该模块自 1.19.4 起实验性引入，但默认不启用，且需手动配置激活）。
即使满足上述条件，该功能仍受限于上游响应是否真正携带 trailer —— 多数 Web 框架（如 Express、Flask、Spring Boot）默认不生成 trailer，需显式调用底层 API（如 Node.js 的 res.addTrailers()）才能输出。
实用替代方案（无需依赖 $upstream_trailer_*）
若目标是获取后端计算的校验信息（如签名、哈希、耗时等），更可靠的方式是：
-
改用常规响应头：让后端将验证信息放在
Response Headers（如X-Content-Signature）而非 trailer 中，Nginx 可直接用$upstream_http_x_content_signature获取； -
启用 proxy_buffering + 自定义 trailer 解析（高级）：使用 Lua（OpenResty）或 NJS 拦截响应体末尾，手动扫描
\r\n\r\n(Header:.*)\r\n0\r\n\r\n模式提取 trailer； -
后端改用非 chunked 响应：若响应体大小可控，禁用 chunked（设置
Content-Length），将验证信息统一放在响应头中，规避 trailer 处理问题。
验证是否真的收到 trailer 的方法
可在 Nginx 日志中临时记录原始响应头和响应体末尾：
- 添加日志字段：
log_format debug '$upstream_http_trailer $upstream_http_x_signature';； - 用 tcpdump 或 Wireshark 抓包，确认后端是否真正在 chunked 尾部发送了 trailer 行；
- 用 curl -v 请求后端直连地址，观察是否有
后出现 trailer 行（curl 默认不显示 trailer，需用curl --include并检查响应末尾）。
不复杂但容易忽略：trailer 不是“自动可用”的响应元数据，它需要后端、协议层、代理层三方协同。优先走响应头路线，比强依赖 $upstream_trailer_* 更稳定。
