somaxconn调小会导致连接拒绝或延迟，因其限制已完成三次握手、等待accept()的全连接队列长度，超限则新连接被内核丢弃，引发客户端超时或connection refused。
为什么 somaxconn 调小会导致连接拒绝或延迟？
当客户端发起 SYN 请求，服务端完成三次握手前，连接会暂存在两个队列中：半连接队列（syn_queue）和全连接队列（accept_queue）。somaxconn 控制的就是后者——即 listen() 系统调用指定的 backlog 参数上限与内核全局最大值二者中的较小者。若实际并发连接建立速度超过该值，新连接会被内核直接丢弃（不发 RST），表现为客户端超时、Connection refused 或 Connection timeout，尤其在短连接高并发（如 HTTP API、健康检查探测）场景下非常明显。
如何安全地修改 somaxconn 值？
修改需分三步，缺一不可，且顺序不能错：
- 临时生效（重启后失效）：
sudo sysctl -w net.core.somaxconn=65535 - 写入配置文件持久化：
echo 'net.core.somaxconn = 65535' | sudo tee -a /etc/sysctl.conf，再执行sudo sysctl -p加载 - 关键遗漏点：应用层
listen()的backlog参数必须 ≤ 内核值，否则仍被截断。例如 Nginx 默认用511，Go 的net.Listen("tcp", addr)默认是SOMAXCONN（即内核值），但某些旧版 Java Netty 或自定义 C 服务可能硬编码为128或1024，必须同步改大
somaxconn 和 net.ipv4.tcp_max_syn_backlog 有什么区别？
两者常被混淆，但作用对象完全不同：
-
net.core.somaxconn：限制已完成三次握手、等待accept()的连接数（全连接队列） -
net.ipv4.tcp_max_syn_backlog：限制收到SYN但尚未完成三次握手的连接数（半连接队列），仅在net.ipv4.tcp_syncookies = 0时生效；现代系统通常开启 syncookies（默认为1），此时该参数基本不起作用 - 真正影响半连接抗压能力的是
net.ipv4.tcp_syncookies是否启用，而非tcp_max_syn_backlog
修改后需要验证和监控什么？
别只看设置成功了就完事，得确认是否真起效：
- 查当前值：
sysctl net.core.somaxconn或cat /proc/sys/net/core/somaxconn - 查某进程监听套接字的实际队列长度：
ss -lnt输出中Recv-Q列显示当前全连接队列积压数，若长期接近或等于somaxconn值，说明仍不够用 - 观察内核丢包：
netstat -s | grep -i "listen overflows"，出现非零值（如listen overflows: 12）即代表已发生队列溢出丢弃 - 注意：调得过大（如 > 65535）对大多数服务无益，反而增加内存占用；建议从
4096起步，按压测结果逐步上调
最易被忽略的是应用层 backlog 参数未同步更新，以及误以为调大 tcp_max_syn_backlog 就能缓解全连接堆积——它根本不管 accept() 队列的事。
