least connections算法易使worker进程连接负载不均，需同步调优系统、用户级和nginx三层文件描述符限制：systemd优先级最高，其次nginx.conf中worker_rlimit_nofile，再配limits.conf；https下每个连接耗3–5个fd，应按worker_connections×4设定上限并验证生效。
Least Connections 负载均衡算法本身不改变连接资源消耗，但它会让每个 worker 进程更频繁地承接新连接——尤其在后端响应时间不均时，容易导致单个 worker 突然承载远超平均值的活跃连接。这时，系统文件描述符（FD）限制就成了实际并发瓶颈。调优不是“只改一个数”，而是打通三层限制：系统全局、用户/进程级、Nginx 内部声明。
确认当前瓶颈在哪一层
先查清楚是哪一层卡住了，避免盲目调大：
- 运行 ulimit -n，看当前 shell 的 soft nofile 限制（通常影响 Nginx 启动环境）
- 执行 cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"，看 Nginx worker 进程实际生效的 FD 上限（关键！很多问题就出在这里显示仍是 1024）
- 运行 sysctl fs.file-max，确认系统总上限是否足够（建议 ≥ worker_processes × worker_connections × 1.5）
同步放开三类文件描述符限制
这三步缺一不可，且优先级从高到低：systemd > nginx.conf > limits.conf
-
systemd 服务级（最高优先级）：编辑 /etc/systemd/system/nginx.service.d/override.conf，加入：
[Service]<br>LimitNOFILE=65536
然后执行 systemctl daemon-reload && systemctl restart nginx -
Nginx 主配置声明：在 /etc/nginx/nginx.conf 的全局块（main context）中添加：
worker_rlimit_nofile 65536;
注意：该值不能超过 systemd 或 limits.conf 中设置的 hard nofile，否则启动失败 -
用户级持久限制：在 /etc/security/limits.conf 中为 nginx 用户（或通配 *）设置：
nginx soft nofile 65536<br>nginx hard nofile 65536
若用 root 启动再 drop 权限，也需确保 root 的限制达标
匹配 Least Connections 下的实际连接压力
Least Connections 倾向把请求集中到最空闲的后端，但 Nginx 自身 worker 连接数仍需留足余量。HTTPS 场景下每个连接实际占 3–5 个 FD，普通 HTTP 约 1–2 个：
- 若设
worker_connections 16384，且启用 HTTPS，建议worker_rlimit_nofile至少设为 65536（16384 × 4），而非刚好匹配 - 同时检查
worker_processes是否合理：用auto并配合worker_cpu_affinity auto，避免多进程争抢 CPU 导致连接堆积在少数 worker 上 - events 块必须启用
use epoll;和multi_accept on;，否则无法高效处理密集 accept() 调用
验证是否真正生效
重启后不要只信配置文件，要验证进程实际能力：
- 再次运行 cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"，输出应为类似
Max open files 65536 65536 files - 压测时观察 error.log 是否还有
accept() failed (24: Too many open files) - 用 ss -s 查看当前 socket 统计，对比
total:与tcp:数值，判断是否接近理论上限
