如何通过分析 access_log 中的连接 ID ($connection) 追踪长连接复用轨迹-Nginx-PHP中文网

Nginx 不支持通过 $connection 追踪长连接复用，因其无此内置变量，且 connection ID 默认不生成、不唯一、不可跨请求追踪；应结合 $connection_requests、时间戳、协议头及 TCP 层工具间接分析。

如何通过分析 access_log 中的连接 id ($connection) 追踪长连接复用轨迹

不能通过 $connection 追踪长连接复用轨迹——因为 Nginx 并没有内置名为 $connection 的日志变量，且连接 ID（connection ID）在标准 access_log 中**默认不生成、不记录、也不具备跨请求唯一性或可追踪性**。

Nginx 官方变量文档中不存在 $connection。你可能混淆了以下概念：

真实存在的变量是 $connection 的近似误写？——实际有 $connection_requests（该连接上已处理的请求数），但它只在连接生命周期内递增，无法标识连接本身，也无法在日志中用于关联不同请求。
Global Secure Access（Microsoft）中的 connectionId 是其专有代理服务生成的会话级标识，与 Nginx 无关；它基于 FQDN、端口等五元组计算，且仅在其平台日志中有效。
长连接（keepalive）本质是 TCP 复用：同一个 TCP 连接可承载多个 HTTP 请求/响应，但 Nginx access_log 默认按「HTTP 事务」（即每个 request）记录，不天然记录底层 TCP 连接的启停、复用次数或生命周期。

若目标是观察客户端是否复用连接、复用频率如何、连接存活时长等，应结合以下指标间接推断：

将 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 更直接反映长连接行为。

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 是应用层事务快照。抓对层次，才能看清轨迹。