Mastering Nginx Rate Limiting: Production‑Ready Strategies

Why Nginx Rate Limiting Matters

Nginx rate limiting is a key technique for keeping web services stable; it uses the Leaky Bucket algorithm to control request rates and concurrent connections, preventing backend overload from traffic spikes or malicious attacks.

Core Benefits

Handles normal traffic peaks by smoothing request rates.

Defends against malicious traffic such as CC attacks, DDoS, and brute‑force attempts.

Protects resources by preventing a single user from monopolizing connections or bandwidth.

Rate limiting should be part of a defense‑in‑depth strategy together with firewalls, WAFs, and CDN/DDoS protection.

Basic Configuration

http {
    # Allow up to 10 requests per second per IP
    limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
    server {
        location /login/ {
            limit_req zone=ip_limit;
            proxy_pass http://login_upstream;
        }
    }
}

Key points :

$binary_remote_addr – IP address used as the limiting key.

zone=ip_limit:10m – Allocates 10 MB memory (≈80 k states on a 64‑bit system).

rate=10r/s – Allows one request every 100 ms on average.

Effect : With 10 simultaneous requests, one is processed immediately and the others are rejected (default 503).

Allowing Bursts (burst)

location /login/ {
    limit_req zone=ip_limit burst=12;
    proxy_pass http://login_upstream;
}

Requests are queued; the first request is processed instantly, the rest are handled at the configured rate. Drawback: added latency.

Instant Release (nodelay)

location /login/ {
    limit_req zone=ip_limit burst=12 nodelay;
}

All burst requests are processed immediately, improving user experience but risking short‑term backend overload.

Smoothing Bursts (delay)

location /login/ {
    limit_req zone=ip_limit burst=12 delay=4;
}

The first four requests are executed instantly; the remaining six enter a queue and are processed evenly. Suitable for balancing experience and backend load.

Strategy Comparison

Basic rate limiting offers strict backend protection but may reject legitimate spikes. Adding burst prevents request loss at the cost of latency. Combining burst with nodelay gives the best user experience but can overwhelm the backend. Using burst with delay provides a middle ground, smoothing traffic while keeping latency reasonable.

Advanced Protection Techniques

1. Limit Concurrent Connections (limit_conn)

http {
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    server {
        limit_conn conn_per_ip 10;
        location /download/ {
            limit_conn conn_per_ip 1;
            limit_rate_after 10m;
            limit_rate 100k;
        }
    }
}

Useful for large file downloads and HTTP/2/3 where each request counts as a connection.

2. Drop Malicious Requests (444)

if ($http_user_agent ~* (BadBot|Scanner|Spammer)) {
    return 444;
}

Custom status 444 closes the connection without a response, saving resources.

3. Custom Return Codes and Logging

http {
    limit_req_status 429;   # default 503, 429 is recommended
    limit_conn_status 429;
    limit_req_log_level warn;
    log_format main '$remote_addr $status req=$limit_req_status conn=$limit_conn_status rt=$request_time';
    access_log /var/log/nginx/access.log main;
}

Variables $limit_req_status and $limit_conn_status indicate request outcomes.

4. Whitelist and Split Limiting

geo $whitelist {
    default 0;
    10.0.0.0/8 1;
    192.168.0.0/16 1;
}
map $whitelist $lim_key {
    1 "";
    0 $binary_remote_addr;
}
limit_req_zone $lim_key zone=ip_limit:10m rate=10r/s;

Internal networks and monitoring IPs can be excluded from rate limiting.

5. API‑Key Prioritized Limiting

map $http_x_api_key $client_key {
    "" $binary_remote_addr;
    default $http_x_api_key;
}
limit_req_zone $client_key zone=per_client:20m rate=20r/s;

Prevents a shared NAT IP from being unfairly penalized.

6. Identifying Malicious Traffic via Logs

# Top 10 IPs
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10
# Top 20 URLs
awk '{print $7}' access.log | sort | uniq -c | sort -nr | head -20
# Requests in a specific hour
grep '21/Aug/2025:14' access.log | wc -l

Deployment and Tuning Workflow

Analyze traffic patterns – collect logs first.

Dry‑run mode – enable limit_req_dry_run on; and limit_conn_dry_run on; to observe without blocking.

Gradually tighten limits – test before fully enforcing.

Load testing – e.g., ab -n 1000 -c 20 https://your.domain/login/.

Monitor and iterate – use $limit_req_status, $limit_conn_status to track throttling ratios.

Safe reload – nginx -t && nginx -s reload.

Key Takeaways

Sensitive endpoints (login, captcha): small burst + nodelay for strict protection.

Regular APIs: larger burst + delay for smooth experience.

Large file downloads: combine limit_conn and limit_rate.

Whitelist and API‑key splitting reduce false positives.

Prefer returning 429 so clients understand the limit.

Memory estimate: on 64‑bit systems, 1 MB holds roughly 8 k states.

Use dry‑run first, then roll out to production.