$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），便于关联排查
这类分析不依赖实时监控系统，原始日志即可回溯，适合事后审计或灰度发布验证。
