When Traffic Hits the CeilingEverything seems fine until a traffic spike hits. Suddenly, users see 500 Internal Server Errors, or your site just stops responding. If you check your Nginx error log at /var/log/nginx/error.log, you’ll likely see this warning staring back at you:
2023/10/27 14:30:15 [alert] 1234#0: 1024 worker_connections are not enough, reopen logs
Your server has hit a hard ceiling. By default, many Nginx installations limit each worker process to 1024 connections. While that sounds like a lot, it is often too low for modern apps and busy APIs.
Why 1024 Isn't EnoughYou can calculate your server's total capacity with a simple formula: Max Connections = worker_processes * worker_connections. However, there is a catch if you use Nginx as a reverse proxy for Node.js, PHP-FPM, or Python.
In a proxy setup, every single request uses two connections. One connection links the user to Nginx, and the second links Nginx to your backend service. This effectively cuts your 1024 capacity in half, meaning only 512 users can connect at once. Beyond Nginx settings, the Linux kernel also sets a limit on "open files." Since Linux treats every network socket as a file, your OS might be blocking Nginx from opening more connections even if you change the config file.
Step 1: Update Nginx ConfigurationStart by boosting the internal limit. Open /etc/nginx/nginx.conf with your preferred editor:
sudo nano /etc/nginx/nginx.conf
Find the events block. For a standard VPS with 2GB to 4GB of RAM, 4096 or 8192 is a safe, stable starting point.
events {
worker_connections 4096;
# Let each worker accept all new waiting connections at once
multi_accept on;
}
Step 2: Sync Workers with CPU CoresIn the same file, look for the worker_processes directive. Set this to auto. This tells Nginx to spawn one process for every CPU core available, which is much more efficient than guessing a number.
worker_processes auto;
Step 3: Raise File Descriptor LimitsThis is where most people get stuck. If you set worker_connections to 4096 but the system still thinks 1024 is the max, Nginx will keep crashing. You must explicitly tell Nginx how many file descriptors it can handle. Add worker_rlimit_nofile at the very top of your nginx.conf file.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
# Set this to at least double your worker_connections
worker_rlimit_nofile 16384;
events {
worker_connections 8192;
}
Step 4: Linux System TuningSometimes the OS itself has a strict "nofile" limit. You can see your current shell's limit by running ulimit -n. To make a permanent change for the Nginx user, edit the system limits file:
sudo nano /etc/security/limits.conf
Add these lines to the bottom, replacing www-data with nginx if that is what your system uses:
www-data soft nofile 16384
www-data hard nofile 16384
Step 5: Apply and Verify the FixNever restart Nginx without testing the syntax first. A single typo can take your whole site offline.
sudo nginx -t
If the test passes, reload the configuration. This applies changes without kicking off active users.
sudo systemctl reload nginx
How to confirm it workedDon't just take the system's word for it. Find the Process ID (PID) of an active worker:
ps aux | grep nginx
Then, check the real-time limits for that PID (replace 1234 with your actual PID):
cat /proc/1234/limits | grep "Max open files"
If the output shows 16384, your server is ready for the next traffic surge.