如何利用日志中的 $connection?requests 变量审计单个长连接链路上不同路径请求的连续切换状态

$connection_requests 不适用，因其仅为自连接建立以来的累计请求数整型计数器，不记录路径、时间戳、upstream等上下文；需结合$request_uri、$upstream_addr、$time_iso8601等变量构建可审计的路径切换标记。

直接使用 $connection_requests 无法审计长连接链路上的路径切换状态，因为它仅记录当前连接生命周期内已处理的请求数量（整型计数器），不携带路径、时间戳、路由标识等上下文信息。

为什么 $connection_requests 本身不适用

$connection_requests 是 Nginx 内置变量，含义是“该 TCP 连接自建立以来成功完成的 HTTP 请求总数”。它随每次请求结束递增，但：

• 不记录每个请求的 location、upstream 名称或实际转发路径
• 不保存请求到达/响应返回的时间点，无法判断两次请求是否“连续”或是否存在间隔
• 在 keepalive 复用场景下，多个不同路径的请求可能共享同一个连接，但变量只提供累计值，无序列痕迹

真正可审计路径切换的关键变量组合

需配合其他变量构建带上下文的请求标记，推荐以下组合写入日志：

• $connection_requests：保留作为连接内序号参考（如第1次、第3次请求）
• $request_uri 或 $uri：识别请求资源路径，区分不同业务接口
• $upstream_addr：记录实际转发到的后端地址（含 IP:port），直观反映路径选择结果
• $time_iso8601：提供毫秒级时间戳，用于判断请求是否紧邻（例如间隔
• $server_name + $host：辅助识别虚拟主机和路由入口，排除跨域名干扰

示例日志格式定义：
log_format path_switch '$time_iso8601|$connection|$connection_requests|$uri|$upstream_addr';

从日志中识别连续路径切换的操作方法

拿到日志后，按 $connection 分组，对每组内请求按 $time_iso8601 排序，再检查相邻请求的 $upstream_addr 是否变化：

• 若前一条 upstream_addr=10.0.1.10:8080，后一条变为 10.0.1.11:8080，且时间差 ≤ 200ms → 判定为一次主动路径切换
• 若 $upstream_addr 不变，但 $uri 差异大（如 /api/user → /api/order），说明同一连接复用下访问了不同服务路径，属正常复用，非故障切换
• 若 $upstream_addr 变为 "-"（空） 或 "127.0.0.1:xxx"，可能触发了本地 fallback 或 error_page 重定向，需单独归类

进阶：用脚本自动标记切换事件

可用 awk 或 Python 快速提取切换行为。例如 awk 脚本逻辑：

• 以 $connection 为键缓存上一条请求的 $upstream_addr 和 $time_iso8601
• 当前行与缓存时间差 ≤ 0.3 秒，且 $upstream_addr 不同 → 输出 “SWITCH” 标记行
• 支持输出切换前/后 upstream、耗时、请求序号（$connection_requests），便于关联排查

这类分析不依赖实时监控系统，原始日志即可回溯，适合事后审计或灰度发布验证。