nginx连接排队能力取决于内核accept队列与listen backlog协同配置；需同步调大net.core.somaxconn、显式设置listen backlog=65535，并配套调整tcp_max_syn_backlog、ulimit和worker_rlimit_nofile。

Nginx 轮询本身不决定排队能力，真正影响“新连接能否被暂存而不丢弃”的，是操作系统内核和 Nginx 协同管理的 TCP 连接队列——其中 backlog 参数正是打通这一环节的关键开关。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

必须同步调大内核 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 或极小值，可能是流量未达压力，或上游已提前拒绝（如负载均衡器或防火墙限速）

不复杂但容易忽略