关键在于区分“活跃请求”（writing + reading）与“空闲连接”（waiting），active connections 包含三者总和，waiting 偏高会误判并发压力；应监控 writing 值、qps 及 upstream 状态，并合理调低 keepalive_timeout 和 keepalive_requests 以减少干扰。
排查 Nginx 并发连接数统计中因长连接（Keep-Alive）导致的误判，关键在于区分“活跃请求”和“空闲连接”。Nginx 的 Active connections（如通过 stub_status 暴露）统计的是当前所有已建立、尚未关闭的 TCP 连接数，包括正在处理请求的、等待新请求的 Keep-Alive 空闲连接，以及正在读写数据的连接——它不等于真实并发请求数。
看懂 stub_status 中的三类连接含义
Active connections: 1234<br>server accepts handled requests<br>123456 123456 789012<br>Reading: 3 Writing: 5 Waiting: 1226
其中：
- Reading：正在读取客户端请求头/体的连接（通常极短，可忽略）
- Writing：正在向客户端发送响应的连接（对应真实处理中的请求）
- Waiting：Keep-Alive 空闲连接，已处理完上一个请求，等待下一个请求到来（默认最长 60s）
⚠️ 误判主因就是 Waiting 数值偏高——它拉高了 Active connections 总数，但不代表有实际业务压力。比如 1000 个客户端复用连接，每秒只发 1 个请求，Waiting 可能长期维持在 900+，而真实并发请求（Writing + Reading）可能只有个位数。
用实时指标交叉验证真实并发负载
单看 Active connections 不可靠，需结合其他维度判断：
- 监控
Writing值：稳定高于 50 或持续 > 80% 的 worker_connections 配置值，才说明响应阶段存在瓶颈 - 观察请求速率（requests/sec）：用
log_format记录$request_time和$upstream_response_time，聚合计算 QPS 和慢请求比例 - 检查 upstream 连接状态：若使用 proxy_pass，关注
upstream_addr和upstream_status，确认是 Nginx 自身连接堆积，还是后端响应慢导致连接滞留
调整 Keep-Alive 参数降低 Waiting 干扰
合理设置长连接生命周期，避免空闲连接长期占位：
-
keepalive_timeout 15s;：比默认 65s 更激进，适合客户端请求间隔较短的场景 -
keepalive_requests 100;：限制单连接最大请求数，防止单连接长期占用（尤其对 HTTP/1.1 客户端） - 对 API 网关或微服务入口，可考虑
keepalive_timeout 5s;+keepalive_requests 20;，平衡复用与连接清理
注意：调低 timeout 会增加 TCP 握手开销，需结合客户端特性（如移动端弱网下不宜过短）和压测结果权衡。
用连接跟踪辅助定位异常长连接
当怀疑某类客户端（如特定 User-Agent 或 IP 段）滥用 Keep-Alive，可临时启用连接日志：
- 添加
log_format conn_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$connection" "$connection_requests"'; - 配合
access_log /var/log/nginx/conn.log conn_log; - 分析
$connection_requests字段：持续 > 1000 的连接可能是异常复用或未正确关闭 - 用
ss -tn state established | grep :80 | wc -l对比系统级连接数，验证是否 Nginx 内部统计与内核一致
不复杂但容易忽略
