listen.backlog控制的是全连接队列（accept queue）长度，非半连接队列；其实际生效值为min(配置值, net.core.somaxconn)，盲目调大无效，真实瓶颈多在pm.max_children或系统限制。
listen.backlog 不是“越大越好”，它只是 TCP 半连接队列长度，真正卡住高并发的往往是 pm.max_children 或系统级限制（如 net.core.somaxconn），盲目调大 listen.backlog 无效，还可能掩盖真实瓶颈。
为什么 listen.backlog 经常被误调？
很多人看到 Nginx 错误日志里出现 connect() failed (11: Resource temporarily unavailable)，第一反应就是改 listen.backlog。但这个错误的真实含义是：PHP-FPM 的 accept 队列已满，新连接被内核丢弃——而队列满的原因，90% 是 PHP 进程处理太慢或数量不够，不是队列本身太小。
-
listen.backlog只控制「等待被 accept() 的连接数」，不控制「正在处理的请求数」 - 它的实际生效上限受系统参数
net.core.somaxconn约束（Linux 默认常为 128 或 511） - PHP-FPM 启动时若设
listen.backlog = 8192，但net.core.somaxconn = 511，最终仍只生效 511
怎么查当前生效的 backlog 值？
别只看配置文件，要确认运行时真实值：
ss -lnt | grep ':9000'
输出中第二列（Recv-Q）显示的就是当前监听 socket 的最大 backlog（即 net.core.somaxconn 和 listen.backlog 的较小值）。
立即学习“PHP免费学习笔记（深入）”；
- 如果看到
Recv-Q是 511，说明系统限制生效了，哪怕你配了 8192 - 检查系统值：
sysctl net.core.somaxconn - 临时提升：
sudo sysctl -w net.core.somaxconn=65535 - 永久生效需写入
/etc/sysctl.conf
listen.backlog 在 PHP8.4 + 高并发下的推荐值
PHP8.4 对 FastCGI 处理无底层变更，listen.backlog 的作用逻辑和之前版本一致。关键不是“设多大”，而是“和谁对齐”：
- 先确保
net.core.somaxconn ≥ 65535（现代高并发服务通用基线） -
listen.backlog设为65535或-1（-1 表示用系统值，更稳妥） - 必须同步检查并调优
pm.max_children：它是真正决定并发能力的参数；比如 16G 内存服务器，pm.max_children通常在 100–200 区间，而非盲目堆到 1000+ - 若用 Unix socket（如
listen = /run/php/php8.4-fpm.sock），listen.backlog依然有效，且不受端口限制，但需确保 socket 文件权限和路径可读写
最容易被忽略的三件事
调完 listen.backlog 就以为高并发问题解决了？大概率会掉坑里：
- 没开 PHP-FPM 的
pm.status_path，就看不到max_children_reached计数器——这才是判断进程池是否真瓶颈的黄金指标 - 忘了调
request_terminate_timeout，长请求把 worker 占死，listen.backlog再大也白搭 - Nginx 的
fastcgi_read_timeout比 PHP 的超时还短，导致连接提前断开，错误日志里根本看不出是 PHP 慢还是 Nginx 主动砍的
