必须同步调大net.ipv4.tcp_max_syn_backlog和net.core.somaxconn，二者取小值作为半连接队列实际上限，且需匹配应用层listen()的backlog参数，否则调优无效；还需验证SynsToListenDrops是否增长以确认是否真丢包。
直接调大 net.ipv4.tcp_max_syn_backlog 本身不能单独缓解半连接攻击，它必须和 net.core.somaxconn 同步调整，并配合应用层配置与行为观察，否则参数修改无效、队列依然溢出。
必须同步调高两个关键参数
Linux 内核在创建监听 socket 时，会取 tcp_max_syn_backlog 和 somaxconn 的较小值作为半连接队列实际上限。默认值（常为 128 或 1024）在突发流量下几秒即满。
- net.ipv4.tcp_max_syn_backlog：控制每个监听端口的半连接队列长度。建议设为 4096～65535，具体取决于每秒 SYN 到达峰值（例如 300 SYN/s 可设为 600～1000）
- net.core.somaxconn：不仅限制全连接队列（accept queue），也隐式截断半连接队列。必须 ≥ 前者，生产环境推荐统一设为 65535
- 执行命令示例：
sysctl -w net.ipv4.tcp_max_syn_backlog=65535sysctl -w net.core.somaxconn=65535
永久生效需写入/etc/sysctl.conf并运行sysctl -p
检查并匹配应用 listen() 的 backlog 参数
即使内核参数调得再大，如果应用代码中调用 listen(fd, 128) 硬编码了小值，最终生效的仍是 128 —— 内核不会突破这个上限。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- Nginx 默认使用
listen ... backlog=511，可通过配置显式增大，如listen 80 backlog=65535 - Node.js、Python（如 Flask + Gunicorn）、Java（如 Tomcat）等需确认其启动参数或框架配置是否限制了 backlog
- 容器环境（如 Docker）需额外透传：
docker run --sysctl net.core.somaxconn=65535 ...
验证是否真在丢弃 SYN 包
别只看 “ListenOverflows”，那是全连接队列溢出；半连接队列溢出对应的是 SYNs to LISTEN sockets dropped。
- 实时查看指标：
awk '/^TcpExt/ {print $1,$2}' /proc/net/snmp | grep SynsToListen
若SynsToListenDrops持续增长，说明队列已满丢包 - 检查当前半连接数量：
ss -n state syn-recv | wc -l
对比cat /proc/sys/net/ipv4/tcp_max_syn_backlog，若接近或达到该值，即存在瓶颈 - 抓包辅助判断：
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0 and dst port 80'
观察是否有大量 SYN 进来但无对应 SYN+ACK 返回
配合其他策略提升抗压能力
单纯扩容队列是基础，但面对真实攻击还需叠加响应机制：
-
降低重试次数：设
net.ipv4.tcp_synack_retries = 2，避免无效连接长期占位（默认 5 次，最长等待约 31 秒） -
按需启用 SYN Cookie：当无法预估峰值或需兜底保障时，设
net.ipv4.tcp_syncookies = 1；但注意它会禁用 SACK、时间戳等 TCP 特性，且部分云网络设备可能干扰流程 -
前置防护更有效：在负载均衡或防火墙层限速（如 iptables 的
--limit 100/sec）、封禁异常源 IP，比纯内核调优成本更低、效果更稳
