连接数暴涨需先分析状态分布：ESTABLISHED激增表明业务上涨或后端响应慢；TIME_WAIT短时翻倍提示短连接风暴；CLOSE_WAIT持续升高则为服务端连接泄漏。
连接数暴涨 ≠ 流量大，先看状态分布
连接数突增本身不是问题，关键看 ss -s 输出里各状态占比：如果 ESTABLISHED 激增，大概率是业务请求真实上涨或后端响应变慢导致连接堆积；如果 TIME_WAIT 短时间翻倍，说明短连接风暴（比如 HTTP 客户端没复用连接、爬虫高频抓取）；而 CLOSE_WAIT 持续升高，基本可断定是服务端代码没调用 close() 或 shutdown()，属于典型的连接泄漏。
查来源 IP 和目标端口，定位“谁在连”和“连谁”
用这两条命令快速筛出异常点：
-
ss -tn | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10—— 找出连接最多的远程 IP，判断是否为爬虫、攻击源或某台异常上游机器 -
ss -tn | awk 'NR>1 {print $4}' | cut -d: -f2 | sort | uniq -c | sort -nr | head -10—— 查哪个本地端口被疯狂连接，对应的服务就是“受害者”或“问题出口”
特别注意：若大量连接指向 :8080 但该服务日志里没有等量请求，很可能是客户端未复用连接（如 Python 的 requests 每次新建 session）、或代理/网关配置了短超时 + 无 keep-alive。
别漏掉文件描述符和内核队列这两个“隐形瓶颈”
很多连接失败报错 Too many open files，表面是连接多，实则是限制没开全：
- 单进程限制靠
ulimit -n，但 systemd 服务默认被DefaultLimitNOFILE=65536截断，必须改/etc/systemd/system.conf并systemctl daemon-reload - 系统级总上限由
fs.file-max控制，设太高会挤占内核内存（建议按内存 GB × 100000 估算） - SYN 队列满会导致
ListenOverflows上升，需同步调高net.core.somaxconn和net.ipv4.tcp_max_syn_backlog，否则连接直接被丢弃，客户端看到的是超时而非拒绝
改完不重登终端，ulimit -n 还是旧值；改完不 sysctl -p，内核参数根本没生效——这些不是“忘了”，是 Linux 加载机制决定的硬约束。
TCP 参数误配会让问题雪上加霜
比如盲目开启 net.ipv4.tcp_tw_recycle（已废弃），在 NAT 环境下会导致部分客户端连接随机失败；又比如把 net.ipv4.ip_local_port_range 还卡在默认 32768 60999，短连接密集时端口几秒就耗尽，新连接直接 fallback 到 TIME_WAIT 等待释放，形成恶性循环。
真正要动的通常是这三项：net.ipv4.tcp_tw_reuse = 1（客户端可重用 TIME_WAIT 套接字）、net.ipv4.tcp_fin_timeout = 30（缩短 FIN_WAIT_2 超时）、net.ipv4.tcp_max_tw_buckets = 2000000（防哈希表溢出）。但所有调整都得配合 ss -s 和 /proc/net/netstat 中的 SynDrop/ListenDrops 指标验证，而不是凭感觉加数字。
