“worker_connections are not enough”是Nginx连接瓶颈的直接证据，表明单worker进程fd耗尽，根源在于worker_connections、worker_rlimit_nofile与系统ulimit -n三者未对齐，需同步调优并验证运行时fd占用。
error_log 是 Nginx 的“运行诊断报告”，它不记录常规请求，而是聚焦于异常、资源告警和调度失败事件。对系统资源调度瓶颈而言，它不是间接线索，而是直接证据源——尤其当 worker 进程因资源不足无法完成连接分配、缓冲或响应转发时，error_log 会明确写出限制类型和触发场景。
重点关注三类调度级告警
这些日志不是配置错误提示，而是内核级资源调度失败的回传：
-
“worker_connections are not enough”：说明单 worker 进程的连接句柄已耗尽。这不是客户端太多，而是 Nginx 在连接建立阶段就卡在了 fd 分配环节，根源在
worker_connections、worker_rlimit_nofile和系统ulimit -n三者未对齐； -
“accept() failed (24: Too many open files)”：操作系统层面拒绝分配新文件描述符，表明即使 Nginx 配置允许，内核已无可用 fd，需检查
/proc/sys/fs/file-max及用户级 limits.conf； - “an upstream response is buffered to a temporary file”：内存缓冲区不足，被迫降级使用磁盘临时文件。本质是内存调度策略失效，暴露的是 proxy/fastcgi 缓冲参数与实际响应体大小不匹配，属于内存资源调度瓶颈。
结合上下文判断瓶颈发生位置
单看报错不够，必须读日志后缀和前后行：
- 出现 “while connecting to upstream” 后缀，说明瓶颈不在接入层，而在 Nginx 主动发起上游连接时——此时每个请求消耗 2 个连接（client + upstream），且可能叠加长连接复用，容易低估真实压力；
- 日志中连续出现 同一 URI 或 upstream 名称，指向特定业务路径或后端服务拖慢整体调度节奏，比如某个 API 响应慢导致 worker 被长时间占用，阻塞新连接接入；
- 伴随 “client request body is buffered”，说明上传请求体过大，触发了 client_body_buffer_size 不足，属于请求体处理路径的内存调度问题。
验证资源调度是否真实受限
不能只信日志文字，要交叉验证运行时状态：
- 查当前活跃连接总数：
ss -s | grep tcp:或netstat -an | grep :80 | wc -l； - 查 Nginx 自身连接分布：
curl http://127.0.0.1/nginx_status（需启用 stub_status），关注 Active connections 和 Reading/Writing/Waiting 比例； - 查单个 worker 实际打开的 fd 数：
lsof -p $(pgrep nginx | head -1) | wc -l，对比是否逼近worker_connections值； - 查系统级 fd 使用率：
cat /proc/sys/fs/file-nr，三个数字分别代表已分配、已使用、最大可分配数。
针对性调整资源调度策略
调参不是盲目加数字，而是按瓶颈类型精准干预：
- 连接类瓶颈：同步调高
worker_connections、worker_rlimit_nofile，并在/etc/security/limits.conf中为 nginx 用户设置nofile软硬限制，重启 systemd 服务生效； - 内存缓冲类瓶颈：根据协议类型（proxy / fastcgi / client）分别扩大对应缓冲区，如
proxy_buffers 64 64k，并设proxy_busy_buffers_size为总缓冲的 1/2～2/3，避免频繁换页； - 磁盘 IO 类瓶颈：若临时文件写入频繁，先确认
proxy_temp_path所在分区空间与 I/O 性能，再通过proxy_max_temp_file_size限制单请求落盘上限，必要时对流式接口关闭proxy_buffering off。
