net.core.somaxconn必须与worker_connections协同配置，否则连接会在进入nginx前被内核丢弃；推荐somaxconn≥worker_connections÷worker_processes并设为65535，同时同步调优tcp_max_syn_backlog、netdev_max_backlog等参数。
worker_connections 不是独立生效的连接上限，它必须和内核 TCP 参数形成配合链路，否则连接会在进入 Nginx 前就被丢弃或卡住。
worker_connections 与 net.core.somaxconn 的前后两关关系
worker_connections 控制每个 worker 进程能处理的已建立连接数，属于应用层调度能力；而 net.core.somaxconn 是内核为每个 listen socket 维护的“已完成三次握手但尚未被 accept() 取走”的连接队列长度，属于协议栈缓冲层。
- 若 somaxconn 过小（如默认 128），瞬时完成握手的连接超出该值，内核会静默丢弃后续合法 SYN-ACK，客户端表现为超时或重传失败
- 此时即使 worker_connections 设为 65535，也毫无意义——连接根本没机会到达 Nginx
- 推荐配置：somaxconn ≥ worker_connections / worker_processes，例如 8 个 worker、每个设 16384，则 somaxconn 至少设为 2048，生产环境建议直接设为 65535
配套内核参数需同步调整
仅调高 somaxconn 不够，还需增强整个 TCP 入口通路的承载能力：
- net.ipv4.tcp_max_syn_backlog：控制半连接队列（SYN_RECV 状态）长度，应 ≥ somaxconn，建议设为 2048～65535
- net.core.netdev_max_backlog：网卡接收队列，应对突发包洪峰，建议设为 25000
- net.ipv4.tcp_tw_reuse = 1：允许 TIME-WAIT 状态的端口复用于新连接，缓解短连接场景的端口耗尽
- net.ipv4.tcp_fin_timeout = 30：缩短 FIN_WAIT_2 超时时间，加快连接释放
为什么必须联动调整？
连接从网络到达 Nginx 的路径是：网卡 → 内核协议栈（SYN 队列 → ESTABLISHED 队列）→ accept() → Nginx 事件循环 → worker_connections 管理。任一环节容量不足，都会造成瓶颈：
- 网卡队列满 → 包被丢弃，不进协议栈
- SYN 队列满 → 客户端收不到 SYN-ACK，连接失败
- ESTABLISHED 队列（somaxconn）满 → 连接完成但取不出来，客户端超时
- worker_connections 满 → Nginx 拒绝新 accept()，日志报 “accept() failed (24: Too many open files)”
验证是否真正打通
调参后不能只看配置文件，要检查实际运行态：
- 查内核值：cat /proc/sys/net/core/somaxconn
- 查 worker 进程 fd 上限：cat /proc/$(pgrep nginx)/limits | grep "Max open files"
- 压测时观察：ss -s 中 “established” 和 “synrecv” 数量变化，若 synrecv 持续堆积，说明 somaxconn 仍是瓶颈
