nginx "worker_connections are not enough" Fix

nginx logs this when a worker process has used every connection slot it is allowed:

2026/10/08 14:31:09 [alert] 912#912: *320118 1024 worker_connections are not enough while connecting to upstream, client: 203.0.113.50, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/"
2026/10/08 14:31:09 [alert] 912#912: 1024 worker_connections are not enough

The number is your current worker_connections value. Visitors see slow pages, 502s or dropped connections while the alert repeats. The fix is rarely just "make the number bigger", because the limit has several layers and nginx uses more connections than people expect.

How many connections does nginx really use?

Each worker has its own pool of worker_connections. The pool is shared by everything the worker opens:

• One connection per client.
• One more connection per proxied request to a backend. A reverse proxy therefore uses roughly two connections per active request, plus any keepalive connections to the upstream.
• Connections to FastCGI, uWSGI or other upstreams.
• Open listening sockets.

So the rough capacity of the server is worker_processes x worker_connections, divided by two when proxying. The default worker_connections is 512 if you set nothing, and many distribution packages ship 768 or 1024.

Step 1: check the current settings

sudo nginx -T 2>/dev/null | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile|multi_accept'
nproc

Typical packaged defaults on Debian and Ubuntu are worker_processes auto; and worker_connections 768; in /etc/nginx/nginx.conf. RHEL-family packages use the same file and often 1024.

Step 2: raise the limits together

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
}

worker_rlimit_nofile raises the per-process file descriptor limit. Every connection is a file descriptor, so worker_connections can never usefully exceed the descriptor limit available to each worker. A reasonable rule is worker_rlimit_nofile at least double worker_connections for a proxy, since each proxied request needs a client socket and an upstream socket.

Then test and reload:

sudo nginx -t && sudo systemctl reload nginx

If the log now changes to "Too many open files", the operating system limit is the next wall. See nginx too many open files (24) for the systemd LimitNOFILE override.

Step 3: look for connections being wasted

Raising limits treats the symptom if connections are held open for the wrong reasons. Check these first:

1. Slow backends. If the application takes 20 seconds to answer, each request holds two connections for 20 seconds. Fixing slowness reduces connection use dramatically. See nginx upstream timed out and reduce time to first byte.
2. Long keepalive. keepalive_timeout 65; is the default. On a busy server with many idle clients, lower it (for example 15s) so idle sockets are freed.
3. Missing upstream keepalive. Without it, nginx opens and closes a backend connection per request, adding churn. Enable it:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

1. Slow-client or bot traffic. A flood of connections from a few addresses can consume the pool. Check the access log for a dominant IP or user agent, and rate-limit with limit_conn and limit_req. If the traffic looks like an attack, read DDoS basics for website owners and consider putting a CDN in front. The CDN Detector shows whether you already have one.
2. WebSockets and long polling. Each stays open for as long as the user is connected, so these workloads need far higher worker_connections than normal page serving.

Step 4: see actual usage

Enable the stub status page on a local-only address to watch active connections:

server {
    listen 127.0.0.1:8081;
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

curl -s http://127.0.0.1:8081/nginx_status

The Active connections figure is the total across workers. Compare it with worker_processes x worker_connections while load is high. You can also count sockets directly with ss -s and sudo ss -tn state established '( sport = :443 or sport = :80 )' | wc -l.

What about multi_accept?

multi_accept on; makes a worker accept all pending connections at once rather than one at a time. It can help under bursts but does not raise any limit, so do not expect it to cure this alert. Leave it at its default unless you have measured a benefit.

Verify

After the reload, stay on the error log for a while with sudo tail -f /var/log/nginx/error.log, and run a load test or wait for peak traffic. The alert should stop. Measure response time from outside with the Website Speed Test and keep an uptime monitor on the busiest URL so slowdowns are caught early.

Next steps

• Raise the OS limit with nginx too many open files (24).
• Tune upstream behavior in nginx 502 and 504 timeout tuning.
• Understand traffic floods in DDoS basics for website owners.
• Diagnose slowness with website slow diagnosis.

FAQ

What is a safe worker_connections value?

There is no universal number. Common production values are 4096 to 16384, as long as worker_rlimit_nofile and the system limits are higher. Size it from measured Active connections plus headroom.

Does worker_processes affect this?

Yes. Total capacity is workers multiplied by connections each. worker_processes auto; sets one worker per CPU core.

Why does a reverse proxy need double the connections?

One socket faces the client and another faces the backend for the duration of each request.

Is this error always traffic?

No. Slow backends and idle keepalive connections can fill the pool even at modest request rates.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.