Nginx连接排队能力取决于内核accept队列与listen backlog协同配置；需同步调大net.core.somaxconn、显式设置listen backlog=65535，并配套调整tcp_max_syn_backlog、ulimit和worker_rlimit_nofile。
Nginx 轮询本身不决定排队能力，真正影响“新连接能否被暂存而不丢弃”的，是操作系统内核和 Nginx 协同管理的 TCP 连接队列——其中 backlog 参数正是打通这一环节的关键开关。
必须同步调大内核 accept 队列上限
Linux 内核用 net.core.somaxconn 控制已完成三次握手、等待 accept() 取走的连接队列（即 accept queue）最大长度。Nginx 的 listen backlog= 值不能超过它，否则会被自动截断。
- 临时生效：
sudo sysctl -w net.core.somaxconn=65535 - 永久生效：在
/etc/sysctl.conf中添加net.core.somaxconn = 65535，再执行sysctl -p
Nginx listen 必须显式声明 backlog 值
轮询配置再合理，若 listen 没写 backlog=，Nginx 就用默认值（通常仅 511），高并发下极易溢出丢连接。
- 正确写法示例：
server { listen 80 backlog=65535; listen 443 ssl backlog=65535; } - 验证是否加载成功：
nginx -T | grep "listen.*backlog"
别漏掉 SYN 半连接队列和系统资源配套
accept 队列只是后半程，前半程（刚发来 SYN、尚未完成握手）由 net.ipv4.tcp_max_syn_backlog 控制，同样需设为 65535。
同时确保：
- 系统文件描述符上限足够：
ulimit -n至少 65535 - Nginx 配置中匹配：
worker_rlimit_nofile 65535 -
worker_connections × worker_processes ≤ ulimit -n，否则连接无法建立
观察是否真起作用
压测时运行 ss -lnt | grep :80，重点关注 Recv-Q 列：
- 若长期接近你设的
backlog=65535，说明队列正在有效缓冲，未溢出 - 若频繁出现
0或极小值，可能是流量未达压力，或上游已提前拒绝（如负载均衡器或防火墙限速）
不复杂但容易忽略
