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是常用值
这两个数字不是玄学，而是对齐常见内核限制与内存占用的平衡点：
-
8192：适配大多数云主机默认somaxconn=65536或32768，且单个连接在队列中内存开销极小，无明显压力 -
16384：面向长连接网关、IM 推送等连接生命周期长、接入节奏不可控的场景，避免因accept()延迟（如 Worker 忙于 CPU 密集任务）导致队列快速溢出 - 超过
16384后收益递减，反而可能暴露reactor_num不足或worker_num调度不及时的问题
设置backlog后连接仍被拒绝？先查这三个地方
现象是客户端反复报 Connection refused 或 connect timeout，但 $server->stats() 显示连接数很低——大概率不是 backlog 本身没生效，而是底层卡住了：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 系统
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 是否持续接近你设的值——如果是，说明前面环节已经堵死。
