TCP连接数暴增的常见原因包括SYN Flood、慢速连接攻击、TCP全连接耗尽以及基于TCP的放大反射攻击，其中SYN Flood是最典型也最容易被误判的手法。 当你打开服务器监控面板，看到established连接数从几百突然跳到几万，第一反应往往是“是不是被扫了”，但TCP连接数暴增并非只有一种套路，不同攻击手法在连接状态、源IP特征和行为模式上差异很大，排查和防御思路也完全不同。
TCP连接数暴增是什么原因？先分清正常与异常
TCP连接数暴增本身不是故障,而是结果，线上业务做促销、爬虫抓取、API接口被批量调用，都会导致连接数上升，判断是否攻击，核心看三个维度：源IP分布、连接状态、连接持续时间。
- 源IP集中且数量少,大概率是业务或者脚本行为。
- 源IP分散且端口随机,同时出现大量半连接或短连接，攻击嫌疑很大。
- 连接建立后长时间不传输数据,占着连接不释放，属于典型的慢速攻击特征。
业内专家指出,攻击者为了提高效率和绕过简单限流，通常会混用多种手法，比如先用SYN Flood冲击入口，再配合慢速攻击拖住后端的连接池，让你拆东墙补西墙。
从连接状态判断攻击类型
用 netstat 或 ss 查看当前连接，状态比数量更有说服力，常见的异常状态组合有：
- 大量SYN_RECV：说明三次握手没完成，对方发完SYN不回应ACK，典型的SYN Flood。
- 大量ESTABLISHED但无数据交互：连接建成了，但既不发请求也不断连，可能是慢速连接攻击，或者被控制端用来占坑。
- 大量TIME_WAIT：主动关闭连接后残留的状态，短时间高并发请求会引发，不一定算攻击，但连接数会被推高。
- 大量CLOSE_WAIT：对端关闭了连接，本地程序没有及时close，说明应用层处理有问题，攻击者利用这一点可以拖垮进程。
如何排查TCP连接数异常？三步定位攻击源头
排查连接数暴增,不要一上来就重启或封IP，按顺序做以下三个步骤，能快速缩小范围。
第一步：按状态统计连接数
在Linux服务器上执行：
ss -ant | awk '{print $1}' | sort | uniq -c
这条命令会列出每个状态的数量,如果SYN_RECV或ESTABLISHED占比异常高，基本可以判定是攻击，接着看具体连接的来源IP：
ss -ant | grep SYN_RECV | awk '{print $4}' | sort | uniq -c | sort -rn | head -20
这里显示的是本机端口,不是源IP，要拿源IP，用：
ss -ant | grep SYN_RECV | awk '{print $3}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
找到排在前面的IP,先用 ping 和 traceroute 确认是不是真实存在的主机，很多攻击IP是伪造的，根本不可达。
第二步：抓包看握手特征
如果连接状态统计结果不清晰,用 tcpdump 抓包分析：
tcpdump -i eth0 tcp port 80 and "tcp[tcpflags] & tcp-syn != 0" -c 1000 -w syn.pcap
把抓到的包用Wireshark打开,重点看SYN包的源IP和TTL值，正常用户发起的SYN包TTL通常集中在几个固定值附近，比如64、128，攻击工具发出的SYN包往往TTL值千奇百怪，或者所有包TTL完全相同后者更可疑，说明是批量生成的。
第三步：结合业务日志交叉验证
网络层的数据只能说明“连接异常”，不能说明“业务被攻击”，需要结合Nginx、Tomcat或业务应用日志，看这些连接对应的实际请求行为：
- 是否大量请求同一个URL,且不带正常浏览器UA？
- 是否在短时间内重复请求消耗资源的接口,比如登录、搜索？
- 是否请求完立即断开,或者发起请求后长时间不读响应？
如果连接异常的同时,业务日志里出现大量超时记录或低效请求，基本上可以定性为应用层攻击，只是借TCP连接作为载体。
针对TCP连接数暴涨攻击的防御方案
攻击手法决定了防御手段,没有一套配置能防住所有情况，下面按攻击类型给出对应的实操方案。
SYN Flood：核心是减少半连接资源消耗
SYN Flood的目标是塞满你的半连接队列，Linux内核默认的tcp_max_syn_backlog有限，攻击一旦超过这个值，新连接直接丢弃，常见做法：
sysctl -w net.ipv4.tcp_max_syn_backlog=2048 sysctl -w net.ipv4.tcp_synack_retries=1 sysctl -w net.ipv4.tcp_syn_retries=1
但这只是调大缓冲区,治标不治本，更有效的方法是在防火墙或接入层开启SYN Cookie，Linux下执行：
sysctl -w net.ipv4.tcp_syncookies=1
开启后内核在SYN队列满时,不再直接丢弃，而是通过Cookie机制生成一个合法的SYN+ACK响应，从而保护后端连接池，注意，SYN Cookie会影响TCP扩展选项（如时间戳、窗口缩放），高吞吐场景下可能带来性能损失，所以只在遭受攻击时临时开启。
慢速连接攻击：限制空连接和超时时间
慢速攻击的原理是建立连接后,用极小速率发送数据，让服务器一直等待，Nginx里可以这样限制：
client_body_timeout 10s; client_header_timeout 10s; keepalive_timeout 15s;
同时用limit_conn限制每个IP的并发连接数：
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;
如果你的服务是TCP四层转发,比如LVS或haproxy，需要设置空闲超时，haproxy配置：
defaults timeout connect 5s timeout client 10s timeout server 10s
短超时能快速释放被占用的连接,但要注意，正常用户上传大文件或使用WebSocket时，超时不能设得太短，否则会误杀业务，行业共识是区分端口或路径做差异化策略。
TCP全连接耗尽：扩容连接表并做源IP限速
攻击者如果伪造大量合法三次握手,建立完整连接但不传输数据，服务器连接表会被撑满，Linux连接表上限由net.ipv4.tcp_max_tw_buckets和net.core.somaxconn控制：
sysctl -w net.core.somaxconn=4096 sysctl -w net.ipv4.tcp_max_tw_buckets=50000
但这些参数只能缓解,不能阻止攻击，真正的防线是把连接数限制前置到入口层，比如用iptables限制单个IP的连接速率：
iptables -A INPUT -p tcp --syn -m limit --limit 200/s -j ACCEPT
更精细的做法是用hashlimit模块：
iptables -A INPUT -p tcp --syn -m hashlimit --hashlimit-above 50/sec --hashlimit-mode srcip --hashlimit-name synlimit -j DROP
这条规则把每个源IP的SYN包速率限制在每秒50个,超过的直接丢包，对于代理或NAT后的用户，可能需要放宽到200以上，否则正常用户会被误杀。
放大反射型攻击：关闭不必要服务并部署认证
TCP虽然不像UDP那样容易被放大,但某些服务（如HTTP的TCP反射）也能造成连接洪峰，攻击者伪造受害者IP，向服务器发起大量连接请求，服务器回复的SYN+ACK会打到受害者身上，防御思路是：
- 关闭公网不必要的TCP端口,只开放业务必需端口。
- 对敏感端口（如6379、3306）增加IP白名单或防火墙规则。
- 在业务层增加验证机制,比如要求客户端在连接后先发特定握手包，不通过则立即断开。
服务器TCP连接数过多怎么办？临时应急与长期方案
如果你恰好遇到连接数暴涨,且服务器已经接近不可用，按下面顺序做应急处理，能先保命再根治。
应急手段：限流和封禁优先
- 用
ss -ant找出占用连接最多的前20个IP，写成黑名单。 - 在防火墙层临时封禁：
iptables -A INPUT -s 1.2.3.4 -j DROP
如果攻击源是随机IP,无法逐个封，就启动全局连接速率限制：
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m limit --limit 5000/minute -j ACCEPT
在应用层临时切换验证页面,比如让用户先输验证码再进入业务，消耗攻击者的连接，同时把静态资源迁移到CDN。
长期方案：把TCP防护下沉到基础设施
单台服务器的TCO防护能力有限,如果业务经常被TCP连接类攻击，建议采用云厂商的高防IP或负载均衡服务，据工信部发布的网络安全威胁监测数据，TCP SYN Flood在DDoS攻击中占比较高，多数云服务商都提供免费的DDoS基础防护，但容量有限，核心业务需要购买高防包。
具体操作：在DNS解析层把业务域名指向高防IP，高防回源到真实服务器，所有流量先经过清洗中心，过滤掉非法连接后再放行，这一方案能同时处理SYN Flood、慢速攻击和反射放大，服务器侧不再需要频繁调整内核参数。
TCP连接数暴增是攻击吗？常见疑问解答
TCP连接数暴增一定是黑客攻击吗
不一定是,搜索引擎爬虫、第三方监控工具、未做并发控制的内部脚本，都可能导致连接数暴涨，判断时需要结合时间规律和请求路径，比如每天固定时段暴增，更可能是定时任务；攻击则往往无规律，且伴随大量异常状态，先看状态统计，再看访问日志，最后才考虑封锁。
如何区分TCP连接数暴涨是DDoS还是CC攻击
DDoS主要消耗网络层和传输层资源,表现为SYN_RECV、半连接或全连接占满；CC攻击则主要消耗应用层资源，连接数正常建立，但请求频率极高，集中在消耗CPU或数据库的接口，区别的关键在于：关闭应用后，如果连接数依然暴增，是DDoS；如果连接数下降但CPU依然满载，是CC，实际攻击中两者经常叠加，防御时也要分层部署。