孙晓岸作为网络运维和渗透测试都沾过边的老手，我对SYN洪水攻击可以说是又恨又爱。恨的是，它曾让一台满载业务的服务器在几分钟内彻底“失联”，全公司盯着我看；爱的是，搞懂它之后，我对TCP协议的理解、对系统内核参数的敏感度、对网络排障的思路，都上了一个台阶。这篇笔记不打算从教科书定义讲起，而是把我从“被攻击时一脸懵”到“能快速定位并缓解”的完整过程、背后原理和实操命令，全部沉淀下来。如果你是刚接触网络进阶的学习者，或者正在被类似问题折磨的运维同行，这篇内容应该能给你一套可以立刻上手的排查和防御思路。
SYN洪水攻击，本质上瞄准的是TCP三次握手中那个最容易被忽略的空档——服务器在收到SYN、尚未完成握手时，必须为这个“半连接”分配资源。攻击者就是抓住这个空档，疯狂发送伪造源地址的SYN包，让服务器的半连接队列被塞满，从此再也无法响应正常的连接请求。下面我按“现象、原理、识别、排查、防御、学习”这条线，一次讲透。
1. 从一次诡异的“服务器假死”说起：SYN洪水攻击到底做了什么
1.1 那天下午，服务器突然“拒绝服务”了
印象很深的一次，是某个电商大促前的压测阶段，一台4核8G的Web服务器突然出现大面积连接超时。登录服务器执行ping完全正常，但从外部用浏览器访问却一直转圈，偶尔能打开，刷新后又是空白页。更奇怪的是top一看，CPU和内存占用都不到30%，怎么看都不像资源耗尽。
当时我下意识先看nginx日志和数据库连接数，都没异常。正准备重启所有服务时，旁边的老同事随口说了句：“你看下netstat -n | grep SYN_RECV是不是特别多。”我执行之后，直接被吓了一跳——SYN_RECV状态的连接数量达到了几万条，而正常情况下这个数字应该是个位数。
那一刻我才意识到，这不是应用层的故障，而是网络层被人用“SYN洪水”给堵住了。
1.2 TCP三次握手的“握手”到底是怎么完成的
要理解SYN洪水，必须先理解TCP为什么需要三次握手。正常的连接建立，客户端会先发送一个SYN包，告诉服务器“我要建立连接”；服务器收到后，会回复SYN+ACK，表示“我收到了，并同意建立连接”；客户端再回复一个ACK，表示“我也收到了，连接正式建立”。
这里有个容易忽略的点：服务器在收到第一个SYN、发出SYN+ACK之后，并不会立刻把这条连接放到“已建立连接”列表里，而是把它放进一个叫 半连接队列（SYN Queue）的缓冲区，等待客户端的最终ACK。这个队列的容量是有限的，长度由内核参数决定，典型值在几百到几千之间。
如果用排队取号来类比：客户端取号后，服务器会给它一个“临时号码”并把它记在等待区，等客户端拿着号回来确认，才算真正叫到号。等待区的位置是有限的，如果有一堆恶意客户端取完号后根本不回来，这个等待区就会被占满，后面真正想取号的正常客户端就完全无法进入。
1.3 攻击者是怎么“堵门”的
SYN洪水的核心攻击思路，就是不完成第三次握手。攻击者伪造大量不存在的源IP地址，向目标服务器发送海量SYN包。服务器每收到一个SYN，都会分配一小块内存、记录半连接状态，并回复SYN+ACK。问题在于，伪造的源IP根本不会回应这些SYN+ACK，于是服务器只能等待超时重传。
在等待超时和重传的过程中，半连接队列逐渐被这些“僵尸连接”填满。当队列满后，新的SYN请求会被直接丢弃，正常用户发起的连接也无法进入队列，自然就出现了“服务器还活着，但什么都访问不了”的假死状态。
攻击者选择的伪造源地址通常经过精心挑选，有的使用随机IP，有的使用真正的空闲IP段，目的就是让服务器无法通过简单的IP封禁来精准拦截。更狡猾的做法是让每个伪造源IP只发少量包，绕开基于源IP连接数阈值的告警。这也是很多新手在分析时容易误判的原因——你以为这是正常业务突发流量，实际上是来源分散、特征隐蔽的SYN洪水。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 别再把异常当故障：SYN洪水攻击的流量特征与识别方法
很多运维第一次遇到SYN洪水，都会像我一样先怀疑应用出问题。实际上，只要抓住几个关键指标，就能在几分钟内判断是不是SYN洪水在作怪。
2.1 第一眼：半连接数量严重超标
最直接的判断依据，是处于SYN_RECV状态的连接数量。在Linux服务器上，用一条命令就能看得明明白白：
bash复制netstat -ant | grep SYN_RECV | wc -l
正常情况下，这台机器的SYN_RECV数量在个位数到两位数波动。如果突然跳到几千、几万，且持续不降，基本可以高度怀疑是SYN洪水。
也可以用ss命令，输出更清晰：
bash复制ss -s
ss -ant state syn-recv
ss -s会汇总所有TCP状态。如果syn-recv的数值远超established，说明半连接已经堆积成灾。
另外要注意观察SYN_SENT状态。如果本机主动外连时出现大量SYN_SENT，且对方不回应，也可能是本机被攻击者当成了跳板或目标，但这种情况和纯入站洪水稍有区别，需要结合目标端口分析。
2.2 第二眼：目标端口的分布极不均衡
SYN洪水通常瞄准的是对外开放的端口，比如80（HTTP）、443（HTTPS）、22（SSH）等。用netstat按端口统计：
bash复制netstat -nt | awk '{print $4}' | sort | uniq -c | sort -rn | head
如果发现某个端口的连接数高得不正常，并且其中SYN_RECV占绝对多数，那基本就是被针对了。我遇到过一个案例，攻击者只打服务器的22端口，导致外部SSH完全连不上，但Web业务毫发无损。所以不要只盯着Web端口，要全端口排查。
2.3 第三眼：TCP重传率和握手成功率的变化
在路由器或服务器上用tcpdump抓包，是确认攻击最有力的手段。执行下面命令抓取80端口的流量，约30秒后停止：
bash复制tcpdump -i eth0 -n tcp port 80 -c 5000 -w syn_flood.pcap
然后用Wireshark或tshark分析，重点看三个特征：
- 大量
SYN包，且源IP不重复或分布极为分散； - 服务器回复
SYN+ACK后，几乎没有对应的ACK包出现； - 出现大量TCP重传，且重传的
SYN+ACK占比极高。
正常业务流量中，即使有人发起大并发，SYN和ACK的交换也会相对平衡，不会出现“只收SYN不给ACK”的一边倒局面。用数据说话：假如抓到的1000个TCP包里有900个是SYN，而对应的Handshake完成率不到1%，这几乎可以板上钉钉地断定是SYN洪水。
2.4 混淆项：别把全连接队列溢出误判成SYN洪水
在排查时还有一个常见误区：accept队列（全连接队列）溢出和SYN队列（半连接队列）溢出，表现很像，但成因完全不同。
accept队列溢出通常发生在应用层处理不过来时，比如Tomcat线程池满了、Redis请求堆积，此时ss -lnt中Send-Q会显示一个很大的积压值，同时出现Recv-Q满的情况。而SYN洪水的目标是把握手流程卡在第一步，现象是SYN_RECV激增。所以排查时务必同时看两个队列指标：
bash复制ss -lnt
里面第二列Recv-Q和Send-Q分别表示accept队列当前的连接数和最大长度。如果Recv-Q长期等于或接近Send-Q的值，说明你的应用处理不过来，需要扩容或优化应用；如果SYN_RECV爆满，那才是网络层问题。把这两者混为一谈，容易导致你花半天时间调应用，结果攻击还在继续。
3. 实战排查链路：确认攻击、定位来源、止损闭环
整个SYN洪水应急，最忌讳的是“凭感觉操作”。我推荐一条完整的排查链路，从接收到告警开始，每一步都有明确目的。
3.1 第一步：采集快照，保住现场
无论多慌，先别急着封IP、重启服务。首要做的是把当前状态完整记录下来，用于后续分析溯源。建议依次执行以下命令并把输出保存到文件：
bash复制date > /tmp/syn_time.txt
netstat -ant > /tmp/syn_netstat.txt
ss -s > /tmp/syn_ss.txt
tcpdump -i eth0 -n tcp port 80 -c 2000 -w /tmp/syn_attack.pcap &
dmesg -T | grep -i syn > /tmp/syn_dmesg.txt
tcpdump抓包只要30-60秒就够，不要一直开着，避免生成超大文件拖垮磁盘。同时把当时的top -bn1、free -h、uptime也存一份，方便后续判断是否伴随其他类型的资源耗尽攻击。保存完证据后，再进入处置阶段。
3.2 第二步：区分“真洪水”和“假洪水”
拿到快照后，先确认是不是“分布式攻击”。看netstat结果里源IP的分布情况：
bash复制netstat -ant | grep SYN_RECV | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
如果Top 20的源IP每个只有几十到几百条连接，同时总连接数巨大，说明攻击源分散，典型的DDoS式SYN洪水；如果某个源IP独占几千条连接，说明可能是单点扫描或畸形攻击，针对该IP封禁就能见效。
接下来看包特征：
bash复制tcpdump -i eth0 -n tcp[13]&2 != 0 and tcp[13]&16 == 0 -c 100
这个表达式会抓取只有SYN标志而没有ACK的包。如果几分钟内抓到的全是这种单SYN包，且几乎看不到后续的握手交互，那么攻击特征已经实锤。配合tcpdump统计一下每秒新增SYN数量：
bash复制tcpdump -i eth0 -n -c 1000 -t "tcp[tcpflags] & tcp-syn != 0" | wc -l
结合抓包时长，就能算出每秒SYN包速率。如果持续超过网卡或内核能处理的阈值，即使队列没满，也可能造成CPU软中断暴涨，这类情况同样需要立刻限速。
3.3 第三步：梯度止损，从“丢车保帅”到“全网限速”
止损顺序不能乱，否则容易误伤正常业务。我自己的优先级是这样的：
-
精确封禁来源IP：如果前一步发现少量源IP贡献了大量连接，立刻用
iptables或防火墙封禁。命令很快，但注意别封到代理或CDN的出口IP。 -
丢弃畸形报文：如果攻击包有明显特征（比如特定TTL、特定TCP窗口大小），可以用
iptables的--tcp-flags精确匹配并丢弃。例如只丢弃纯SYN且源端口为固定端口的包，能快速缓解。 -
限制单IP的握手速率：在防火墙层针对新建连接速率做限流，让单个源IP每秒最多只能发若干个SYN包，超出直接丢。
-
启用SYN Cookie：如果已确认是SYN洪水，且无法快速分流，立刻执行：
bash复制sysctl -w net.ipv4.tcp_syncookies=1
这个参数会在半连接队列满时，临时把连接信息编码到SYN+ACK的序列号中，不占用队列资源，是缓解SYN洪水的“救火神器”。之后还要配合tcp_max_syn_backlog适当调大，给正常连接留出缓冲空间。
- 联系上游或云服务商：如果攻击流量已经超过服务器带宽，无论本地怎么调都是徒劳。例如1Gbps的带宽被打满，本地优化只能保证CPU不被打爆，但链路依然拥塞，必须让机房或云服务商的流量清洗设备介入。
止损过程中，每做完一步都重新观察SYN_RECV数量是否下降。如果在启用SYN Cookie后仍然持续增长，说明攻击面可能在其他端口或协议上，需要扩大检查范围。
3.4 第四步：保留证据，写清“时间线”
处理完攻击后，别忘了整理一份时间线报告。包括发现时间、流量峰值、确认依据、处置操作、每步生效时间、最终恢复时间。这不仅是为了汇报，更是为了后续复盘和优化防御规则。我通常会把netstat快照和tcpdump包一起归档，保存至少3个月，方便后续和法律团队或云厂商追溯。
4. 源码级理解与内核参数：SYN Cookies和半连接队列背后的博弈
很多人知道调tcp_syncookies可以缓解攻击，但不知道为什么。这一节我们从内核处理SYN的流程讲起，帮你建立真正的“底层直觉”。
4.1 半连接队列的“满”是怎么触发的
Linux内核为每个监听Socket维护两个队列：
SYN Queue：存放未完成握手的连接请求，由net.ipv4.tcp_max_syn_backlog控制大小；Accept Queue：存放已完成握手但等待应用accept()的连接，由net.core.somaxconn和应用程序的backlog参数共同决定。
正常流程是：收到SYN后，内核在SYN Queue里建一个request_sock结构体，发送SYN+ACK。收到客户端的ACK后，把它从SYN Queue移到Accept Queue，等待应用层调用accept()。
当SYN Queue满了之后，内核有几种策略，取决于tcp_syncookies的取值：
tcp_syncookies=0：直接丢弃新SYN，不回复SYN+ACK；tcp_syncookies=1：当SYN Queue满时，内核不建立request_sock，而是计算一个“Cookie”作为初始序列号随SYN+ACK发回。Cookie里编码了源IP、目标IP、源端口、目标端口、时间戳等关键信息。如果客户端真的能返回ACK，内核通过检查ACK里的确认号是否合法，就能还原出连接信息，进而建立连接。
Cookie看似完美，但它也有代价：每个连接都会重新计算，无法在SYN Queue中保留一些高级选项（如TCP窗口缩放、SACK），可能导致高带宽传输性能下降。所以在正常情况下，tcp_syncookies=1已经足够，但不要依赖它来解决所有问题。
4.2 内核参数调优的“正确姿势”
遇到SYN洪水时，不要盲目乱调参数。我建议按以下顺序来评估：
| 参数 | 默认值参考 | 作用与调优建议 |
|---|---|---|
net.ipv4.tcp_max_syn_backlog |
1024（视发行版而定） | 半连接队列最大值。如果正常业务并发高，可以适当调大到4096，但过大容易消耗内存，且会让攻击者更容易堆满内存，建议结合流量模型调整。 |
net.ipv4.tcp_synack_retries |
5 | 未收到ACK时重发SYN+ACK的次数。降低到1-2，可以加快失效半连接的回收，阀值过大会让带攻击特征的连接留存过久。 |
net.ipv4.tcp_syncookies |
1 | 启用SYN Cookie，建议保持开启。 |
net.ipv4.tcp_abort_on_overflow |
0 | 当accept队列满时是否直接发送RST。建议保持0，否则会中断正常客户端的重试。 |
net.core.somaxconn |
128 | 全局accept队列上限，高并发服务应调大至1024或更高。 |
net.ipv4.ip_local_port_range |
32768-60999 | 主动外连的本地端口范围，与服务做反向代理时有关，与SYN洪水直接关系不大，但要理解。 |
net.ipv4.tcp_max_tw_buckets |
180000 | TIME_WAIT数量上限，超限会销毁连接，一般不用为SYN洪水调整。 |
一个常见的“应急调参组合”：
bash复制sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=1
sysctl -w net.ipv4.tcp_syn_retries=1
注意：tcp_syn_retries是客户端主动连接时SYN重试次数，对入站洪水影响不大。调整后要观察系统日志，如果出现possible SYN flooding on port的提示，说明攻击还在继续，需要结合防火墙限速。
4.3 为什么SYN Cookie不是万能的
我在实际测试中发现，tcp_syncookies=1虽然能保证半连接队列不被打满，但如果攻击流量本身把CPU的软中断打满，处理每个包的CPU开销依然存在。攻击方只要把SYN包速率提到每秒几十万甚至上百万，即使每个包只消耗极少的CPU，整台机器的软中断也会飙升到100%，业务照样不可用。
此外，某些业务场景下，SYN Cookie和TCP Fast Open、TFO存在兼容问题。如果你启用了net.ipv4.tcp_fastopen，建议在实际攻防演练时验证兼容性，否则正常用户可能会遇到偶发的连接建立异常。说白了，内核参数只是缓解手段，真正的防线还是要在更靠近网络入口的位置完成，也就是下一节要说的边界防御。
5. 边界防御与长期加固：防火墙限速、代理缓解与监控体系
如果只是被打了才救火，那永远会很被动。聪明的做法是在攻击发生前，就把防御规则和监控指标铺好。这一节讲落地配置。
5.1 用iptables/nftables做“粗过滤”
对于单机级别的防御，iptables依然是最直接、最灵活的工具。以下几条规则建议在生产环境谨慎测试后长期启用。
限制每IP每秒新建连接数（针对SYN包）：
bash复制iptables -A INPUT -p tcp --syn -m limit --limit 20/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
这段规则的含义是：每秒最多放行20个SYN包，允许突发50个，超过的SYN包直接丢弃。缺点是比较粗糙，如果攻击源IP很多，20/s的全局限额也可能误伤正常用户，所以数字需要根据业务并发模型调整。
更精细的做法是针对单IP做hashlimit：
bash复制iptables -A INPUT -p tcp --syn -m hashlimit --hashlimit-name syn_flood --hashlimit 5/sec --hashlimit-burst 10 --hashlimit-mode srcip -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
这条规则限制每个源IP每秒最多5个SYN包，允许瞬时10个突发。对于纯静态站点或API服务，这个阈值足够正常用户使用；对于大并发场景，可以放宽到20/sec。重点在于，这能把单点扫描和典型SYN洪水的攻击源直接挡在门外。
另外，可以丢弃带异常TCP标志的包，例如同时设置SYN和FIN的包、同时设置FIN和URG或PSH的包，这类包在正常业务中极少出现，是很多扫描工具的特征：
bash复制iptables -A INPUT -p tcp --tcp-flags ALL SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
注意：如果使用nftables，语法稍有不同，但思路一致。启用前最好先抓一段正常业务流量做对比，避免误杀。
5.2 把SYN代理放在前面
除了单机防火墙，另一种常见的缓解思路是“SYN代理”。典型的实现有商业DDoS防护设备、云清洗中心，以及开源的haproxy（在TCP模式下的 tcp-request connection 规则）和linux自带的synproxy模块。
synproxy是一种更彻底的内核态方案，它由防火墙代为完成三次握手，确认客户端真实有效后，再与后端服务器建立连接。这样后端服务器看不到任何恶意半连接，攻击压力全部被SYN代理承担。启用示例（nftables）：
bash复制nft add table ip filter
nft add chain ip filter synproxy "{ type filter hook forward priority 0; }"
nft add rule ip filter synproxy tcp dport 80 ct state new,invalid counter synproxy mss 1460 wscale 7 timestamp sack-perm
我没法在这里展开全部语法，但可以负责任地说：如果公司业务对可用性要求极高，且攻击经常发生，投入资源做一层SYN代理或接入云清洗是值得的。本地调参只是“后院灭火”，代理和清洗才是“防火隔离带”。
5.3 监控报警：别等攻击打到脸上才发现
一套好用的SYN洪水监控，至少需要覆盖以下指标：
- 每分钟新增SYN包数量（来源：交换机NetFlow/sFlow 或服务器
/proc/net/netstat中的ListenDrops）； SYN_RECV状态连接数；- TCP重传率；
- 目标端口新建连接失败率。
推荐用Prometheus + node_exporter + Grafana搭建基础监控，node_exporter已经暴露了node_netstat_Tcp_*等指标。重点盯住node_netstat_Tcp_SyncookiesSent和node_netstat_Tcp_ListenDrops。这两个指标一个表示SYN Cookie生效了多少次，一个表示监听队列丢弃了多少连接，都是洪水攻击的直接信号。
报警阈值可以基于历史基线设置，例如：ListenDrops超过之前7天平均值的3倍，持续5分钟，触发告警。有了监控，你才能在攻击刚开始的几分钟内发现，而不是等用户投诉了才知道。
5.4 最容易忽略的“隐藏入口”
很多人防御SYN洪水时只盯着对外业务端口，却忽略了一些间接入口。比如：
- 办公网与服务器在同一VPC，内部扫描工具产生的异常SYN包也会影响稳定性；
- 运维堡垒机、监控采集器所在主机如果暴露了不必要的端口，也会被当作跳板；
- NTP、DNS等UDP反射放大攻击虽然不叫SYN洪水，但同样会导致链路拥塞，现场表现很像连接超时。
因此，长期加固不能只盯着TCP端口。用ss -lntp定期检查本机所有监听端口，用nmap -sS -p-在授权范围内对自己做一次“攻击者视角”的端口扫描，关闭所有不需要的端口，才是从源头减少攻击面。
6. 学习路上的几个“坑”与建议
6.1 实验环境：把“破坏”关进笼子里
想真正搞懂SYN洪水，光看书是不够的，建议搭一套隔离实验环境。我自己的方法是：用VMware或VirtualBox开三台虚拟机，一台模拟攻击者，一台模拟目标服务器，一台模拟正常客户端，所有机器放在仅主机模式的自定义网段中。
攻击模拟工具选择上，很多教程会直接推荐hping3或scapy。我建议你了解其原理，但操作时要格外谨慎：只能在你自己拥有或已获得明确授权的环境中使用。hping3的SYN洪水命令非常简单，简单到有点危险，所以我在这里不做详细展开，只说说实验设计思路。你可以用scapy构造特定源IP的SYN包，也可以直接用curl和ab模拟正常并发，这样能对比正常高并发和恶意洪水的差异。
实验过程中，我强烈建议你在服务器上同时开三个终端：一个实时执行watch -n 1 'ss -ant | grep SYN_RECV | wc -l'，一个执行top观察软中断，另一个执行tcpdump -i any tcp port 80 -nn -c 500。这样你能直观看到攻击流量打到服务器的瞬间，SYN_RECV从个位数飙升到几千，CPU的si（软中断）数值同步上升。比起任何文字描述，亲眼看到这个过程会让你记一辈子。
6.2 先学会防御，再研究原理，最后才是模拟
我给网络学习者的建议是，不要一上手就学攻击工具。先熟练使用netstat、ss、tcpdump、iptables、sysctl，能够看懂连接状态和流量特征；然后熟读tcp(7)和Linux内核关于tcp_ipv4的文档；最后再在实验环境里做模拟。顺序反了，很可能把人带偏，以为网络安全就是“打打杀杀”，实际上安全的核心是“懂原理、会防御、能复原”。
6.3 踩坑总结：我处置SYN洪水时犯过的错
最后分享几次我自己的“翻车”经历，希望你能避开。
第一次，是攻击来时我直接重启了nginx，结果半连接全部被清空，恢复后不到两分钟又被填满。重启服务会中断正常用户，却对攻击毫无影响，以后别再干这种事了。
第二次，是我把tcp_max_syn_backlog调得非常大，比如设为65535，以为能装下更多连接。结果攻击照单全收，大量半连接占用了内存，导致服务器不仅网络瘫痪，连ssh都因为内存压力变得极慢。半连接队列不是越大越好，它只决定“排队区容量”，真正决定能否扛住攻击的是你能否快速识别并丢弃恶意包。
第三次，是我在云服务器上只封了看到的那几十个IP，却忘了攻击还在不断换源。最后通过云服务商的安全组配合“全局限速+来源地区封禁”才缓解。对于超大流量攻击，本地处理永远是最后一道防线，而不是第一道防线。
6.4 关于“学习笔记”这件小事
学网络和安全，最忌讳“看过就当会了”。我自己的习惯是每次排障后，把现象、命令、输出、结论整理成一份独立笔记，包括几条命令的完整输出。因为网络问题的很多答案，不在文档里，而在真实的tcpdump包和netstat数字里。SYN洪水攻击本身并不复杂，复杂的是在真实业务场景中，如何在几十秒内判断、止损并恢复。这个过程，只能靠一次次的实操和复盘去积累。
愿这篇笔记，能让你在面对SYN洪水时，少一些我当天下午的慌张，多一分“哦，原来是它在敲门”的从容。