Nginx 不支持通过 $connection 追踪长连接复用，因其无此内置变量，且 connection ID 默认不生成、不唯一、不可跨请求追踪；应结合 $connection_requests、时间戳、协议头及 TCP 层工具间接分析。
不能通过 $connection 追踪长连接复用轨迹——因为 Nginx 并没有内置名为 $connection 的日志变量，且连接 ID（connection ID）在标准 access_log 中**默认不生成、不记录、也不具备跨请求唯一性或可追踪性**。
为什么 $connection 不可用、也不适合做长连接追踪
Nginx 官方变量文档中不存在 $connection。你可能混淆了以下概念：
-
真实存在的变量是
$connection的近似误写？——实际有$connection_requests（该连接上已处理的请求数），但它只在连接生命周期内递增，无法标识连接本身，也无法在日志中用于关联不同请求。 - Global Secure Access（Microsoft）中的 connectionId 是其专有代理服务生成的会话级标识，与 Nginx 无关；它基于 FQDN、端口等五元组计算，且仅在其平台日志中有效。
- 长连接（keepalive）本质是 TCP 复用：同一个 TCP 连接可承载多个 HTTP 请求/响应，但 Nginx access_log 默认按「HTTP 事务」（即每个 request）记录，不天然记录底层 TCP 连接的启停、复用次数或生命周期。
真正可行的长连接行为分析方法
若目标是观察客户端是否复用连接、复用频率如何、连接存活时长等，应结合以下指标间接推断：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
-
$connection_requests：在单条日志中记录当前连接已处理的请求数。若连续多条日志中该值递增（如 1→2→3），且$remote_addr、$time_local时间戳接近（秒级差≤1）、$request_time均很短，大概率属同一 keepalive 连接。 -
$msec+$request_time：配合高精度时间戳，识别同一 IP 在极短时间内发起的多个请求，辅助判断复用可能性。 - 启用
log_format包含$server_protocol和$http_connection：检查是否为 HTTP/1.1 且请求头含Connection: keep-alive，确认客户端和服务端协商支持复用。 - 搭配 TCP 层工具验证：用
ss -i或netstat -s | grep -i "segments retransm"观察服务端连接状态和重传，比纯 access_log 更直接反映长连接行为。
如需精准追踪「一次 TCP 连接生命周期」，需额外机制
access_log 本身不是为连接级审计设计的。若业务强依赖此能力，推荐组合方案：
-
启用 Nginx 的
debug日志级别（慎用于生产）：在error_log /path/to/debug.log debug;下，Nginx 会输出连接建立（*xxx connect()）、关闭（*xxx close()）、复用（*xxx http wait request）等事件，含 socket fd 和时间戳，可完整还原连接轨迹。 - 使用 eBPF 工具（如 bpftrace、tcplife）：在内核层捕获 TCP connect/accept/close 事件，直接获取连接五元组、持续时间、传输字节数，完全独立于应用日志。
-
代理层统一注入 request_id + 连接标记：在反向代理（如 Envoy、ALB）中开启连接粒度日志，并将连接哈希（如
sha256($remote_addr:$remote_port:$server_addr:$server_port)）作为自定义字段写入日志，再与$request_id关联分析。
靠修改 log_format 加个“假 connection ID”无法解决本质问题——长连接复用是传输层行为，而 access_log 是应用层事务快照。抓对层次，才能看清轨迹。
