要让Nginx在负载均衡场景下稳定承载巨量连接，net.core.somaxconn与Nginx listen backlog必须协同设为65535或更高（如131072），共同决定“已完成三次握手、等待accept取走”的全连接队列容量；默认128极易溢出致连接被内核静默丢弃，需同步调优tcp_max_syn_backlog（建议2倍）、netdev_max_backlog、file-max、ulimit及启用multi_accept等。
要让 Nginx 在负载均衡场景下稳定承载巨量连接，net.core.somaxconn 不是可选项，而是连接接纳链路的第一道闸门。它和 Nginx listen backlog 共同决定“已完成三次握手、等待 accept 取走”的连接队列实际容量。默认值 128 或 1024 在万级并发下极易打满，新连接被内核静默丢弃——客户端只看到超时或 Connection refused，Nginx 日志里却空空如也。
明确 somaxconn 的真实作用
它不是总连接数限制，而是每个监听 socket（比如 :80 或 :443）独享的“全连接队列”（accept queue）长度上限。TCP 三次握手完成后，连接就排队等 Nginx 调用 accept() 取走。这个队列一旦溢出：
- 内核不发 RST，也不回复 ACK，直接丢弃后续合法 SYN-ACK
- 客户端反复重传，最终超时；压测时表现为大量 502/503 或连接失败
- 多个 server{} 共用同一端口（如 443 上托管几十个域名），共享同一个队列，需按最大预期并发估算
必须与 Nginx listen backlog 对齐
Nginx 的 listen 指令若不显式指定 backlog，默认值仅为 511。哪怕你把 somaxconn 设成 65535，实际生效的仍是 min(65535, 511) = 511 —— 高配完全无效。
- 在 nginx.conf 中为每个监听端口显式声明：listen 80 backlog=65535;、listen 443 ssl backlog=65535;
- 若目标是百万级连接，推荐统一设为 65535 或 131072（需内存支撑）
- 验证是否生效：运行 ss -lnt | grep ':80'，观察 Send-Q 列是否已变为你设置的值
同步强化 TCP 栈上下游环节
只调大 somaxconn 是单点优化，SYN 队列、网卡收包、文件描述符任一环节卡住，连接就会在更早阶段丢失：
- net.ipv4.tcp_max_syn_backlog：控制半连接队列（SYN_RECV）长度，建议设为 somaxconn 的 2 倍（如 131072）
- net.core.netdev_max_backlog：网卡软中断收包队列，设为 10000～50000，防突发流量底层丢包
- fs.file-max 和 ulimit -n：系统级文件描述符上限需 ≥ worker_processes × worker_connections × 1.5；Nginx 内同步配置 worker_rlimit_nofile
- net.ipv4.tcp_tw_reuse = 1：启用 TIME-WAIT 复用，缓解短连接密集场景（如 API 网关、Ingress 回源）的端口耗尽问题
负载均衡场景下的特别注意事项
作为反向代理或 Ingress 控制器，Nginx 不仅要处理客户端连接，还要主动与后端建立大量上游连接，这对系统资源提出双重压力：
- 扩大临时端口范围：net.ipv4.ip_local_port_range = "1024 65535"，避免 upstream 连接因端口不足失败
- Ingress Controller（如 nginx-ingress）通常自动读取 somaxconn 生成配置，但仍需确认其生成的 nginx.conf 中 listen 行含正确 backlog 值
- 启用 multi_accept on;，让单次事件循环尽可能多地从队列中取走就绪连接，降低积压概率
- 关闭 accept_mutex off;（尤其在多核高并发下），允许所有 worker 同时接受新连接，减少排队延迟
