backlog参数只控制全连接队列长度，不管理半连接队列；其实际生效值为min(backlog, /proc/sys/net/core/somaxconn)，默认511，常用8192/16384是兼顾somaxconn限制与内存开销的平衡点。

backlog参数直接影响全连接队列长度

它不控制半连接（SYN）队列，只管已完成三次握手、等待应用调用 accept() 取走的连接。当新连接完成握手后发现全连接队列已满，Linux 内核会直接丢弃 ACK 包——客户端感知为“连接超时”或“Connection refused”，而非服务端拒绝。

• 默认值是 511，远低于中高并发场景的实际缓冲需求
• 实际生效值取 min(backlog, /proc/sys/net/core/somaxconn)，设再大也无效
• 该队列满 ≠ 服务崩溃，但会导致连接建立失败率陡升，尤其在秒级突发流量下（如活动开抢、爬虫扫端口）

为什么8192和16384是常用值

这两个数字不是玄学，而是对齐常见内核限制与内存占用的平衡点：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

• 8192：适配大多数云主机默认 somaxconn=65536 或 32768，且单个连接在队列中内存开销极小，无明显压力
• 16384：面向长连接网关、IM 推送等连接生命周期长、接入节奏不可控的场景，避免因 accept() 延迟（如 Worker 忙于 CPU 密集任务）导致队列快速溢出
• 超过 16384 后收益递减，反而可能暴露 reactor_num 不足或 worker_num 调度不及时的问题

设置backlog后连接仍被拒绝？先查这三个地方

现象是客户端反复报 Connection refused 或 connect timeout，但 $server->stats() 显示连接数很低——大概率不是 backlog 本身没生效，而是底层卡住了：

• 系统 somaxconn 未同步调高：cat /proc/sys/net/core/somaxconn 必须 ≥ 你设的 backlog 值
• max_conn 配置过小：它限制的是“已 accept 的活跃连接总数”，若设为 1000，即使 backlog=16384，第 1001 个连接也会被主动拒绝
• 文件描述符不足：ulimit -n 和 fs.file-max 必须 ≥ max_conn + 预留冗余（至少+2000），否则 accept() 系统调用直接失败，连接进不了队列

backlog和reactor_num、worker_num的协同关系

backlog 是“缓冲池”，但池子再大，没人及时清货也没用。它必须和调度能力匹配：

• reactor_num 过小（如 1），单个 Reactor 线程处理所有新连接事件，accept() 调用堆积 → 全连接队列涨得比清得快
• worker_num 过低，Worker 处理业务慢，accept() 返回后无法快速进入业务逻辑，间接拖慢新连接接纳速度
• 实测建议：reactor_num ≥ CPU 核心数，worker_num ≥ CPU 核心数 × 2，再配 backlog=8192 才能形成有效流水线

真正容易被忽略的点是：backlog 生效的前提是整个连接链路没有瓶颈。它只是最后一道缓冲，不是性能万能药。一旦看到连接拒绝，别急着调大 backlog，先用 ss -lnt 看 Recv-Q 是否持续接近你设的值——如果是，说明前面环节已经堵死。