{"id":89,"date":"2026-07-15T00:00:00","date_gmt":"2026-07-15T00:00:00","guid":{"rendered":"http:\/\/\/var\/www\/html\/?p=89"},"modified":"2026-07-21T01:02:34","modified_gmt":"2026-07-21T01:02:34","slug":"nginx-workers-connection-limit-reached-workerconnections-on-centos-stream-rocky-linux","status":"publish","type":"post","link":"https:\/\/butitworkedlocal.com\/nginx-workers-connection-limit-reached-workerconnections-on-centos-stream-rocky-linux\/","title":{"rendered":"Troubleshooting ‘Nginx workers connection limit reached’ on CentOS Stream \/ Rocky Linux"},"content":{"rendered":"\n

Resolve Nginx connection limit errors on CentOS Stream & Rocky Linux. Learn to tune worker_connections, file descriptors, and kernel parameters for high traffic.<\/strong><\/p>\n\n\n

When your Nginx web server experiences heavy traffic or misconfiguration, you might encounter issues where new connections are dropped, requests time out, or users see "502 Bad Gateway" or "503 Service Unavailable" errors. A common underlying cause on high-load systems is hitting the Nginx worker connection limit, leading to performance degradation or complete service interruption. This guide will walk you through diagnosing and resolving this critical issue on CentOS Stream and Rocky Linux environments.<\/p>\n

Symptom & Error Signature<\/h3>\n

Users will typically experience slow page loads, connection refused errors, or HTTP 502\/503 status codes. In the Nginx error logs, usually found at \/var\/log\/nginx\/error.log<\/code>, you will observe messages similar to these:<\/p>\n

2023\/10\/26 14:35:01 [alert] 1234#1234: *1234567 too many open files: 1024, max_connections: 1024 (client: 192.168.1.1, server: example.com, request: "GET \/ HTTP\/1.1", host: "example.com")\n2023\/10\/26 14:35:02 [alert] 1234#1234: *1234568 worker_connections are not enough while connecting to upstream (X.X.X.X:80)\n2023\/10\/26 14:35:03 [crit] 1235#1235: *1234569 accept() failed (24: Too many open files)\n<\/code><\/pre>\n
These error messages clearly indicate that Nginx workers are unable to establish new connections, either due to their own configured limits or system-wide file descriptor constraints.<\/p>\n
Root Cause Analysis<\/h3>\n
The "Nginx workers connection limit reached" error typically stems from one or more of the following underlying issues:<\/p>\n
    \n
  1. Insufficient worker_connections<\/code>:<\/strong> This is the most direct cause. The worker_connections<\/code> directive in nginx.conf<\/code> defines the maximum number of simultaneous connections that a single Nginx worker process can handle. If the aggregate capacity (worker_processes * worker_connections<\/code>) is lower than the actual peak concurrent connections, Nginx will drop new requests.<\/li>\n
  2. Too Few worker_processes<\/code>:<\/strong> While worker_connections<\/code> limits individual workers, worker_processes<\/code> determines how many workers Nginx spawns. If this value is too low, the server might not fully utilize available CPU cores, bottlenecking processing capacity even if worker_connections<\/code> is high per worker.<\/li>\n
  3. System-wide File Descriptor Limits (ulimit -n<\/code>):<\/strong> Nginx is a file descriptor (FD)-intensive application. Each client connection, as well as connections to upstream servers, uses at least one file descriptor. If the operating system's per-process file descriptor limit (ulimit -n<\/code>) for the Nginx process is lower than its configured worker_connections<\/code>, Nginx will fail with "Too many open files" errors before reaching its internal connection limit.<\/li>\n
  4. Kernel TCP Backlog Limits (net.core.somaxconn<\/code>, net.ipv4.tcp_max_syn_backlog<\/code>):<\/strong> These kernel parameters control the maximum length of the queue for pending TCP connections. If Nginx processes established connections slower than new connections arrive, these queues can overflow, leading to dropped connections even before Nginx can accept them, often presenting as connection resets on the client side.<\/li>\n
  5. Upstream Server Bottlenecks:<\/strong> If Nginx is configured as a reverse proxy, a slow or overloaded upstream application server (e.g., PHP-FPM, Node.js app, Tomcat) can cause Nginx worker processes to wait for responses, holding open connections and thereby exhausting the worker_connections<\/code> pool prematurely.<\/li>\n<\/ol>\n
    Step-by-Step Resolution<\/h3>\n
    Follow these steps to diagnose and resolve the Nginx worker connection limit issue.<\/p>\n
    1. Analyze Current Nginx & System Configuration<\/h4>\n
    Before making changes, understand your current settings:<\/p>\n
    First, identify the Nginx master process ID:<\/p>\n
    sudo systemctl status nginx | grep Main PID\n# Example output: Main PID: 1234 (nginx)\n<\/code><\/pre>\n
    Replace 1234<\/code> with your Nginx master PID in subsequent commands.<\/p>\n
      \n
    • Check Nginx worker_processes<\/code> and worker_connections<\/code>:<\/strong>
      grep -E 'worker_processes|worker_connections' \/etc\/nginx\/nginx.conf\n<\/code><\/pre>\n<\/li>\n
    • Check Nginx process's file descriptor limit:<\/strong>
      cat \/proc\/$(sudo systemctl show --property MainPID nginx | cut -d= -f2)\/limits | grep 'Max open files'\n<\/code><\/pre>\nCompare this "Max open files" (soft limit) with your worker_connections<\/code> value. worker_connections<\/code> must be less than or equal to this limit.<\/li>\n
    • Check system-wide kernel TCP backlog settings:<\/strong>
      sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog\n<\/code><\/pre>\n<\/li>\n<\/ul>\n
      2. Adjust Nginx worker_connections<\/code> and worker_processes<\/code><\/h4>\n
      Modify the Nginx main configuration file, typically \/etc\/nginx\/nginx.conf<\/code>.<\/p>\n
        \n
      1. Open the Nginx configuration file:<\/strong><\/p>\n
        sudo vi \/etc\/nginx\/nginx.conf\n<\/code><\/pre>\n<\/li>\n
      2. Adjust worker_processes<\/code> and worker_connections<\/code>:<\/strong>\nLocate the worker_processes<\/code> and events<\/code> blocks.<\/p>\n
          \n
        • Set worker_processes<\/code> to auto<\/code> to allow Nginx to detect the optimal number of processes based on CPU cores, or explicitly to the number of CPU cores available on your server.<\/li>\n
        • Significantly increase worker_connections<\/code>. A common starting point for high-traffic sites is 10240<\/code> or 20480<\/code>. You can go higher, but remember each connection consumes some memory.<\/li>\n
        • Consider adding multi_accept on;<\/code> in the events<\/code> block. This tells a worker process to accept as many new connections as possible at once, rather than one by one, which can be beneficial under very high load.<\/li>\n<\/ul>\n
          # \/etc\/nginx\/nginx.conf\n\nuser  nginx;\nworker_processes  auto; # Set to 'auto' or the number of CPU cores (e.g., 4, 8)\n\nerror_log  \/var\/log\/nginx\/error.log warn;\npid        \/run\/nginx.pid;\n\nevents {\n    worker_connections  20480; # Increase this value significantly (e.g., 10240, 20480, 40960)\n    multi_accept        on;    # Optional: Enable multiple connection accepts per worker\n}\n\nhttp {\n    include       \/etc\/nginx\/mime.types;\n    default_type  application\/octet-stream;\n\n    # ... other http directives ...\n}\n<\/code><\/pre>\n<\/li>\n
        • Test Nginx configuration:<\/strong><\/p>\n
          sudo nginx -t\n<\/code><\/pre>\n
          Ensure you see syntax is ok<\/code> and test is successful<\/code>.<\/p>\n<\/li>\n
        • Reload Nginx service:<\/strong><\/p>\n
          sudo systemctl reload nginx\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
          The total number of concurrent connections Nginx can theoretically handle is worker_processes * worker_connections<\/code>. Ensure this value is adequate for your anticipated peak traffic but also mindful of your server's RAM and CPU resources. A common guideline is to set worker_connections<\/code> to at least 2 * UlimitNOFILE<\/code> to account for both client and upstream connections.<\/p>\n<\/blockquote>\n
          3. Increase System-wide File Descriptor Limits (ulimit)<\/h4>\n
          The Nginx process's file descriptor limit must be equal to or greater than its worker_connections<\/code> setting. We'll modify the Systemd service unit for Nginx to achieve this.<\/p>\n
            \n
          1. Create or edit the Nginx Systemd override file:<\/strong><\/p>\n
            sudo systemctl edit nginx\n<\/code><\/pre>\n
            This will open a file like \/etc\/systemd\/system\/nginx.service.d\/override.conf<\/code>.<\/p>\n<\/li>\n
          2. Add the LimitNOFILE<\/code> directive:<\/strong>\nAdd the following lines to the file, setting LimitNOFILE<\/code> to a value higher than your worker_connections<\/code> (e.g., 65536<\/code> or 131072<\/code>).<\/p>\n
            [Service]\nLimitNOFILE=65536\n<\/code><\/pre>\n<\/li>\n
          3. Save and exit.<\/strong><\/p>\n<\/li>\n
          4. Reload the Systemd daemon:<\/strong><\/p>\n
            sudo systemctl daemon-reload\n<\/code><\/pre>\n<\/li>\n
          5. Restart Nginx to apply changes:<\/strong><\/p>\n
            sudo systemctl restart nginx\n<\/code><\/pre>\n<\/li>\n
          6. Verify the new ulimit<\/code> for the Nginx process:<\/strong><\/p>\n
            cat \/proc\/$(sudo systemctl show --property MainPID nginx | cut -d= -f2)\/limits | grep 'Max open files'\n<\/code><\/pre>\n
            The soft<\/code> and hard<\/code> limits should now reflect the LimitNOFILE<\/code> you set.<\/p>\n<\/li>\n<\/ol>\n
            While increasing LimitNOFILE<\/code> allows Nginx to handle more connections, setting it excessively high without sufficient RAM can lead to memory exhaustion and system instability. Start with 65536<\/code> or 131072<\/code> and monitor your server's performance.<\/p>\n<\/blockquote>\n
            4. Tune Kernel TCP Backlog Parameters<\/h4>\n
            Adjusting kernel parameters can help the system handle bursts of new connections more gracefully.<\/p>\n
              \n
            1. Create or edit a custom sysctl<\/code> configuration file:<\/strong><\/p>\n
              sudo vi \/etc\/sysctl.d\/90-custom.conf\n<\/code><\/pre>\n
              (You can also use \/etc\/sysctl.conf<\/code>, but .d<\/code> files are cleaner for custom settings).<\/p>\n<\/li>\n
            2. Add or modify the following parameters:<\/strong><\/p>\n
              # Maximum number of connections that can be queued for a listening socket\nnet.core.somaxconn = 65535\n\n# Maximum number of SYN requests that the kernel will keep in memory\nnet.ipv4.tcp_max_syn_backlog = 8192\n\n# Allow reusing sockets in TIME_WAIT state for new connections (can help with port exhaustion)\nnet.ipv4.tcp_tw_reuse = 1\n\n# Reduce TIME_WAIT state duration (for faster socket cleanup)\nnet.ipv4.tcp_fin_timeout = 30\n<\/code><\/pre>\n<\/li>\n
            3. Save and exit.<\/strong><\/p>\n<\/li>\n
            4. Apply the sysctl<\/code> changes:<\/strong><\/p>\n
              sudo sysctl -p \/etc\/sysctl.d\/90-custom.conf\n<\/code><\/pre>\n
              (Or sudo sysctl -p<\/code> if you edited \/etc\/sysctl.conf<\/code>).<\/p>\n<\/li>\n
            5. Verify the new kernel parameters:<\/strong><\/p>\n
              sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_tw_reuse net.ipv4.tcp_fin_timeout\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
              net.core.somaxconn<\/code> affects the listen<\/code> directive's backlog<\/code> parameter in Nginx. net.ipv4.tcp_max_syn_backlog<\/code> is crucial for preventing SYN flood attacks and managing a high rate of new connection attempts. These values should be adjusted incrementally based on your specific traffic patterns and monitoring.<\/p>\n<\/blockquote>\n
              5. Monitor and Optimize<\/h4>\n
              After implementing these changes, continuous monitoring is crucial to ensure stability and optimal performance.<\/p>\n
                \n
              • Monitor Nginx error logs:<\/strong> Keep an eye on \/var\/log\/nginx\/error.log<\/code> for any new connection-related errors.<\/li>\n
              • System resource monitoring:<\/strong> Use tools like atop<\/code>, htop<\/code>, dstat<\/code>, or grafana\/prometheus<\/code> to monitor CPU, memory, and network usage.<\/li>\n
              • Network statistics:<\/strong>
                  \n
                • Check for connections in various states: netstat -nat | awk '{print $NF}' | sort | uniq -c | sort -nr<\/code><\/li>\n
                • Summarize network statistics: ss -s<\/code><\/li>\n<\/ul>\n<\/li>\n
                • Nginx Stub Status Module:<\/strong> If enabled, monitor Nginx's active connections and requests per second:
                  curl -s http:\/\/localhost\/nginx_status\n<\/code><\/pre>\n(Requires stub_status<\/code> to be enabled in your Nginx configuration, e.g., in a server block: location \/nginx_status { stub_status on; allow 127.0.0.1; deny all; }<\/code>).<\/li>\n
                • Further Nginx Optimization:<\/strong>
                    \n
                  • Consider keepalive_timeout<\/code> and keepalive_requests<\/code> if your application benefits from persistent connections.<\/li>\n
                  • Optimize proxy buffering settings (proxy_buffering<\/code>, proxy_buffers<\/code>, proxy_buffer_size<\/code>) if Nginx is a reverse proxy.<\/li>\n
                  • Ensure your upstream application servers (e.g., PHP-FPM, uWSGI, Node.js) are also adequately scaled and configured to handle the increased load Nginx is now passing to them.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
                    By systematically adjusting Nginx configuration and underlying OS limits, you can significantly improve your server's ability to handle high concurrent connections, ensuring a more stable and responsive web service.<\/p>\n","protected":false},"excerpt":{"rendered":"
                    Resolve Nginx connection limit errors on CentOS Stream & Rocky Linux. Learn to tune worker_connections, file descriptors, and kernel parameters for high traffic.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[242,55,23,172,201,56,6,241],"class_list":["post-89","post","type-post","status-publish","format-standard","hentry","category-web-server","tag-centos-stream","tag-nginx","tag-performance","tag-rocky-linux","tag-sysctl","tag-systemd","tag-troubleshooting","tag-worker_connections"],"_links":{"self":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/89","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/comments?post=89"}],"version-history":[{"count":2,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/89\/revisions"}],"predecessor-version":[{"id":337,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/89\/revisions\/337"}],"wp:attachment":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/media?parent=89"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/categories?post=89"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/tags?post=89"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}