syn flood 攻击无法完全阻止但可大幅降低影响，核心是启用 tcp_syncookies、iptables 限速和调低 tcp_synack_retries。tcp_syncookies 使内核用加密哈希生成 syn+ack 序列号，仅完成三次握手才分配资源；iptables 自定义链限制每秒 syn 包数量；tcp_synack_retries 建议设为 2 或 3 以缩短重试等待时间。
SYN Flood 攻击无法完全阻止，但能大幅降低影响——关键在于让服务器不为伪造连接分配资源，同时快速识别并丢弃异常流量。
启用 tcp_syncookies 是最有效内核级防护
这个参数开启后，内核不再为每个 SYN 请求在内存中保存半连接状态，而是用加密哈希生成一个 SYN+ACK 序列号（即 cookie）。只有客户端真正完成三次握手、返回带正确 ACK 的包时，内核才分配 socket 资源。
- 临时启用：
sysctl -w net.ipv4.tcp_syncookies=1 - 永久生效：在
/etc/sysctl.conf中添加net.ipv4.tcp_syncookies = 1，再执行sysctl -p - 注意：
tcp_syncookies=1会禁用SACK（选择性确认），在高丢包链路（如弱 Wi-Fi 或跨境线路）下可能略微降低吞吐，但对绝大多数 Web/HTTP 服务无感 - 它和
tcp_tw_reuse不冲突，可共存；但一旦启用，tcp_max_syn_backlog就被忽略——别再指望靠调大它来“硬扛”
用 iptables 做前置限速，成本低见效快
内核层兜底，iptables 层做第一道过滤。重点不是封死所有高频 IP，而是把“每秒发几十个 SYN 包却从不完成握手”的行为拦在进内核前。
- 推荐组合（新建自定义链）：
iptables -N syn-floodiptables -A INPUT -p tcp --syn -j syn-floodiptables -A syn-flood -m limit --limit 50/s --limit-burst 10 -j RETURNiptables -A syn-flood -j DROP -
--limit-burst 10是“信用池”，允许突发 10 个包；之后严格按50/s放行。数值需根据业务正常峰值微调（比如小 API 服务可设为20/s） - 避免直接用
recent模块封 IP（如--hitcount 30），它在高并发下有性能开销，且容易误伤 NAT 后的合法用户 - 这条规则必须放在
INPUT链靠前位置，否则可能被其他规则（如已建立连接放行）绕过
tcp_synack_retries 要调低，但别设为 0
这是服务器发完 SYN+ACK 后，等待客户端 ACK 的重试次数。默认是 5，意味着最多等约 63 秒（指数退避：1s, 3s, 7s, 15s, 31s）。攻击者就卡在这里耗资源。
- 建议设为
2或3：sysctl -w net.ipv4.tcp_synack_retries=2 - 设为
0会导致首次SYN+ACK发送失败即丢弃连接，在部分网络路径不稳的场景（如某些云厂商 LB 后）反而增加建连失败率 -
tcp_syn_retries是客户端参数，服务器上改它没意义，不用碰 - 调整后可通过
ss -s观察synrecv数量是否明显下降
真正难处理的是混合型攻击：SYN Flood + 真实慢速 HTTP 连接 + 随机 User-Agent 扫描。这时候单靠内核参数和 iptables 不够，得配合前端 WAF 或负载均衡器做连接清洗——但那是另一层的事了。先确保这三步调好，90% 的基础 SYN Flood 就不会让你的 netstat -s | grep "SYNs to LISTEN sockets" 每秒跳几百次。
