nginx 默认日志变量不提供 upstream server 实时活跃连接数，因 least_conn 的连接计数仅内存维护且未暴露为日志变量；需用 stub_status+脚本、nginx plus api 或 upstream-check 模块获取。
要排查 Nginx least_conn 负载均衡策略下日志中缺少连接数指标的问题，核心在于：Nginx 官方日志模块（log_format）**默认不提供当前 upstream server 的实时活跃连接数字段**，$upstream_addr、$upstream_status 等变量无法直接反映 least_conn 选中的依据（即各 backend 的当前连接数）。这不是配置错误，而是功能限制。
为什么日志里看不到每个 server 的连接数？
Nginx 的内置日志变量中：
-
$upstream_addr只记录实际转发到的后端地址（含 IP:port），不带连接状态； -
$upstream_connect_time/$upstream_header_time是时序指标，和连接计数无关； -
least_conn的决策发生在请求分发前，该数值是内存中动态维护的（per-server connection counter），但 Nginx 未将其暴露为可记录的变量。
替代方案：用 stub_status + API 或第三方模块暴露连接数
若需观测各 upstream server 当前连接数，需借助外部手段：
-
启用
ngx_http_stub_status_module并配合自定义监控脚本：虽然它只显示 Nginx 总体连接数（Active, Reading, Writing, Waiting），不区分 upstream，但可结合nginx -T和进程级连接统计（如ss -tnp | grep :port）粗略估算后端负载； -
使用
nginx-plus或开源模块如nginx-upstream-check-module+nginx-sticky-module：Nginx Plus 提供/api/5/upstreams/<name>/servers</name>接口，返回含active字段的 JSON，精确反映每个 server 的当前活跃连接数； -
在 upstream 块中启用
check指令（需编译 check 模块）并搭配status页面：部分定制版本支持在 status 页面显示active列，可用于人工或脚本轮询。
验证 least_conn 是否生效：看请求分发是否倾向低连接后端
不依赖日志中的“连接数字段”，可通过间接方式确认策略行为：
- 用
ab或wrk对同一 upstream 发起并发请求（如 1000qps 持续 30 秒）； - 分别在各 backend 机器上执行
ss -tn sport = :your_app_port | wc -l，观察连接数是否明显不均衡（低连接数节点承接更多新连接）； - 在 Nginx 日志中用
$upstream_addr统计各 backend 被选中的频次，对比其初始连接负载 —— 若初始连接数差异明显，least_conn 应导致频次向连接少的一方偏移。
注意：不要误用 $connections 变量
$connections 是 Nginx worker 进程的总连接数（来自 stub_status），与 upstream server 的连接数完全无关。试图在 log_format 中使用它来代表 least_conn 决策依据，会导致完全错误的理解。
