启用 tcp_syncookies=1 是缓解 SYN-Flood 攻击最直接、开销最低的内核级手段，仅在半连接队列溢出时自动触发，兼容时间戳与 SACK，且使 tcp_max_syn_backlog 失效；需配合 tcp_synack_retries=2（非0）以快速释放无效连接，并通过 netstat -s 与 dmesg 验证实际生效。
启用 tcp_syncookies = 1 是缓解 SYN-Flood 攻击最直接、开销最低的内核级手段，但它不是“一开就万事大吉”的开关，而是一个需要精准配合的兜底机制。
为什么必须设为 1，而不是 0 或 2
设为 0 表示完全关闭，失去保命能力；设为 2 是强制无条件启用 SYN Cookies，会禁用 TCP 时间戳和 SACK 等关键扩展，在高丢包链路（如跨境、移动网络）下可能影响正常连接质量。现代内核（≥3.7）已支持带时间戳的 SYN Cookies，设为 1 即可实现“仅在半连接队列溢出时自动触发”，安全且兼容性最佳。
- 临时生效：sysctl -w net.ipv4.tcp_syncookies=1
- 永久生效：在 /etc/sysctl.conf 中添加 net.ipv4.tcp_syncookies = 1，再运行 sysctl -p
- 验证是否生效：sysctl net.ipv4.tcp_syncookies 应返回 = 1
tcp_syncookies=1 启用后，tcp_max_syn_backlog 就失效了
这是常被忽略的关键点：一旦启用 tcp_syncookies=1，内核将绕过半连接队列管理逻辑，tcp_max_syn_backlog 的值会被忽略，再调大它毫无意义。此时队列不再靠内存缓冲，而是靠加密序列号隐式建链。所以不要把精力浪费在堆高这个参数上，重点应转向加速无效连接释放和前置过滤。
必须搭配 tcp_synack_retries 调低才能见效
默认值 5 意味着服务器最长要等约 63 秒才放弃一个伪造连接（重试间隔为 1s、3s、7s、15s、31s），攻击者正是利用这个等待窗口持续耗尽资源。设为 2 后，总等待压缩至约 1–3 秒，能快速清空无效状态，显著降低 ss -s | grep synrecv 的峰值。
- 推荐配置：net.ipv4.tcp_synack_retries = 2
- 切勿设为 0：会导致首次 SYN+ACK 丢失即断连，云厂商 LB、NAT 网关后的真实用户易受影响
- 该参数只影响服务端行为，改 tcp_syn_retries 对防御无帮助
验证它是否真在起作用
光看参数写入不等于实际生效。需结合两个指标观察：
- 运行 netstat -s | grep -i "syncookies"，确认 Syncookies sent 计数随攻击流量上升
- 同时检查 dmesg 是否仍有 "Possible SYN flooding" 提示；若持续出现，说明队列仍频繁溢出，需排查 iptables 是否漏放或应用层 backlog 是否过小
