连接数统计偏高通常源于Nginx对“连接”的判定与业务预期不一致，尤其在代理转发、HTTP/2多路复用或upstream长连接场景下，$binary_remote_addr等key导致单连接反复计入，或idle连接、缓冲阻塞、reuseport统计口径差异被误计为活跃连接。
连接数统计偏高，通常不是真实并发连接过多，而是 Nginx 模块（如 ngx_http_limit_conn_module 或自定义计数逻辑）对“连接”的判定与业务预期不一致，尤其在代理转发场景下容易误统计。排查重点不在“有多少连接”，而在“哪些连接被计入、为何重复或滞留”。
确认 limit_conn 的作用域和键值是否合理
limit_conn 统计依赖 limit_conn_zone 定义的键（key）。代理场景中常见错误是用 $binary_remote_addr 作为 key，但后端服务启用了长连接复用（如 HTTP/1.1 keepalive 或 HTTP/2），同一个客户端 IP 可能持续复用少数几个 TCP 连接发起大量请求，导致单个连接被反复计入（尤其配合不当的 limit_conn 放置位置）。
- 检查 zone 定义：确认 key 是否包含能区分请求粒度的变量，例如
$server_name:$binary_remote_addr或更精细的$http_x_forwarded_for（需确保可信） - 避免在
location块中重复声明limit_conn，否则可能因多匹配触发多次计数 - 用
log_format加入$limit和$limit_key变量，记录实际生效的 key 值和限流状态，验证是否 key 冲突或重复命中
检查 upstream 长连接配置与连接复用行为
代理转发中，Nginx 与上游服务器之间的连接复用（keepalive）本身不直接影响 limit_conn，但如果 upstream 配置了 keepalive 32 且未设 keepalive_requests 或 keepalive_timeout，可能导致 Nginx worker 进程长期持有空闲 upstream 连接，而这些连接在某些自定义模块或监控脚本中被错误纳入“活跃连接”统计（比如通过 stub_status 的 Active connections 是 TCP 连接总数，含 idle 状态）。
- 确认
upstream块中设置了合理的keepalive_requests（如 100）和keepalive_timeout（如 60s） - 用
ss -tnp | grep :your_upstream_port观察 ESTABLISHED 连接的实际数量和生命周期，对比nginx -T | grep limit_conn配置，判断是否 upstream 连接被误读为客户端连接 - 若使用第三方连接统计模块（如
nginx-module-vts），查阅其文档确认“connection”指标是否包含 upstream idle 连接
排查 proxy_buffering 和请求体读取导致的连接滞留
当 proxy_buffering off 或客户端发送大 body（如文件上传）且未及时读取时，Nginx 会保持客户端连接等待后端响应或缓冲区释放，此时连接处于 “reading request header” 或 “reading request body” 状态，仍被计入活跃连接，但并非有效业务连接。
- 启用
error_log debug;（临时），搜索"client timed out" "upstream sent too big header" "client closed prematurely"类日志，定位是否因读写阻塞导致连接卡住 - 检查
client_header_timeout、client_body_timeout、proxy_read_timeout是否过长（如设为 300s），导致异常连接长期不释放 - 对上传接口单独配置更短的超时和独立的
limit_connzone，避免影响其他路径
验证是否受 reuseport 或多 worker 影响统计口径
启用 listen ... reuseport 时，每个 worker 进程独立监听端口，limit_conn 的 zone 是 worker 级别共享的（默认），但部分旧版本或特殊编译模块可能存在 zone 同步延迟；同时，stub_status 显示的是当前 worker 的连接数，若用脚本聚合所有 worker 数据却未去重，也会虚高。
- 运行
ps -ef | grep nginx查看 worker 数量，再分别请求每个 worker 的/basic_status（需绑定不同端口或用worker_connections分离）比对数值 - 升级到 Nginx 1.19.10+，确保
reuseport与limit_conn兼容性 - 避免直接用
netstat -an | grep :80 | wc -l代替stub_status，前者包含 TIME_WAIT、CLOSE_WAIT 等非活跃状态
不复杂但容易忽略：统计偏高往往源于“连接定义”和“业务模型”错位，而不是模块坏了。先厘清你要限的是“客户端 IP 并发请求数”，还是“到上游的连接数”，或是“当前处理中的事务数”，再选对模块和 key，比调参数更重要。
