Nginx提示worker_connections are not enough怎么办？并发限制排查

Nginx错误日志出现 worker_connections are not enough，意味着某个worker已经无法再打开处理请求所需的连接。它不只统计客户端连接；反向代理访问上游、长连接以及其他打开的连接同样会占用额度，因此不能简单用并发用户数去套公式。

直接把 worker_connections 从1024改到几万，有时错误仍然存在，因为进程的文件描述符上限没有同步提高，或者大量连接来自上游变慢、WebSocket长期占用和异常流量。正确顺序是先保存峰值证据，再同时核对Nginx配置、worker数量、进程限制和连接生命周期。

先确认错误发生的时间窗口

先从错误日志找到首次出现、频率和对应站点：

sudo grep -n 'worker_connections are not enough' /var/log/nginx/error.log | tail -50
sudo journalctl -u nginx --since '30 minutes ago' --no-pager
date

把时间与流量、502/504、上游延迟和发布记录对齐。只在固定高峰出现，通常是容量不足或连接释放太慢；平时流量很低却突然密集出现，则要检查爬虫、攻击、健康检查风暴和上游故障。

日志中的worker进程号也有价值。若错误长期集中在一个worker，需要确认连接是否均匀分配、是否开启复用端口，以及某类长连接是否集中落到少数进程。

读取Nginx最终生效配置

不要只查看某个片段文件。使用 nginx -T 展开所有include，确认配置实际位于正确上下文：

sudo nginx -T 2>&1 | grep -E 'worker_processes|worker_connections|worker_rlimit_nofile'
sudo nginx -t

worker_connections 必须写在 events 块中，默认值通常为512。worker_processes auto 会按可用CPU选择worker数量，但容器的CPU配额、亲和性和旧版本行为可能影响结果，应结合实际进程数量查看。

ps -C nginx -o pid,ppid,cmd

理论上限常被粗略写成worker数乘以每个worker连接数，但这不是可直接承诺的客户端并发量。实际值还受文件描述符、代理连接、监听套接字、keepalive和系统资源约束。

统计当前连接而不是只看请求量

启用了 stub_status 时，可读取Active、Reading、Writing和Waiting。没有监控入口，也可以从套接字和worker文件描述符入手：

sudo ss -s
sudo ss -ntp | grep nginx | wc -l
for pid in $(pgrep -P $(cat /run/nginx.pid)); do printf '%s ' "$pid"; ls /proc/$pid/fd | wc -l; done

Waiting 高不一定是故障，它通常包含HTTP keepalive等待连接。Writing长期上升要检查客户端接收慢和响应体过大；连接上游的ESTABLISHED或SYN-SENT堆积，则更像上游响应慢或网络异常。

采样应覆盖完整高峰，至少记录每个worker的文件描述符数量，而不是只看一秒快照。命令会遍历进程目录，超大规模环境应降低频率，优先使用已有监控指标。

理解反向代理的双连接消耗

客户端请求进入Nginx占用一条连接，Nginx再访问HTTP、FastCGI、uwsgi或其他上游时，还需要相应连接。代理场景下，一个活跃请求可能同时涉及客户端侧与上游侧，因此最大客户端数通常小于简单乘积。

上游响应突然变慢时，客户端连接和上游连接会一起停留更久，连接额度很快被吃满。应同时检查：

sudo ss -nt state established '( sport = :80 or sport = :443 )'
sudo tail -n 200 /var/log/nginx/access.log

访问日志最好包含 $request_time、$upstream_connect_time 和 $upstream_response_time。客户端总耗时高而上游耗时低，可关注慢客户端和发送带宽；上游耗时同步升高，则先修复上游容量，不要只扩Nginx连接数。

核对进程文件描述符上限

官方配置说明明确指出，实际同时连接数不能超过打开文件数上限。直接读取正在运行的worker限制最可靠：

WORKER_PID=$(pgrep -P $(cat /run/nginx.pid) | head -1)
cat /proc/$WORKER_PID/limits | grep -i 'open files'
sudo nginx -T 2>&1 | grep worker_rlimit_nofile

systemd管理的Nginx还要检查单元限制：

systemctl show nginx -p LimitNOFILE
systemctl cat nginx

Shell里执行 ulimit -n 只代表当前Shell，不代表systemd启动的Nginx。需要调整时，应使用单元override中的 LimitNOFILE，必要时配合Nginx主上下文的 worker_rlimit_nofile，随后重新加载systemd并重启或平滑升级。具体数值要给日志、监控连接峰值和安全余量支撑。

找出连接为什么迟迟不释放

扩大上限只是给排查争取空间。HTTP keepalive过长、WebSocket/SSE长期连接、客户端上传慢、上游无响应、代理超时设置过宽，都可能让连接常驻。

sudo ss -ntp | awk '/nginx/ {print $1}' | sort | uniq -c
sudo nginx -T 2>&1 | grep -E 'keepalive_timeout|proxy_.*timeout|client_.*timeout'

不要为了快速释放连接把所有超时压到几秒。WebSocket和大文件上传本就需要较长连接，粗暴缩短会制造断线。应按站点和location区分协议，再根据真实响应时间设置connect、read、send和keepalive超时。

异常来源IP形成大量并发时，先确认业务是否允许，再使用接入层限速、连接限制或防护服务。仅靠提高上限会让恶意流量消耗更多内存和上游资源。

安全调整events与系统限制

示例结构如下，数值只是展示配置位置，不能直接复制到生产：

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
}

调整前估算worker峰值文件描述符、预留日志和其他文件开销，并确认系统全局文件表、内存和端口资源。连接数提高后，每条连接相关缓冲仍会消耗内存，TLS握手还会带来CPU压力。

需要压测验证时，可在 萤光云 建立与生产版本一致的隔离节点，或在按小时计费的 LightNode 上构造受控流量。不要直接对生产域名发起无上限压测，也不要复制真实证书私钥。

平滑加载与回滚

先保存旧配置并做语法检查，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx --since '5 minutes ago' --no-pager

平滑加载会让新worker使用新配置，旧worker处理完现有连接后退出。长连接很多时，旧worker可能保留较久，所以应同时观察新旧PID、连接数和内存。若修改了systemd的LimitNOFILE，仅reload Nginx可能不会获得新限制，需按变更方式安排受控重启。

回滚不能只恢复nginx.conf；若还改过systemd override、负载均衡或防火墙，也要纳入同一变更单。每次只改变一组相关参数，才能知道哪项真正有效。

修复后怎样验收

在真实高峰或可控压测下，确认错误日志不再出现，worker文件描述符有合理余量，上游响应时间没有恶化，系统内存和CPU也保持稳定。

sudo nginx -T 2>&1 | grep -E 'worker_processes|worker_connections|worker_rlimit_nofile'
for pid in $(pgrep -P $(cat /run/nginx.pid)); do cat /proc/$pid/limits | grep 'open files'; done

合格的修复不是单纯让报错消失，而是连接峰值、文件描述符上限和上游容量之间有可解释的余量，并且重启后配置仍然生效。

常见问题

worker_connections包含上游连接吗？

包含。官方说明指出它统计worker打开的全部连接，包括与被代理服务器的连接，而不只是客户端连接。

配置65535就一定能支持65535个用户吗？

不能。还受worker数量、进程文件描述符、每个请求涉及的连接、连接时长、内存和上游能力限制。

只执行nginx reload能更新LimitNOFILE吗？

systemd单元限制发生变化时，通常需要让服务进程由更新后的管理器配置重新启动。应在维护窗口按实际单元配置验证，不要只看当前Shell的ulimit。