将 net.ipv4.tcp_synack_retries 设为 0 是关键止损点，可使半连接存活时间从180秒降至3秒内、队列周转率提升两个数量级，但必须配合 tcp_syncookies=1 使用，否则会导致弱网客户端连接失败。
直接启用 net.ipv4.tcp_syncookies = 1 并调小 net.ipv4.tcp_synack_retries 到 0，是当前最有效、副作用最小的应急手段。其他参数调整必须配合业务场景验证，盲目增大队列反而可能加速资源耗尽。
为什么 tcp_synack_retries = 0 是关键止损点
默认值 5 意味着每个伪造 SYN 包会触发最多 5 轮重发 SYN+ACK，每轮间隔约 1 秒，半连接在队列中平均滞留超 60 秒。攻击者用几百个 IP 就能填满队列，导致正常连接被丢弃甚至 SSH 失联。
设为 0 后，内核收到 SYN 就发一次 SYN+ACK，收不到 ACK 立即释放该条目——实测半连接存活时间从 180 秒降至 3 秒以内，队列周转率提升两个数量级。
- 必须搭配
tcp_syncookies = 1使用，否则设为 0 可能导致合法弱网客户端（如高丢包率移动网络）连接失败 - 不建议设为
1或2：仍存在重传开销，且无法规避队列占满问题 - 修改后立即生效：
sysctl -w net.ipv4.tcp_synack_retries=0
tcp_max_syn_backlog 和 somaxconn 不是越大越好
这两个参数分别控制半连接队列和全连接队列上限。盲目设成 65535 会显著增加内存占用，且若应用层 listen() 的 backlog 参数没同步调大，实际生效值仍是 min(内核值, 应用值)。
真实瓶颈往往不在队列长度，而在内核处理每个 SYN 包的 CPU 开销。过大的队列只是把压力从“连接拒绝”转移到“CPU 打满”。
- 观察当前压力：
ss -s | grep "synrecv"查看半连接数；netstat -s | grep -i "listen\|overflow"查TcpExtListenOverflows计数 - 合理起点：将
tcp_max_syn_backlog设为4096，somaxconn设为8192，再根据TcpExtListenOverflows是否持续增长决定是否上调 - Java 应用需检查
ServerSocket(int port, int backlog)构造器传入值；Nginx 需确认listen 80 backlog=8192配置已写入
tcp_tw_reuse 可以开，但 tcp_tw_recycle 必须关
tcp_tw_reuse = 1 允许内核将处于 TIME-WAIT 状态的端口快速复用于新连接（仅限客户端主动发起的连接），对缓解端口耗尽有帮助，但前提是 net.ipv4.tcp_timestamps = 1 已启用。
tcp_tw_recycle 在 Linux 4.12+ 内核中已被彻底移除，旧版本（如 CentOS 7 默认内核）若开启，会在 NAT 环境下造成大量连接失败——它依赖 TCP 时间戳做“唯一性校验”，而 NAT 设备后多个客户端的时间戳可能冲突，导致 ACK 被静默丢弃。
- 检查状态：
sysctl net.ipv4.tcp_tw_recycle输出应为0 - 如需复用 TIME-WAIT 端口，只开
tcp_tw_reuse，并确保tcp_timestamps为1（现代内核默认开启） - 更稳妥的做法是扩大本地端口范围：
net.ipv4.ip_local_port_range = 10000 65535
iptables 限速必须配合内核参数，不能单独依赖
单纯用 iptables -A INPUT -p tcp --syn -m limit --limit 10/sec -j DROP 会引入额外匹配开销，且无法区分真实用户与伪造 IP。它应在内核参数调优基础上作为第二道防线，而非替代方案。
规则位置很关键：必须放在所有 ACCEPT 规则之前，且优先匹配 ESTABLISHED 连接（避免干扰已有流量）。另外，--limit-burst 值不宜过小，否则突发合法请求（如 CDN 回源）也会被误杀。
- 推荐组合：
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT放最前 - 再加限速规则，
--limit-burst至少设为30，给短时峰值留余量 - 注意：云厂商 SLB 或 WAF 后的服务器，源 IP 可能全是内网地址，此时 iptables 限速失效，应交由上层设备处理
真正容易被忽略的是：SYN Flood 防御效果高度依赖攻击流量特征。如果攻击包 TTL 异常低、IP ID 无规律、TCP 选项字段混乱，说明攻击者在模拟真实协议栈——此时单靠内核参数已不够，必须结合 netfilter 模块（如 xt_psd）或用户态流量清洗工具做深度识别。不要以为调完几个 sysctl 就一劳永逸。
