tcp_max_syn_backlog 调大后 backlog full 的 net.core.somaxconn 同步调整

调大tcp_max_syn_backlog后仍丢SYN，是因为全连接队列（由net.core.somaxconn决定）瓶颈未解决；两者不匹配或应用listen()参数被截断会导致新连接在入全连接队列时被丢弃。

tcp_max_syn_backlog 调大后为什么还会丢 SYN？

因为 tcp_max_syn_backlog 只控制「半连接队列」长度，而真正决定 accept() 能否及时取走连接的，是「全连接队列」上限——它由 net.core.somaxconn 决定。两者不匹配时，即使半连接队列扩容了，新连接仍会在进入全连接队列时被内核丢弃（日志里出现 "TCP: drop open request from ..." 或 "possible SYN flooding"）。

怎样确认两个参数是否匹配？

用以下命令查当前值：

sysctl net.ipv4.tcp_max_syn_backlog net.core.somaxconn

再检查应用监听时传入的 backlog 参数（如 python 的 socket.listen(128)），它会被内核截断为 min(backlog, somaxconn)。常见问题包括：

• tcp_max_syn_backlog 设为 65535，但 somaxconn 还是默认的 128
• 应用代码里 listen() 传了 1024，但 somaxconn 是 512 → 实际生效的是 512
• 容器环境里只改了宿主机 somaxconn，但容器未继承或被 cgroup 限制

调参顺序和推荐值怎么设？

必须先调 net.core.somaxconn，再调 tcp_max_syn_backlog，且后者建议 ≥ 前者 × 2（留出半连接缓冲空间）。例如：

sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=131072

注意：

• 修改后需重启监听服务（或让其重新 bind/listen），否则旧 socket 仍用老值
• 某些发行版（如较新 centos/RHEL）默认启用 net.ipv4.tcp_abort_on_overflow=0，此时队列满不会发 RST，而是丢包+重传，更难排查
• 云环境（如 AWS EC2）可能有底层连接数限制，调高内核参数未必能突破实例规格上限

怎么验证调整生效了？

用 ss -lnt 看 Recv-Q 是否长期接近或等于 somaxconn 值；再用 netstat -s | grep -i "listen overflows" 查是否有溢出计数增长。如果仍有溢出，重点看应用是否：

• accept() 调用太慢（比如阻塞在磁盘 I/O 或锁上）
• 单线程 accept + 处理，无法应对突发连接
• 用了 Event loop（如 nginx、node.js），但 worker 数不足或配置了过小的 listen backlog

真正卡点往往不在内核参数，而在应用层吞吐能力。参数只是把门开宽，人得走得快才行。