必须匹配 net.core.somaxconn 才能使 worker_connections 有效，否则连接在进入 nginx 前即被内核丢弃；推荐 somaxconn ≥ worker_connections ÷ worker_processes 并设为 65535，同步调优 tcp_max_syn_backlog、netdev_max_backlog 等参数。
要让 worker_connections 真正发挥作用，必须让它和内核的 net.core.somaxconn 匹配。否则连接会在进 Nginx 前就被丢弃，配置再高也没用。
核心匹配关系
net.core.somaxconn 是每个监听 socket 的“已完成三次握手、等待 accept() 取走”的队列长度；worker_connections 是单个 worker 进程能处理的并发连接上限。两者不是相等关系，而是前后衔接关系：
- 理想情况下应满足：somaxconn ≥ worker_connections ÷ worker_processes
- 必须留余量——实际建议直接设为 65535，避免因连接分布不均或突发流量导致积压
- 多个
server{}监听同一端口（如 443）共享同一个全连接队列，需按最大预期并发估算，不能只看单个 server
为什么不能只调大 worker_connections
连接到达 Nginx 的路径是：网卡 → 内核协议栈（SYN 队列 → ESTABLISHED 队列）→ accept() → Nginx 事件循环 → worker_connections 管理。任一环节容量不足都会卡住：
- 若
somaxconn太小（如默认 128），瞬时完成握手的连接超出该值，内核会静默丢弃后续合法连接，客户端表现为超时或Connection refused - 此时即使
worker_connections设为 65535，连接根本到不了 Nginx，完全无效 - 用
ss -lnt查看Recv-Q，持续大于 0 就是队列积压的直接证据
配套必须同步调整的参数
只改 somaxconn 和 worker_connections 不够，还需打通整条 TCP 入口通路：
-
net.ipv4.tcp_max_syn_backlog：控制半连接队列（SYN_RECV 状态），建议设为 65535 或至少与somaxconn持平 -
net.core.netdev_max_backlog：网卡接收队列，应对突发包洪峰，建议设为 25000～262144 -
worker_rlimit_nofile：Nginx 进程可打开的最大文件数，必须 ≥worker_connections × worker_processes - Nginx 配置中启用
multi_accept on和reuseport，提升取连接效率，缓解队列压力
验证是否真正生效
调参后不能只看配置文件，要检查运行态：
- 查内核值：
sysctl net.core.somaxconn，确认已加载 - 查 Nginx worker 进程的 fd 上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时观察
ss -s输出中的tcp行：inuse接近somaxconn值，说明入口队列吃紧；synrecv持续堆积，则半连接队列仍是瓶颈
