Linux系统级somaxconn参数需同步调整net.ipv4.tcp_max_syn_backlog和应用层listen() backlog，并启用tcp_syncookies；临时改用sysctl -w，永久写入/etc/sysctl.conf后执行sysctl -p生效。
Linux系统级somaxconn参数怎么改
系统级TCP连接队列上限由/proc/sys/net/core/somaxconn控制，它决定了listen()能接受的最大未完成连接数（即SYN队列+已完成连接队列的总和上限）。默认值通常为128或4096，远低于高并发服务需求。
临时修改（重启失效）：sudo sysctl -w net.core.somaxconn=65535
永久生效需写入/etc/sysctl.conf：echo 'net.core.somaxconn = 65535' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
常见坑：
- 修改后不执行sysctl -p或sysctl --system，配置不会加载
- 容器环境（如Docker）中，宿主机改了，容器内仍读取自己的namespaced值，需在docker run时加--sysctl net.core.somaxconn=65535
- Kubernetes Pod需通过securityContext.sysctls显式设置，否则被忽略
C++ listen()里的backlog参数到底传多少
backlog是listen()函数的第二个参数，它**不是硬性队列长度**，而是内核用于初始化连接队列的**提示值**。实际生效值受三者限制：min(backlog, 系统somaxconn, 内核编译上限SOMAXCONN)。
实操建议：
- 不要传0或负数（行为未定义，glibc可能截断为0）
- 明确传一个合理值，比如65535，而非依赖默认的SOMAXCONN（老内核可能是128）
- C++代码中应检查listen(sockfd, backlog)返回值，失败时errno可能是EINVAL（说明backlog被内核拒绝）
示例片段：
int backlog = 65535;<br>if (listen(sockfd, backlog) == -1) {<br> if (errno == EINVAL) {<br> // 可能是somaxconn太小，或内核限制<br> }<br>}
为什么设置了somaxconn和backlog还是丢连接
即使两者都调大，仍可能看到ss -s里synrecv堆积、客户端报Connection refused或超时，原因常不在队列本身：
- 应用没及时accept()：队列满了只是表象，根本原因是应用层处理不过来，CPU打满或阻塞在IO上
- SYN Cookie未启用：当net.ipv4.tcp_syncookies=0且SYN队列溢出时，直接丢包；建议设为1（仅对未完成连接启用）或2（始终启用）
- 连接跟踪（conntrack）满：尤其在NAT或防火墙场景，nf_conntrack_count达到nf_conntrack_max也会静默丢包
- net.core.netdev_max_backlog过小：网卡收包软中断队列溢出，导致底层就收不到SYN包
验证当前生效的队列长度
不能只看sysctl net.core.somaxconn，还要确认运行时实际值：
- 查看某监听socket的实际队列大小（需root）：ss -lnt输出中Recv-Q列显示当前已完成连接数，Send-Q列显示该socket允许的最大连接队列长度（即生效的backlog值）
例如：LISTEN 0 65535 *:8080 *:* 表示Send-Q=65535已生效
- 检查是否被内核截断：cat /proc/net/netstat | grep -i "ListenOverflows\|ListenDrops"，非零说明队列确实溢出了
- 抓包确认SYN是否被RST：用tcpdump -n port 8080 and 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'，若看到服务端发RST给SYN，大概率是队列满且syncookies关了
真正起作用的是somaxconn、backlog、内核编译上限三者的最小值，而且accept()速度才是最终瓶颈——参数调得再大，线程卡在日志IO里也白搭。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
