worker_connections设置不当最直接引发503错误，因连接数超限导致Nginx无法accept新请求，继而触发“Too many open files”、连接堆积、雪崩重试及静默降级等问题。
worker_connections 设置不当最直接引发的错误是 “worker_connections are not enough”，但它只是表象，背后往往连带一系列系统级和应用层异常。这类限制不是孤立生效的，一旦失配，会快速暴露在多个环节。
连接被拒绝或返回 503 错误
当新连接请求到达时，Nginx worker 进程已达到 worker_connections 上限，无法再 accept 新连接。此时：
- 客户端可能收到 503 Service Temporarily Unavailable 响应（尤其在反向代理场景）
- 部分请求直接被内核丢弃，表现为 TCP 连接超时、RST 包、或客户端无响应
- 日志中反复出现
accept() failed (24: Too many open files)或worker_connections are not enough while connecting to upstream
日志报错 “Too many open files”
这不是 Nginx 配置写错了，而是底层资源被卡死：
- Nginx 启动时报
could not open error log file: open() "/var/log/nginx/error.log" failed (24: Too many open files) - worker 进程运行中突然无法打开临时文件、缓存文件或 upstream 连接，导致请求失败
- 根本原因是
ulimit -n或worker_rlimit_nofile小于worker_connections，每个连接至少占 1 个 fd，反向代理下常需 2–3 个
连接堆积、延迟升高与雪崩式重试
限制过严不会立刻宕机，但会引发连锁反应：
- 内核 listen 队列积压，
netstat -s | grep "listen overflows"显示溢出次数上升 - 客户端因超时反复重发请求，QPS 虚高但有效吞吐下降
- 后端服务收到大量重复请求或连接未释放，触发自身限流或崩溃
- 监控看到
Accepts/Handled比值明显低于 1，说明很多连接连 accept 都没完成
配置加载失败或静默降级
有些问题不报错，但实际失效：
- 修改
worker_connections 65535后nginx -t通过，但启动时日志只 warn：“xxx worker_connections exceed open file resource limit: 1024”，实际按 1024 运行 - systemd 环境下未配
LimitNOFILE，即使 limits.conf 改了也无效 - 把
worker_connections写在 http 或 server 块里，Nginx 直接启动失败，提示语法错误
