Master Nginx Rate Limiting: From Basic Leaky Bucket to Burst and NoDelay

This article provides a step‑by‑step example that supplements the official Nginx documentation by explaining rate‑limiting configurations.

Nginx rate limiting uses the leaky‑bucket algorithm; you can read about it on Wikipedia if interested.

Empty Bucket

We start with the simplest rate‑limiting configuration:

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;
    }
}

$binary_remote_addr limits by client IP.

zone=ip_limit:10m creates a zone named ip_limit using 10 MB of memory to store per‑IP state.

rate=10r/s sets the limit to ten requests per second.

location /login/ applies the limit to the login endpoint.

With this configuration the bucket is empty, so any request that cannot be released immediately is rejected. If ten requests arrive simultaneously, only one is processed while the others are denied, which is often undesirable.

The leaky bucket releases requests at a uniform rate; 10r/s means one request every 100 ms. Because the bucket is empty, excess requests are dropped.

Burst

We modify the configuration to solve the previous problem:

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;

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

burst=12 sets the bucket size to 12.

Logically this is a leaky bucket implemented as a FIFO queue that temporarily stores requests that cannot be executed immediately. The release speed remains one request per 100 ms, but concurrent requests are queued until the bucket is full, after which new requests are rejected. This also smooths traffic spikes.

With this setting, ten simultaneous requests are processed one every 100 ms, but the added queuing increases latency, which may still be unacceptable for some scenarios.

NoDelay

We further adjust the configuration to eliminate the delay caused by queuing:

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;

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

nodelay makes a request start immediately once it enters the bucket, instead of waiting for the leaky‑bucket interval.

Now a request is either executed immediately or rejected; rate‑limiting no longer adds extra latency. Because the bucket still releases at a uniform rate and its capacity is fixed, the average throughput remains the same (10 r/s), achieving the limiting goal.

The downside is that the traffic is no longer evenly spaced: up to 12 requests can be processed instantly, after which subsequent requests are spaced by 100 ms. If the bucket becomes empty after a quiet period, another burst of up to 12 concurrent requests can occur.

Nginx also provides a delay parameter to control how many requests are allowed to execute without delay.

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;

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

delay=4 starts delaying from the 5th request onward.

By adjusting the delay value you can limit the number of concurrent executions, making request handling more uniform—useful for resource‑intensive services.