Common Nginx Configuration Mistakes That Hurt Performance

Nginx is fast by default, which paradoxically means a lot of site owners never revisit their configuration after initial setup — and slowly accumulate mistakes that quietly eat into performance. Here are the most common Nginx misconfigurations we see, and how to fix each one.

Not Enabling Gzip or Brotli Compression

This is the single most common oversight. Without compression, text-based responses (HTML, CSS, JS, JSON) are sent at full size, wasting bandwidth and slowing transfer time unnecessarily. Adding a basic gzip block to your config is a five-minute fix with an immediate, measurable impact:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1000;

Brotli offers even better compression ratios than gzip for supported browsers, though it requires an additional Nginx module that isn't compiled in by default on all distributions.

Missing or Incorrect Cache Headers for Static Assets

Without explicit cache headers, browsers may re-request unchanged static files (images, CSS, JS) on every visit, adding unnecessary load and latency. Set long cache lifetimes for versioned static assets:

location ~* \.(css|js|jpg|jpeg|png|gif|ico|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Worker Process Count Not Matching CPU Cores

By default, some Nginx installations don't automatically detect and match worker processes to available CPU cores. Setting worker_processes auto; lets Nginx determine this correctly, rather than leaving it at a low fixed number that underutilizes a multi-core server.

Keepalive Timeout Misconfiguration

Keepalive connections avoid the overhead of re-establishing a TCP connection for every request from the same client. Setting the timeout too low forces unnecessary reconnections; setting it too high ties up worker connections for idle clients. A reasonable middle ground (keepalive_timeout 15s to 30s) works for most use cases, but should be tuned based on actual traffic patterns.

Missing Rate Limiting on Sensitive Endpoints

Login pages, search endpoints, and API routes without rate limiting are vulnerable to both abuse and accidental overload from misbehaving clients or bots. Nginx's limit_req module allows you to cap request rates per client IP:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location /login {
    limit_req zone=login burst=3;
}

No Reverse Proxy Buffering Tuning

When Nginx sits in front of an application server (Node.js, PHP-FPM, etc.), default proxy buffer sizes may not be appropriate for your actual response sizes, leading to unnecessary disk writes for buffering large responses, or truncated data for undersized buffers. Tune proxy_buffer_size and proxy_buffers based on your typical response payload sizes.

Serving Static Files Through the Application Instead of Nginx Directly

A surprisingly common mistake is letting requests for static assets (images, CSS, JS) pass through to the application server instead of being served directly by Nginx. This adds unnecessary overhead — Nginx is dramatically faster at serving static files than most application frameworks, and this alone can meaningfully reduce load on your application servers.

Not Setting Appropriate Client Body Size Limits

The default client_max_body_size may be too small for legitimate use cases (file uploads) or, in the opposite direction, left too large in a way that makes your server more vulnerable to resource exhaustion attacks. Set this explicitly based on your actual upload requirements rather than leaving it at whatever the distribution default happens to be.

Ignoring HTTP/2 (or HTTP/3)

If you're still running plain HTTP/1.1, you're missing out on multiplexing benefits that reduce the overhead of multiple concurrent requests. Enabling HTTP/2 (and increasingly HTTP/3 with QUIC) is usually a straightforward configuration change with real performance benefits for pages loading many assets.

The Bottom Line

Most Nginx performance issues aren't about needing more powerful hardware — they're about configuration defaults that were never revisited after initial setup. A periodic audit of your Nginx config against this list can uncover meaningful performance gains without touching your application code at all.