连接数高需区分业务增长、配置瓶颈、攻击或程序缺陷，重点分析连接主体、方式及合理性，通过ss命令快速统计状态、定位ip与端口、结合基线判断异常，并检查系统级限制。
连接数高不等于故障，但需要快速区分是业务增长、配置瓶颈，还是攻击或程序缺陷。重点不是“数多少”，而是“谁连的、怎么连的、连得是否合理”。
一、快速摸清当前连接总量与状态分布
先用轻量命令看全局情况，避免 netstat 卡顿：
- 总 TCP 连接数：ss -s | grep “TCP:”（比 netstat 快，开销低）
- 按状态细分：例如查 SYN_RECV 是否异常增多——ss -tan state syn-recv | wc -l，超过几十个就需警惕
- 统计所有连接状态数量：ss -tan | awk ‘{print $1}’ | sort | uniq -c | sort -nr，重点关注 TIME_WAIT、ESTABLISHED、CLOSE_WAIT 的占比
二、定位“谁在连”和“连了什么”
连接暴增通常集中在少数 IP 或端口，要分层下钻：
- Top 10 源 IP（按连接数）：ss -tn | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr | head -10
- 本地哪些端口连接最多（判断是否某服务异常）：ss -tn | awk ‘{print $4}’ | cut -d: -f2 | sort | uniq -c | sort -nr
- 查某个端口（如 8080）的访问来源 IP 分布：ss -tn sport = :8080 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr
三、结合基线判断是否真异常
单看“2000 个连接”没意义，要看它是否偏离常态：
- 查近一小时流量趋势：vnstat -l，确认带宽是否同步飙升
- 查 nginx/apache 日志中成功请求数（如 200 状态）：awk ‘$9==200 {c++} END{print c+0}’ /var/log/nginx/access.log
- 对比历史峰值：若平时 ESTABLISHED 稳定在 300，当前突增至 2500，且 90% 来自同一 C 段、User-Agent 固定、URL 路径单一（如 /wp-login.php），大概率是暴力扫描或 CC 攻击
四、检查系统级限制是否成为瓶颈
连接数上不去，有时不是攻击，而是被系统卡住了：
- 当前进程最大文件描述符数：ulimit -n（普通用户默认常为 1024）
- 系统级总文件句柄上限：cat /proc/sys/fs/file-max
- 已分配文件句柄数：cat /proc/sys/fs/file-nr（三列中第一列是已使用数）
- 连接跟踪表上限（影响 NAT/防火墙性能）：sysctl net.ipv4.ip_conntrack_max
不复杂但容易忽略：很多“连接数高”的问题，其实是应用没及时 close，堆积大量 CLOSE_WAIT；或是客户端短连接频繁建连，而服务端未启用 tcp_tw_reuse 导致 TIME_WAIT 占满端口。先看状态，再看日志，最后调参数。