启用 net.ipv4.tcp_syncookies=1 是缓解超大规模 SYN-Flood 最有效的内核级手段，需同步调高 somaxconn 至 65535、将 tcp_synack_retries 设为 2，并配合 iptables 首条限速规则防御。
直接启用 net.ipv4.tcp_syncookies = 1 是缓解超大规模 SYN-Flood 的最有效内核级手段，它不分配内存、不维护状态，只在半连接队列真正溢出时启动无状态验证机制。但单设这一项远远不够——它必须在“队列先撑得住、重试快释放、应用能接住”的前提下才能持续生效。
必须设为 1，且确认已激活
该参数取值为 0（关闭）、1（自动启用）、2（强制启用）。超大规模场景下推荐固定设为 1：
- 临时启用：
sysctl -w net.ipv4.tcp_syncookies=1 - 永久生效：在
/etc/sysctl.conf中添加net.ipv4.tcp_syncookies = 1，再执行sysctl -p - 验证是否写入：
sysctl net.ipv4.tcp_syncookies应返回= 1 - 验证是否触发：攻击期间运行
netstat -s | grep -i "syncookies"，观察 Syncookies sent 计数是否增长
同步调高 somaxconn 至 65535，否则 syncookies 压根不会启动
tcp_syncookies 是兜底机制，只在 net.core.somaxconn 或 tcp_max_syn_backlog 队列溢出时才介入。若两者仍为默认 128 或 1024，攻击流量几秒就打满队列并被静默丢弃，根本触不到 cookie 逻辑。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 设为
net.core.somaxconn = 65535（同时约束全连接队列，也提升 accept 效率） - 该值必须 ≥ 应用层
listen()调用的 backlog 参数，否则会被截断 - Nginx 需配
listen 80 backlog=65535；Tomcat 在server.xml中设acceptCount="65535"；Node.js 启动时传入backlog=65535 - 改完需重载服务（如
systemctl reload nginx），否则监听套接字仍用旧值
把 tcp_synack_retries 降到 2，让无效连接秒级释放
默认值 5 意味着服务器最多等待约 63 秒才放弃一个伪造连接（重试间隔：1s, 3s, 7s, 15s, 31s）。攻击者正是靠这个“长等待”卡死队列。设为 2 后，总等待压缩至约 1–3 秒，显著降低 ss -s 中 synrecv 的峰值。
- 配置
net.ipv4.tcp_synack_retries = 2 - 切勿设为 0：首次 SYN+ACK 发送失败即丢弃，会误伤云厂商 LB、NAT 网关后的真实用户
- 该参数仅影响服务端行为，
tcp_syn_retries是客户端参数，服务器上修改无效
配套 iptables 限速，减轻内核协议栈压力
syncookies 是内核层兜底，iptables 是网络层第一道过滤网。规则必须放在 INPUT 链最前，否则大量伪造包会穿透到 TCP 栈，白白消耗 CPU。
- 插入首条规则：
iptables -I INPUT -p tcp --syn -m limit --limit 50/s --limit-burst 10 -j ACCEPT - 后续丢弃所有未匹配的 SYN：
iptables -A INPUT -p tcp --syn -j DROP -
--limit-burst 10是信用池，允许突发；50/s需按业务正常峰值微调（API 服务可压至 20/s） - 避免使用
recent模块封 IP：高并发下性能差，且 NAT 后易误伤
