nginx worker_connections tuning for high traffic

TL;DR

workerconnections caps the connections each nginx worker handles; the right value is derived from expected concurrent connections divided by worker processes, with headroom. But workerconnections alone is not the story: workerrlimitnofile must allow the file descriptors, and worker_processes should match CPU cores. Tune all three together or the limit you raised is not the limit that binds.

The query

nginx worker_connections tuning for high traffic

Use this when

• Nginx logs warn about too many open files or connection limits
• Preparing for known traffic spikes
• Capacity planning for the edge tier
• Connections get refused under load

Not for when

• Upstream application performance
• TLS handshake optimization (related but separate)
• Choosing a load balancer

Steps

Step 1: Measure current connection patterns

Check active connections per worker during peak: the status module or logs give you the numbers. You need the peak concurrent connections, not the average; tuning for the average fails at the first spike. Expected output: peak connections per worker, measured, not guessed.

Step 2: Do the math

workerconnections should exceed peak connections per worker with headroom (2x is a sane start). workerprocesses typically equals CPU cores. Total capacity is workers times connections; make sure that product covers peak plus growth. Expected output: concrete numbers for workerprocesses and workerconnections with the reasoning written down.

Step 3: Raise the file descriptor limit to match

workerrlimitnofile must cover worker_connections times workers plus overhead, and the OS ulimit must allow it. This is the step everyone forgets: nginx configured for 10k connections but allowed 1024 file descriptors still caps at 1024. Expected output: file descriptor limits at every layer above the connection target.

Step 4: Tune keepalive to shape connection churn

Keepalive settings determine how long connections linger. For high traffic, keepalives reduce handshake overhead but hold connections; tune keepalive_timeout and upstream keepalive pools so idle connections do not eat the budget you just raised. Expected output: connection reuse high, idle connection waste low.

Step 5: Load test and watch the real limits

Test with realistic traffic and watch for the actual binding constraint: connection refused, file descriptor errors, or CPU saturation. The math gets you close; the load test tells you the truth. Expected output: a tested configuration with measured headroom, not a theoretical one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvyvIQZF6YLIUNHxnatyLA