调大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
真正卡点往往不在内核参数，而在应用层吞吐能力。参数只是把门开宽，人得走得快才行。
