backlog参数不直接提升并发连接数，只控制已完成三次握手、等待accept()的连接队列长度，实际值取其与net.core.somaxconn的较小者；队列满则丢弃新连接，需同步调大somaxconn、ulimit -n及worker_rlimit_nofile等配套参数。
listen 指令的 backlog 参数本身不直接提升服务器能承载的并发连接数，但它会影响新连接在进入应用层处理前的“排队能力”，从而间接影响高并发场景下的连接接纳表现。关键在于理解它在 TCP 连接建立流程中的作用位置和系统协同限制。
backlog 控制的是“已完成连接队列”的长度
当客户端发起 SYN 握手，服务端完成三次握手后，该连接会进入内核维护的 accept 队列（也叫 completed queue），等待应用调用 accept() 取走。listen 的 backlog 参数主要设置这个队列的最大长度（实际值受内核参数 somaxconn 限制）。若队列满，后续完成握手的连接会被内核直接丢弃（不发 RST，客户端可能超时重传）。
- backlog 值过小（如默认 128），在突发大量短连接或 accept 处理慢时，容易丢连接
- 适当增大 backlog（如设为 512 或 1024），可缓冲握手完成但尚未被 accept 的连接，降低丢包率
- 注意：它不控制 SYN 队列（incomplete queue），SYN 队列大小由 net.ipv4.tcp_max_syn_backlog 决定
必须同步调整内核参数 somaxconn
Linux 内核会对 backlog 参数做截断：实际队列长度 = min(backlog, /proc/sys/net/core/somaxconn)。如果只改 Nginx 或 Redis 的 listen backlog，而 somaxconn 仍为默认值（常见为 128），则设置无效。
- 临时生效：sudo sysctl -w net.core.somaxconn=4096
- 永久生效：在 /etc/sysctl.conf 中添加 net.core.somaxconn = 4096，然后运行 sysctl -p
- 检查当前值：cat /proc/sys/net/core/somaxconn
单靠 backlog 无法突破系统级瓶颈
连接承载能力是全链路问题，backlog 只解决“握手后排队”这一环：
- 文件描述符限制（ulimit -n）：每个连接占用一个 fd，需确保足够（如 65536）
- 端口范围与 TIME_WAIT：高并发短连接易耗尽本地端口，需优化 net.ipv4.ip_local_port_range 和 net.ipv4.tcp_tw_reuse
- 应用处理能力：accept 后的读写、业务逻辑延迟，才是真正的吞吐瓶颈；backlog 再大，accept 不及时仍会积压
- 网卡与中断：万兆网卡下，单核软中断可能成为瓶颈，需考虑 RPS/RFS 或多队列绑定
典型配置示例（以 Nginx 为例）
Nginx 的 listen 指令支持 backlog 参数：
server {
listen 80 backlog=4096;
...
}
但前提是：
- 已将 somaxconn 调至 ≥ 4096
- worker_rlimit_nofile 设为足够大（如 65536）
- 系统 ulimit -n 已同步提升
