Turkey (Turkish)
Germany (German)
Worldwide (English)
Request flowClient, NGINX, and backend connection break point
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
If NGINX is unable to accept new connections at high traffic, and you see "worker_connections are not enough" or "too many open files", only increase one number at a time. The worker count, file descriptor limit, proxy connections, keepalive, WebSocket, and bot traffic should be measured together.
2026/07/17 04:27:03 [alert] 2511#2511: 1024 worker_connections are not enough
2026/07/17 04:27:04 [crit] 2511#2511: accept4() failed (24: Too many open files)The simultaneous connection limit for each NGINX worker is determined by worker_connections. Reverse proxy connections, upstream sockets, and some open files also consume descriptors; the theoretical capacity cannot exceed the operating system limit.
worker_processes should be set to auto on most systems as it creates workers based on CPU; although it may seem like total client capacity is simply worker_processes × worker_connections, in proxy usage, an additional upstream connection may be required for each client.
worker_rlimit_nofile can increase the open file limit of NGINX workers, but it should be consistent with systemd LimitNOFILE and process soft/hard limits.
Long keepalive, WebSocket or SSE connections can keep many connections open even in low request traffic. stub_status, ss and /proc process limits should be monitored together.
Do not increase the limit alone without investigating if the sudden limit warning is caused by a bot/DDoS, slow client, upstream connection leak, or incorrect keepalive configuration.
When using a proxy client in the capacity account, consider that both client and upstream connections are consumed; the real value should be measured with stub_status and process fd number.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: A worker has reached the defined limit for new connections.
Possible cause: Low limit, long links or traffic surge.
Meaning: The process cannot open a new socket/file descriptor.
Possible cause: The NOFILE soft/hard or systemd limit is too low.
Meaning: Failed to create upstream or client socket.
Possible cause: Descriptor limit or leak.
Meaning: A socket remained open during reload.
Possible cause: Long connection or module behavior.
Meaning: The local ephemeral port or network resource may have been exhausted.
Possible cause: Too many upstream connections or TIME_WAIT.
Meaning: Connection limit is not filled directly but the worker/backend queue is growing.
Possible cause: Upstream capacity is lower than NGINX.
Meaning: Common default/example value may be insufficient for a heavy system.
Possible cause: No capacity planning for config.
Meaning: The application or NGINX process has reached the file descriptor limit.
Possible cause: Limit or file/socket leak.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile|keepalive_timeout|keepalive_requests'Displays active capacity and connection lifetime settings.
MASTER=$(cat /run/nginx.pid); cat /proc/$MASTER/limits | grep -i 'open files'
for p in $(pgrep -f 'nginx: worker'); do echo PID=$p FD=$(ls /proc/$p/fd | wc -l); cat /proc/$p/limits | grep -i 'open files'; doneMaster and worker show real NOFILE limits/fd usage.
ss -s
ss -ant state established | wc -l
ss -ant state time-wait | wc -lMeasures active, established, and TIME_WAIT connections.
curl -s http://127.0.0.1/nginx_statusShows Active, accepts, handled, requests, reading/writing/waiting values.
systemctl show nginx -p LimitNOFILE
systemctl cat nginxShows the open file limit in service unit and override files.
nginx -t && systemctl reload nginx
systemctl show nginx -p LimitNOFILEApply config change and validate service limit.
Although the root cause of the NGINX error is the same, package paths, service names, security layers and virtual host management vary depending on the Linux distribution or Plesk infrastructure used.
NGINX Worker Connections and Open Files for systemd, package path and journald controls.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sNGINX Worker Connections and Open Files for SELinux, PHP-FPM pool and RHEL-based service controls.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sNGINX virtual host files generated by Plesk: control nginx worker connections and open files.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
plesk repair web -nFirst, measure the actual connection/fd usage and traffic type; then adjust the NGINX, systemd, and operating system limits to be compatible.
Determine whether it's bot traffic, normal growth, or WebSocket/keepalive
date; uptime; ss -sRecord worker count, connection limit, and rlimit values
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'Compare config value with /proc limits and open descriptor count.
for p in $(pgrep -f 'nginx: worker'); do echo -n "$p "; ls /proc/$p/fd | wc -l; doneSeparate established, waiting, TIME_WAIT, WebSocket and upstream connections.
ss -ant | awk 'NR>1 {s[$1]++} END {for(k in s) print k,s[k]}'worker_connections, worker_rlimit_nofile and systemd LimitNOFILE should be planned together.
systemctl show nginx -p LimitNOFILEAfter reload, follow the fd number, stub_status, and error_log warnings.
nginx -t && systemctl reload nginx
watch -n2 'ss -s; curl -s http://127.0.0.1/nginx_status'If the limit increase has been made, IP/URI distribution and rate limiting plan are required.
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headLong-running connections consume worker capacity.
ss -antp | grep nginx | wc -lWaiting connections and the keepalive_timeout value are examined.
curl -s http://127.0.0.1/nginx_status; nginx -T | grep keepalive_timeoutConsider additional upstream sockets for each client.
ss -antp | grep nginx | headIf a worker's fd count is constantly increasing, open targets are examined.
lsof -p $(pgrep -f 'nginx: worker' | head -1) | head -n 50Global nginx.conf, web server template and domain traffic are evaluated together.
nginx -T | grep worker_connections; ss -sSets the upper limit for the number of connections each worker process can open at the same time; proxy upstream connections are also included in this number
Worker processes and worker connections are considered roughly, but the file descriptor limit, proxy connections, and traffic type reduce the actual capacity.
Process NOFILE, systemd LimitNOFILE, worker_rlimit_nofile, and actual fd usage must be compatible with each other.
No. It will be ineffective if the operating system limit is low; it can exacerbate the problem if there is bot traffic or fd leak.
Active connections, accepts, handled, requests showing the number of reading/writing/waiting connections.
Yes. Every open WebSocket client for a long time and mostly consumes upstream connection.
systemctl show nginx -p LimitNOFILE and check the /proc/PID/limits file of the running worker together.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.