答案是需同步调高系统级、用户级、进程级及systemd级四层文件描述符限制，并验证生效。报错“socket() failed (24: Too many open files)”表明Nginx worker进程触及fd上限，须依次检查并调高fs.file-max、limits.conf、worker_rlimit_nofile和LimitNOFILE，确保各层一致且足够。
当 Nginx 遇到高并发连接数超限，并非直接在 error.log 中输出“连接数超限”这类明确字样，而是通过系统级错误码和资源耗尽现象间接体现。真正触发日志记录的，往往是底层 socket 创建失败或 accept 操作被拒，此时内核已无法分配新连接资源。
典型 error.log 提示内容
在高并发压测或流量突增时，/var/log/nginx/error.log 中常见如下几类报错：
- “accept() failed (24: Too many open files)”：最直接信号，说明 worker 进程打开的文件描述符（fd）已达系统限制（包括 socket 连接、配置文件、日志句柄等）
- “accept() failed (11: Resource temporarily unavailable)”：常伴随高负载出现，表明内核 backlog 队列满或进程无法及时调用 accept()，本质是连接积压未处理
- “connect() failed (24: Too many open files) while connecting to upstream”：反向代理场景下，Nginx 自身 fd 耗尽，连后端都建不了连接
-
无错误日志但大量 502/503 响应：部分请求静默失败，access.log 中
$upstream_addr为空或为-，$upstream_status为 502/503，也是 fd 不足的间接表现
关键参数与系统限制关联
这些提示背后，涉及三层限制需同步检查：
-
Nginx 层：确认
worker_connections设置（如设为 1024），且worker_processes auto匹配 CPU 核数 -
系统层：查看
ulimit -n输出值（默认常为 1024），并检查/etc/security/limits.conf中nginx用户的 soft/hard nofile 限制 -
内核层：运行
sysctl net.core.somaxconn（默认常为 128），该值决定 listen socket 的最大等待连接队列长度；同时关注net.ipv4.ip_local_port_range是否过窄，影响 outbound 连接复用
快速验证与定位方法
发现疑似连接数瓶颈时，可立即执行：
- 查当前 nginx 进程 fd 使用量：
lsof -p $(cat /var/run/nginx.pid) | wc -l - 对比系统上限：
cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files" - 实时观察连接堆积：
ss -s | grep "sockets:"查 total established + synrecv 数量趋势 - 配合 access.log 统计单位时间请求数：
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-2 | sort | uniq -c | sort -nr | head -5确认是否真为突发流量所致
修复方向不等于盲目调大
单纯增加 worker_connections 或 ulimit 可能掩盖真实问题：
- 若应用本身响应慢、连接不释放，调大只会延缓崩溃，需结合
keepalive_timeout和上游keepalive配置优化连接复用 - 检查是否有长轮询、未关闭的 WebSocket 或慢日志写入拖慢 worker，导致连接积压
- Docker/K8s 环境中，容器内 ulimit 默认继承宿主机，但可能被 cgroup 限制，需检查
docker inspect或kubectl describe pod中的 resources.limits
