活跃连接数突增需结合业务行为、资源水位和连接状态分布综合判断，不能仅看数值；需分析来源IP、目标端口、Nginx状态比（Reading/Writing/Waiting）、系统与Nginx连接上限、日志状态码及时间点关联线索。
活跃连接数突增本身不等于异常，关键看它是否匹配业务行为、资源水位和连接状态分布。直接查数字没用，得结合上下文判断。
看连接来源和目标分布
先确认这些连接是进来的还是出去的，连向哪里：
- 用 ss -ant | awk '{print $5}' | sort | uniq -c | sort -nr | head -10 查访问最多的客户端 IP，突然出现大量单一 IP 或某网段密集连接，大概率是扫描或 CC 攻击
- 用 ss -ant | grep ':80\|:443' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr 看外部请求来源分布
- 如果连接大量指向后端服务端口（如 :8080、:3000），且集中在少数 IP，说明是 upstream 连接堆积，可能后端处理慢或 accept 队列满
查连接状态构成
Nginx 的 /nginx_status 输出里 Reading / Writing / Waiting 三类状态比总数更有价值：
- Reading 高：请求头还没收完，可能是大文件上传、恶意慢速攻击（Slowloris）或客户端网络差
- Writing 高：响应正在发给客户端，常见于大响应体、带宽打满、后端返回慢导致 Nginx 缓冲区积压
- Waiting 高（且 Active connections 持续高位）：说明大量连接处于 keepalive 空闲状态，属正常；但如果 Waiting 高而 Reading/Writing 极低，又伴随高 QPS，则可能是连接复用率异常升高，需检查 upstream keepalive 配置是否合理
比对系统级连接与 Nginx 配置上限
活跃连接数不是孤立指标，要和两个硬限制交叉验证：
- 查当前配置：运行 nginx -T 2>/dev/null | grep -E 'worker_processes|worker_connections'，算出理论最大连接数 = worker_processes × worker_connections
- 查系统限制：运行 cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，确保它 ≥ 上述理论值，否则会触发 “too many open files” 错误
- 若活跃连接数接近上限，同时 error.log 出现 accept() failed (24: Too many open files) 或 connect() failed (11: Resource temporarily unavailable)，就是真瓶颈，不是流量问题而是配置或系统资源不足
关联日志与时间点交叉分析
突增不是凭空发生的，必须对齐时间戳找线索：
- 用 tail -n 200 /var/log/nginx/access.log | awk '{print $4,$9}' | sort | uniq -c | sort -nr 查突增时刻前后 5 分钟内状态码分布 —— 若 499（客户端主动断开）、444（Nginx 丢弃）、502/504 集中出现，往往指向后端不稳定或超时配置过严
- 同步查 error.log：grep "$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M' 2>/dev/null)" /var/log/nginx/error.log，重点看是否有 upstream timed out、no live upstreams 或 connect() to ... failed
- 如果突增时段恰好对应某个定时任务、爬虫调度、CDN 回源高峰或发布动作，就大概率是可解释的业务行为
