调大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（留出半连接缓冲空间）。例如：
