如何通过调优内核 tcp_max_syn_backlog 抵御静态服务的恶意建连-Nginx-PHP中文网

只调tcp_max_syn_backlog基本没用，因其实际生效值为min(tcp_max_syn_backlog, somaxconn)，且在tcp_syncookies=1时完全不生效；真正有效的是协同调整somaxconn、应用层listen backlog和syncookies策略。

如何通过调优内核 tcp_max_syn_backlog 抵御静态服务的恶意建连

直接调优 tcp_max_syn_backlog 本身并不能有效抵御针对静态服务（如 Nginx 静态文件服务器、CDN 边缘节点、轻量 API 网关）的恶意建连，因为该参数在现代 Linux 发行版中常被其他机制截断或绕过。关键不是单独堆高它，而是理解它在哪起作用、在哪失效，并配合真实生效的环节协同防御。

tcp_max_syn_backlog 在静态服务场景下的真实角色

它只控制内核半连接队列（SYN_RECV 队列）的理论容量上限，但实际可用长度 = min(tcp_max_syn_backlog, somaxconn)
若 tcp_syncookies = 1（绝大多数发行版默认开启），该参数完全不参与排队逻辑：内核跳过队列，直接用加密 cookie 响应 SYN，tcp_max_syn_backlog 仅剩“备用缓冲”意义
静态服务通常使用高性能 Web 服务器（如 Nginx、Caddy），其 listen() 调用默认 backlog 很小（Nginx 默认 511），若 somaxconn 未同步调大，tcp_max_syn_backlog 再高也无用

必须同步调整的三个硬性依赖项

net.core.somaxconn
- 必须 ≥ 应用层 listen(fd, backlog) 的传入值
- Nginx 默认为 511，建议统一设为 65535，避免被截断
- 修改后需 systemctl reload nginx 或重启进程，否则监听 socket 不重载新队列大小
net.ipv4.tcp_syncookies
- 设为 1（永久启用），这是静态服务抗恶意建连的核心兜底
- 启用后，伪造 IP 的 SYN 不再占用内存，也不进队列，直接发带 cookie 的 SYN+ACK
- 现代内核（≥3.7）支持时间戳和 SACK，不影响正常 HTTP/HTTPS 功能
应用层 listen backlog 设置
- Nginx 用户检查 listen 80 backlog=65535;（需 1.15.9+ 支持）
- Caddy 或自研服务需确认代码中 listen() 第二个参数是否硬编码为 128 或 1024，否则内核上限再高也白搭

对静态服务更有效的替代或补充手段

降低 net.ipv4.tcp_synack_retries 至 2
- 默认 5 意味着每个伪造连接占位约 31 秒；设为 2 后最长仅约 1.5 秒
- 减少队列中“僵尸条目”，提升周转率，对真实弱网用户影响极小
配合 iptables 限速（比纯内核调优更前置）
- iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
  （单 IP 并发 SYN > 3 个即丢，适合静态资源访问特征）
- iptables -A INPUT -p tcp --syn -m limit --limit 5/sec --limit-burst 10 -j ACCEPT
  （全局每秒最多响应 5 个新 SYN，防突发扫段）
监控是否真在丢半连接（而非误判）
- 查 SynsToListenDrops（半连接溢出）：
```
awk '/^TcpExt/ {print $1,$2}' /proc/net/snmp | grep SynsToListenDrops
```
- 若该值不涨，但 SynsToListenIgnored 上升 → 表明 syncookies 正常接管，属预期行为

不复杂但容易忽略：tcp_max_syn_backlog 只有在 tcp_syncookies = 0 且 somaxconn 足够大、应用 backlog 匹配时才真正起队列扩容作用；对绝大多数已启用 syncookies 的静态服务，它只是个“心理安慰参数”。真正起效的是三者协同 + 网络层过滤。