Nginx Performance Tuning — Squeeze Every Request per Second from Your Reverse Proxy

Nginx's default configuration is conservative — designed to work on any hardware without exhausting resources. On a modern server, these defaults leave significant performance on the table. worker_connections 768 limits concurrent connections far below what the hardware can handle. sendfile off forces Nginx to copy files through userspace instead of using the kernel's zero-copy mechanism. Compression is disabled by default, sending uncompressed responses that waste bandwidth and increase load times.

The reverse proxy defaults are similarly conservative. proxy_buffering settings are too small for modern applications that return large JSON responses. proxy_connect_timeout and proxy_read_timeout defaults may not match your application's response characteristics. Keepalive connections to upstream servers are not enabled by default, forcing a new TCP connection for every proxied request — adding 1-3ms of latency to every request.

Tuning Nginx is not about cranking every number to maximum. It is about understanding your traffic pattern — request sizes, response sizes, connection duration, concurrent connections — and configuring Nginx to handle that specific pattern efficiently.

Worker Configuration: We set worker_processes auto to match CPU cores and worker_connections to 4096-16384 depending on available file descriptors. We increase worker_rlimit_nofile to match and set the system's ulimit accordingly. For event-driven workloads (WebSocket, long polling), we use the epoll method explicitly and enable multi_accept.

Compression: We enable gzip for text-based content types (HTML, CSS, JavaScript, JSON, SVG, XML) with gzip_comp_level 5 (the sweet spot between compression ratio and CPU cost). For modern browsers, we configure Brotli compression via the ngx_brotli module, which achieves 15-20% better compression than gzip at equivalent CPU cost. Static assets are pre-compressed at build time so Nginx serves .br and .gz files without runtime compression.

Upstream Keepalive: We configure keepalive connections to upstream servers (your application instances). Instead of opening a new TCP connection for every proxied request, Nginx reuses connections from a pool. We set keepalive 32 (or more based on traffic volume) and configure proxy_http_version 1.1 with proxy_set_header Connection "" to enable HTTP/1.1 keepalive to the upstream.

Buffering: We tune proxy_buffer_size, proxy_buffers, and proxy_busy_buffers_size based on your application's typical response sizes. For APIs returning large JSON payloads, we increase buffer sizes to prevent Nginx from writing to temporary files. For streaming responses (SSE, file downloads), we configure proxy_buffering off on the relevant locations.

Caching: We configure proxy_cache for responses that benefit from edge caching. Cache keys include the request URI and relevant headers (e.g., Accept-Encoding for varied compression). Cache purge is wired into the deployment pipeline. For static assets, we set expires max to enable browser caching with long TTLs.

Security Headers: As part of the configuration, we add security headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy, and Strict-Transport-Security. These do not affect performance but are essential for production Nginx deployments.

A production-tuned Nginx configuration:

• Worker tuning — processes, connections, and file descriptor limits matched to your hardware
• Compression — gzip and Brotli with pre-compressed static assets
• Upstream optimization — keepalive connection pooling to your application servers
• Buffer tuning — buffer sizes matched to your response characteristics
• Proxy caching — response caching with invalidation wired to deployments
• SSL/TLS optimization — TLS 1.3, OCSP stapling, session tickets, and optimized cipher suites
• Security headers — HSTS, CSP, X-Frame-Options, and other security headers
• Performance benchmarks — before/after throughput and latency measurements