调大 net.core.somaxconn 能提升静态服务并发连接能力，但必须同步设置应用层 listen backlog 参数，否则无效；还需协同调整 tcp_max_syn_backlog、netdev_max_backlog 和 file-max 等参数。
直接调大 net.core.somaxconn 能显著提升静态服务（如 Nginx、Caddy、OpenResty）应对突发连接的能力，但必须同步调整应用层配置，否则内核参数形同虚设。
为什么 somaxconn 是关键瓶颈
静态服务通常不涉及复杂业务逻辑，CPU 和内存压力低，但突发流量下极易出现“Connection refused”或连接延迟升高。根本原因不是资源耗尽，而是已完成三次握手的连接在内核队列中堆积后被丢弃——这个队列上限就由 net.core.somaxconn 控制。
默认值 128 意味着：哪怕服务器空闲，每秒也只能排队接收最多 128 个已建立的连接；超出部分客户端收到 RST 包，表现为连接拒绝。
必须同步修改应用层 backlog
内核不会无条件按 somaxconn 执行。应用调用 listen() 时传入的 backlog 值，会与 somaxconn 取较小者作为实际队列长度。常见误区：
- Nginx 默认 backlog=511，即使你把 somaxconn 设为 65535，实际仍卡在 511
- 需在
listen指令中显式声明：listen 80 backlog=65535; - Caddy v2+ 默认读取系统 somaxconn，无需额外配置，但需确认版本 ≥2.6
- OpenResty（基于 Nginx）同样依赖
listen ... backlog=显式设置
验证是否真正生效
改完别急着压测，先确认队列长度已更新：
- 执行
ss -ltn | grep ':80'（替换为你的端口），观察 Send-Q 列是否为 65535 - 若仍是 128 或 511，说明 Nginx 配置未重载，或未加
backlog=参数 - 检查
nginx -t && nginx -s reload是否成功，避免配置语法错误导致回退到默认值
配套必须调整的三个参数
单调 somaxconn 不足以应对真实突发场景，还需协同优化：
- net.ipv4.tcp_max_syn_backlog = 65535：防止半连接（SYN_RECV）堆积，避免触发 SYN cookies 开销
- net.core.netdev_max_backlog = 10000：网卡软中断收包队列，匹配高 PPS 流量节奏
-
fs.file-max = 2097152 及用户级 limits（
* soft nofile 1048576）：确保足够文件描述符支撑海量连接
所有参数写入 /etc/sysctl.conf 后运行 sysctl -p 生效，无需重启系统。
