Nginx "Too many open files" or "worker_connections are not enough"? Raise the right limit

1. Which message do you have?

sudo grep -E "worker_connections are not enough|Too many open files" /var/log/nginx/error.log | tail -n 5

• worker_connections are not enough: Nginx's own connection limit. In our test (20 connections, 50 visitors at once), 33 visitors got no answer at all: the connection just closed. See step 2.
• (24: Too many open files): the operating system's limit on open files for Nginx. In our test (limit 64, 100 visitors), 68 of them got a 500 error. See step 3.

Neither is common on a small site with default settings. If you see them, also check why so many connections are open at once: a slow PHP backend or a bot can hold them. See server slow? find which site and page and rate limiting.

2. "worker_connections are not enough"

Each Nginx worker can hold worker_connections connections at once. Debian and Ubuntu set 768. That number counts every connection, including the ones Nginx opens to PHP-FPM or another backend, so a PHP page uses two. Look at the current settings:

grep -E "worker_processes|worker_connections|worker_rlimit_nofile" /etc/nginx/nginx.conf

Raise it in the events block of /etc/nginx/nginx.conf, and raise the file limit with it (step 3), because every connection is also an open file:

worker_rlimit_nofile 8192;

events {
    worker_connections 4096;
}

worker_rlimit_nofile goes at the top level, outside every block. Then test and reload:

sudo nginx -t && sudo systemctl reload nginx

More connections cost a little memory, but not much. The real limit is usually what's behind Nginx: if PHP can only run 10 pages at once, 4,000 connections just means 4,000 visitors waiting. See 502 and 504 errors for the PHP side.

3. "Too many open files"

Linux limits how many files (and connections, which count as files) each program may have open. On Debian 13, systemd starts services with a soft limit of 1,024 and a hard limit of 524,288 (#DefaultLimitNOFILE=1024:524288 in /etc/systemd/system.conf). Check what the Nginx workers really have:

cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "open files"

The fix is the same line as in step 2. Nginx starts as root, so it can raise its workers' limit itself, up to the hard limit:

worker_rlimit_nofile 8192;

In our test, worker_rlimit_nofile 1024 took the workers from 64 to 1,024 open files, and all 100 visitors got their download instead of 68 errors. A good rule: at least twice worker_connections.

Raising worker_connections alone can make it worse. In our test, we set 4,096 connections but left the file limit low. Nginx accepted the visitors, then failed with "Too many open files" and 500 errors. Always raise both together.

You don't need to change ulimit in your shell, or /etc/security/limits.conf: those don't apply to services that systemd starts. If another service needs more, set LimitNOFILE= in a systemctl edit override for that service.

4. Check it after the reload

sudo nginx -t && sudo systemctl reload nginx
cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "open files"

The first number should now be your worker_rlimit_nofile. A reload starts new workers. If the number hasn't changed, restart Nginx instead (sudo systemctl restart nginx; a short interruption, and only after nginx -t passes). We tested the limit itself, but not whether a reload alone applies it.

Quick list

• worker_connections are not enough (visitors get no answer): raise worker_connections in events { }.
• (24: Too many open files) (visitors get 500): add worker_rlimit_nofile 8192; at the top level.
• Raise both together. More connections without more files gave 500 errors in our test.
• Check: /proc/<worker pid>/limits, not ulimit in your shell.
• Then ask why so many connections are open: slow PHP, slow database, or bots.

Official sources

• Nginx: worker_connections and worker_rlimit_nofile
• systemd: DefaultLimitNOFILE

Next steps: if Nginx won't start after a change, see Nginx won't start or reload. For all the logs in one place, see where are the logs.

ServerNest is being built to set safe Nginx limits for your server's size and warn you before visitors are turned away. Join early access to try it first.

← Back to the security blog