nginx: [alert] 768 worker_connections are not enough

What the message looks like

2026/10/29 14:02:11 [alert] 1234#1234: *98765 768 worker_connections are not enough while connecting to upstream, client: 203.0.113.5, server: example.com, request: "GET /api/ HTTP/2.0", upstream: "http://127.0.0.1:8080/api/"

Common causes

• worker_connections in the events block is still the low value from the packaged nginx.conf, and traffic has outgrown it.
• A slow upstream keeps connections open for a long time, so they pile up (see also the 504 and 502 pages).
• Long-lived connections such as WebSocket, SSE or long polling occupy a slot for their whole lifetime.
• The limit is higher in nginx than the OS allows: the open-files limit of the nginx process is too small, so the value cannot be used.
• A flood of requests from bots or a misbehaving client.

Check

1. Current worker settings
   nginx -T 2>/dev/null | grep -nE 'worker_(processes|connections|rlimit_nofile)'Copy
2. How often does the alert appear?
   grep -c 'worker_connections are not enough' /var/log/nginx/error.logCopy
3. Open-files limit of the running master process
   grep 'open files' /proc/$(cat /run/nginx.pid)/limitsCopy
4. Socket summary (established vs. waiting)
   ss -sCopy

Fix

• Raise the limit in /etc/nginx/nginx.conf: events { worker_connections 4096; } and keep worker_processes auto;.
• Allow enough file descriptors: worker_rlimit_nofile 8192; in the main context, at least twice worker_connections when proxying.
• If systemd limits the service, add a drop-in with systemctl edit nginx and set LimitNOFILE= to a matching value.
• Reduce the load itself: fix the slow upstream, enable keepalive to the upstream, and limit abusive clients with limit_req.
• Apply it: nginx -t && systemctl restart nginx (a reload does not change the process limit set by systemd).

FAQ

What is the maximum number of clients nginx can serve?

Roughly worker_processes × worker_connections, divided by two when nginx proxies every request, because each proxied request uses a client and an upstream connection.

Is a higher value always better?

No. Each connection needs memory and a file descriptor. Raise it moderately, make sure the file descriptor limit matches, and fix the cause if connections pile up because of a slow backend.