必须开启net.ipv4.tcp_syncookies=1并同步调大tcp_max_syn_backlog和somaxconn，缩短synack_retries至2，配合iptables前置限速规则，才能使syncookies真正生效。
必须开启 net.ipv4.tcp_syncookies=1，但光开这个没用——它只在半连接队列真正溢出时才触发，而默认队列太小（常为 1024），攻击一来就直接丢包，根本轮不到 syncookies 生效。
确认当前状态和是否真被调用
别只看参数值，得验证它是不是在干活：
-
sysctl net.ipv4.tcp_syncookies返回1只说明已启用，不等于正在工作 - 运行
netstat -s | grep -i "syncookies"，观察Syncookies sent计数是否随流量增长；为 0 说明队列还没满，或规则被 iptables 提前拦了 - 检查半连接队列是否真溢出：
ss -s看SYNs行的incomplete数，持续 >net.ipv4.tcp_max_syn_backlog值才是 syncookies 触发条件
同步调大两个关键队列上限
syncookies 是“保命机制”，不是“防攻击开关”。它需要先让系统撑到溢出那一刻，才有机会出手：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
net.ipv4.tcp_max_syn_backlog：半连接队列大小，建议设为4096～65535；低于2048在高并发下基本形同虚设 -
net.core.somaxconn：全连接队列上限，必须 ≥ 应用层listen()的backlog参数；Nginx 要配listen 80 backlog=65535，Node.js 启动时显式传65535，Golang 默认适配但需确认未被ulimit -n或容器限制压制 - 改完必须 reload 服务（如
systemctl reload nginx），否则新值对应用无效
缩短 tcp_synack_retries 加速释放无效连接
默认值 5 意味着服务器最长等约 63 秒才放弃一个伪造 SYN+ACK，这等于给攻击者送资源窗口：
- 设为
2：总等待时间压缩至约 1–3 秒，大幅降低队列积压压力 - 设为
0会禁用重传，导致真实弱网用户（如跨境、云厂商 LB 后端）建连失败，不推荐 - 该参数不影响正常三次握手，只压缩无效连接的存活时间
iptables 必须前置限速，不能依赖 syncookies 单打独斗
syncookies 是内核兜底，iptables 是第一道过滤网。把高频异常 SYN 包拦在进协议栈前，才能避免内核被打满：
- 规则必须放在
INPUT链靠前位置（早于-m state --state ESTABLISHED类放行规则），否则会被绕过 - 推荐组合：
iptables -A INPUT -p tcp --syn -m limit --limit 10/sec --limit-burst 20 -j ACCEPT，之后紧跟iptables -A INPUT -p tcp --syn -j DROP - 不要用
recent模块做高频封禁——高并发下性能差；改用ipset + fail2ban动态管理封禁 IP
最容易被忽略的是：应用层 listen() 的 backlog 值和 net.core.somaxconn 不匹配，或者改完内核参数没 reload 服务。这时候你看到的不是防护生效，而是连接失败率突然上升——误以为 syncookies 失效，其实是它根本没机会启动。
