先明确一个底层事实：backlog 参数只管全连接队列，别指望它去干预半连接（SYN）队列。它的实际生效值取 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 本身没生效，而是底层卡住了：
- 系统
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 是否持续接近你设的值——如果是，说明前面环节已经堵死。
