不能用 $sent_http_connection 监控 Nginx 主动下发的连接管理策略，因其仅表示响应头中 Connection 字段的一次性输出值（如 keep-alive 或 close），不反映策略配置、生效状态或执行效果；真正控制连接行为的是 keepalive_timeout、keepalive_requests 等配置指令，应通过 stub_status、$connection_requests、tcpdump 等方式监控实际连接行为。
不能用 $sent_http_connection 监控 Nginx 主动下发的连接管理策略。
这个变量本身不反映连接策略
$sent_http_connection 是 Nginx 内置变量，表示响应头中实际发送给客户端的 Connection 字段值（如 keep-alive 或 close），它只是对当前响应的一次性输出，由 Nginx 根据请求处理过程（比如是否启用 keepalive、协议版本、客户端请求头等）自动决定，并非配置项或策略开关。它不体现“主动下发策略”的行为，也不记录策略生效次数、触发条件或全局配置状态。
真正控制连接行为的是配置指令
连接管理策略由以下配置直接决定，监控应围绕它们展开：
- keepalive_timeout：设置 keep-alive 连接保持时间，超时后服务端主动关闭连接
- keepalive_requests：单个连接允许的最大请求数，达到后强制断开
- send_timeout：两次写操作之间的超时，影响长连接稳定性
- client_header_timeout / client_body_timeout：控制请求建立阶段的等待容忍度
推荐的监控方式
要真实掌握连接策略执行效果，建议结合以下手段：
- 通过 stub_status 页面观察
Active connections、Reading/Writing/Waiting实时分布，判断 keep-alive 是否有效驻留 - 在 access_log 中使用
$connection_requests变量，统计每个 TCP 连接承载的请求数，验证keepalive_requests是否按预期截断连接 - 用 tcpdump 或 ss -ti 抓包分析 FIN/RST 出现时机，确认服务端是否在
keepalive_timeout后主动发 FIN - 配合日志中的
$request_time和$upstream_connect_time，识别因连接复用失败导致的重复建连开销
为什么不要依赖 $sent_http_connection
该变量值通常固定为 keep-alive（HTTP/1.1 默认）或 close（出错、HTTP/1.0、显式禁用时），无法区分是策略生效、客户端不支持，还是中间设备干扰。同一配置下，它可能在 99% 的响应里都是 keep-alive，但你仍可能面临大量短连接——这说明问题不在响应头，而在客户端行为或上游网络。把它当监控指标容易误判。
