要让Nginx真正接纳高并发连接，net.core.somaxconn与Nginx listen backlog必须协同调优，共同决定“已完成三次握手、等待accept取走”的全连接队列实际容量；默认128极易溢出致连接被内核静默丢弃，推荐均设为65535并同步调优tcp_max_syn_backlog、文件描述符等配套参数。
要让 Nginx 真正接纳住高并发连接，net.core.somaxconn 和 Nginx 的 listen backlog 必须协同调优——它们共同决定了“已完成三次握手、但还没被 accept 取走”的连接队列实际容量。这个队列一旦溢出，新连接会被内核静默丢弃，客户端只看到超时或 Connection refused，Nginx 根本收不到请求。
理解 somaxconn 的真实作用
它不是总连接数限制，而是每个监听 socket 的“全连接队列”（accept queue）长度上限。TCP 三次握手完成后，连接就进入这个队列等待 Nginx 调用 accept() 取走。默认值通常为 128 或 1024，在千级并发下就可能打满。
- 队列满后，内核不发 RST，也不回复 ACK，直接丢弃后续合法连接
- 现象是客户端反复重传 SYN，最终超时；Nginx 日志里看不到对应请求
- 该值是 per-listen socket，多个 server{} 共用同一端口（如 443）时共享同一个队列
与 Nginx listen backlog 对齐是硬要求
Nginx 的 listen 指令中若不显式指定 backlog，默认值仅为 511。即使你把 somaxconn 设为 65535，实际生效的仍是 min(65535, 511) = 511。
- 必须在 nginx.conf 中显式写： listen 80 backlog=65535;（或更高，如 131072）
- SSL 端口同样需要： listen 443 ssl backlog=65535;
- 验证是否生效：运行 ss -ltn | grep ':80'，观察 Send-Q 列是否已变为你设置的值
按负载合理设定 somaxconn 数值
不能盲目设大，需结合 worker_processes 和 worker_connections 推算理论下限，并留足余量：
- 公式：somaxconn ≥ worker_connections ÷ worker_processes × 1.5～2（应对分布不均和瞬时峰值）
- 示例：8 核服务器设 worker_processes 8、worker_connections 65535 → 单端口预期待 accept 连接约 8200 → somaxconn 至少设为 16384，推荐 65535 或 131072
- 永久生效：在 /etc/sysctl.conf 中添加 net.core.somaxconn = 65535，再执行 sudo sysctl -p
必须同步强化 TCP 栈上下游环节
只调 somaxconn 是单点优化，SYN 队列、网卡收包、文件描述符等任一环节卡住，都会导致连接在更早阶段丢失：
- net.ipv4.tcp_max_syn_backlog：控制半连接队列（SYN queue），建议设为 somaxconn 的 2 倍（如 131072）
- net.core.netdev_max_backlog：网卡软中断收包队列，建议 10000～50000，防突发丢包
- fs.file-max 和 ulimit -n：系统级文件句柄上限需 ≥ worker_processes × worker_connections × 1.2；Nginx 配置中同步加 worker_rlimit_nofile 1048576;
- net.ipv4.tcp_tw_reuse = 1：启用 TIME-WAIT 复用，缓解短连接场景端口耗尽
