调大tcp_max_syn_backlog无效主因是SYN包未达协议栈或syncookies启用；需检查iptables限速、网卡丢包、云防护策略，关闭syncookies并调大somaxconn和应用listen backlog，同时监控TIME-WAIT堆积。
调大 net.ipv4.tcp_max_syn_backlog 后 SYN 洪水攻击效果仍不明显，往往不是参数没生效，而是它只是整个 TCP 连接建立链路中的一环——真正卡住攻击流量的，常在它前面或后面。
SYN 队列根本没被填满，攻击流量早被拦截了
这个参数控制的是“未完成连接队列”（SYN queue）最大长度，但前提是 SYN 包得先到达内核协议栈。现实中，很多环境在这一层之前就做了限制：
- iptables/nftables 的 connlimit 或 hashlimit 规则：比如对单 IP 限速 10 个新建连接/秒，SYN 包根本进不到 TCP 层；
-
网卡硬件 offload 或驱动层丢包：某些网卡在高并发小包场景下自动丢弃部分 SYN（尤其无 checksum 或 malformed 包），dmesg 可能出现
rx_queue_overflow； - 云厂商或防火墙的默认防护策略：如 AWS Security Group、阿里云安骑士、腾讯云 DDoS 基础防护，会在四层负载均衡或网关侧主动限速或重置异常 SYN 流量。
系统启用了 syncookies，绕过了 backlog 队列
当 net.ipv4.tcp_syncookies = 1（默认开启），内核在 SYN queue 溢出时会启用 syncookie 机制：不保存半连接状态，而是用加密 cookie 编码客户端信息，直接发 SYN+ACK。攻击者发多少 SYN，内核就回多少 SYN+ACK，看起来“扛住了”，实际已脱离 backlog 控制逻辑。
验证方式：
cat /proc/sys/net/ipv4/tcp_syncookies —— 若为 1，且 ss -s | grep "SYN-RECV" 数值长期很低，大概率 syncookie 在起作用。
若需真实测试 backlog 效果，可临时关闭：
sysctl -w net.ipv4.tcp_syncookies=0（注意：生产环境慎用，会降低抗洪能力）。
应用层 accept 队列（backlog 参数）成了新瓶颈
即使内核 SYN 队列撑住了，后续还有“已完成连接队列”（accept queue），由 listen() 系统调用的 backlog 参数和 net.core.somaxconn 共同限制。若应用调用 accept() 太慢（如阻塞处理、线程不足、全连接队列满），新连接会被丢弃，表现为客户端超时，而非 SYN 超时。
- 检查当前 accept 队列使用：
ss -lnt | grep :端口 —— 第三列是recv-q（当前等待 accept 的连接数），若持续接近第二列send-q（即 somaxconn 或 listen backlog 最小值），说明此处已堵住； - 增大该瓶颈：
sysctl -w net.core.somaxconn=65535，并确保应用listen(fd, 65535)显式传入足够大的值（glibc 2.2+ 默认截断为 somaxconn）。
TIME-WAIT 连接大量堆积，挤占本地端口和内存资源
在短连接高频场景下，SYN 洪水虽被挡下，但若攻击后紧接大量正常（或伪造）FIN，会导致本机快速进入 TIME-WAIT。这会：
- 耗尽
net.ipv4.ip_local_port_range指定的可用端口，新连接无法发起（对客户端）； - 占用内存（每个 TIME-WAIT 占约 320 字节），触发
net.ipv4.tcp_max_tw_buckets限制后，内核开始强制回收，可能误杀合法连接； - 间接影响 SYN 处理效率：极端情况下，内核忙于维护海量 TIME-WAIT 条目，响应变慢。
排查命令：
ss -ant state time-wait | wc -l
netstat -s | grep -i "time wait"
