net.ipv4.tcp_max_syn_backlog 调大后仍然 SYN 洪水效果不明显的隐藏原因

调大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”