TCP连接数异常暴涨，十有八九是SYN Flood或CC攻击的开场信号，但也可能是爬虫、配置失误或业务突增，先看连接状态再动手封禁，别误伤正常流量。
TCP连接数异常暴涨是什么原因？先分清攻击和误报
很多站长第一次发现服务器卡死,都是因为ss -s输出里established数量冲到几千甚至上万，这时候先别急着关服务器，连接数暴涨只是一个症状，不是攻击本身，业内专家指出，攻击流量与正常流量在连接状态分布上有明显差异，这是判断的第一把尺子。
四种可能：攻击、爬虫、配置、业务
- SYN Flood：半连接占满，
SYN_RECV状态暴涨，tcp_max_syn_backlog被塞爆。 - CC/应用层攻击：
ESTABLISHED连接少但每个都占着不释放，CPU和php-fpm进程被打满。 - 恶意爬虫/采集：UA特征明显，IP段集中，连接数高但单连接请求次数少。
- 配置失误/业务突增：连接池泄漏、代理超时设置过长，或活动大促带来的瞬时量。
行业共识认为,判断的第一件事不是看总数，而是看连接状态的比例，打开终端跑一条命令：
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
输出里如果SYN-RECV占了大头，基本可以锁定泛洪攻击；如果全是ESTABLISHED且TIME-WAIT极少，则更可能是应用层慢消耗或业务问题。
连接状态的"体检报告"怎么读
| 状态 | 含义 | 暴涨含义 |
|---|---|---|
| SYN_RECV | 收到SYN但未完成握手 | 大概率SYN Flood |
| ESTABLISHED | 握手完成 | 应用层攻击或爬虫 |
| TIME_WAIT | 主动关闭方等待 | 连接复用配置不到位 |
| CLOSE_WAIT | 被动关闭方未关闭 | 代码没关连接，业务Bug |
多数情况下,CLOSE_WAIT大量堆积是代码问题，不是攻击，排查时先排除这个，免得白打半天防火墙。
服务器TCP连接数突然变多，怎么一步步排查
别一上来就拔网线,按下面几条命令逐层往下看，每一步都有输出可验证。
看总量和状态分布
ss -s
总量高但TCP: Syncookies sent数值也在涨，说明syncookie机制已经在硬扛泛洪，注意看timesync字段，重传率高说明链路拥塞或对端在丢弃连接。
抓TOP IP
ss -nt | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20
前20个IP里如果单个IP连接数占总量一半以上,且来源IP段集中，那就是明牌攻击，如果IP分布很散、每IP就几十个连接，更像肉鸡专网。
看端口维度
ss -ant | grep ':80' | awk '{print $1}' | sort | uniq -c
Web服务端口异常,对照Nginx日志看是动态请求还是静态资源，如果全是POST /login或GET /api/xxx，那就是CC，同时跑一个top看CPU，用户态高是CC，内核态高是SYN Flood这个区分百试不爽。
TCP连接数暴涨 攻击还是配置问题？用这几招快速定位
有次一个客户报"被打了"，查下来是Nginx的worker_connections配了1024但keepalive_timeout设成75秒，连接全堵在TIME_WAIT，这种情况防火墙封IP只会让事情更糟。
对比特征：攻击 vs 误报
- 攻击：源IP分散、无规律UA、请求路径集中、单连接请求次数极少（<3次）
- 误报：源IP固定段、UA正常、请求路径贴合业务逻辑、单连接请求次数多
快速验证法：用tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'抓包看SYN包的源地址，如果伪造性明显（MAC与IP不匹配、TTL值罕见），基本坐实是DDoS。
一次实战排查的顺序
先看ss -s确认异常级别 → 再跑ss -nt列出TOP连接IP → 同步看Nginx access log里这些IP的请求模式 → 用strace -p [pid]抽查一个连接的行为。strace输出里如果一直卡在recvfrom或read，说明对方发了数据但不等响应，是典型的慢速攻击特征。
连接数已经爆了，眼下怎么应急
别慌,按这个顺序操作，每一步都能立刻降负担。
第一步：临时提高Backlog和Syncookies兜底
sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=8192 sysctl -w net.ipv4.tcp_synack_retries=1
注意，syncookies开启后Nginx日志里可能出现客户端握手慢的假象，这是正常现象，应急结束后记得调回生产值。
第二步：按特征封禁，精准打击
# 封禁SYN重试异常IP iptables -A INPUT -p tcp --syn -m connlimit --conn-above 50 -j DROP # 封禁单IP并发连接 iptables -A INPUT -p tcp --dport 80 -m connlimit --conn-above 100 -j DROP
如果是Nginx+PHP站点，再加一层限制：limit_conn_zone $binary_remote_addr zone=perip:10m;，然后在server块里limit_conn perip 30;，这个限制对应单IP的并发TCP连接数，从源头控制半开连接和慢连接
。
第三步：应用层防御
SYN Flood被防火墙挡住后，如果连接数还是高，多半是CC，在Nginx层加频率限制：
limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;
针对动态请求location块启用,静态资源不要限制，否则GEO爬虫和正常用户会被误伤。这里要区分Spider的IP段，百度蜘蛛、Googlebot都有公开IP段可以白名单。
关于TCP连接数异常暴涨的常见问题
连接数暴涨和服务器CPU飙升总是同时出现吗？
不一定,SYN Flood主要消耗内核协议栈和内存，CPU可能只升到30-50%；CC攻击才直接打满用户态CPU和数据库连接池，如果CPU没爆但服务器响应慢，优先排查内存溢出和SWAP交换。
怎么区分正常业务峰值和攻击型暴涨？
连接增长速率是硬指标,正常大促的流量增长曲线是渐进的，攻击流量往往在1-2分钟内直线拉升，且伴随着大量TCP重传和RST包，配合fastsocket或nettop看实时新建连接速率，正常波动有节奏，攻击是持续高压。
封IP不生效怎么办？
IP封禁对真实IP的CC有效,对肉鸡SYN Flood基本无效，这时该上tc限速或直接联系机房上防火墙清洗。单机层面的iptables对超大规模洪泛本身就不是合格的防御手段，架构上在边缘节点做流量清洗才是长远之计。
连接数暴涨是一场"感冒"，本身不是绝症，症状背后的原因决定了治疗手段：是病毒（攻击）就隔离，是自身的慢性病（配置Bug）就调理，别让每一次"疑似攻击"都变成熬夜打地鼠的游戏把监控指标（新建连接数、状态分布、重传率）纳入日常巡检，很多暴涨其实在萌芽阶段就能被自动化脚本按死。