Rate limit requests in nginx

The fix/etc/nginx/nginx.conf

http {
    limit_req_zone $binary_remote_addr zone=general:10m rate=20r/s;
    limit_req_zone $binary_remote_addr zone=login:10m   rate=5r/m;
    limit_req_status 429;

    server {
        location / {
            limit_req zone=general burst=40 nodelay;
        }
        location /login {
            limit_req zone=login burst=3 nodelay;
        }
    }
}

The gotcha that makes this useless

Read this before deploying anything above.

$binary_remote_addr is the address of whoever opened the TCP connection. If nginx sits behind Cloudflare, an ALB, or any reverse proxy, that is the proxy’s address — not the user’s.

The result is the opposite of what you wanted. Every visitor shares one bucket, so a burst of legitimate traffic trips the limit for everybody at once, while an attacker is throttled no more than anyone else. You have built a self-inflicted outage and called it protection.

Fix it by teaching nginx which address to trust:

set_real_ip_from 10.0.0.0/8;        # your load balancer's range
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Then $binary_remote_addr becomes the client address and the limits mean something.

set_real_ip_from must list only proxies you actually control. It tells nginx to believe a header, and X-Forwarded-For is trivially forged. Trust it from an arbitrary source and an attacker sets their own address per request, giving themselves an unlimited rate — a rate limiter that any client can opt out of.

Why this is low severity

Rate limiting is not an access control. It closes no exposure and stops no attacker who has a valid credential or a botnet with many addresses.

What it genuinely buys you:

• Origin protection. Your PHP-FPM pool or upstream app has a finite worker count; nginx can absorb far more concurrency than it can. limit_req keeps a crawler from exhausting the thing behind it.
• Slower credential stuffing. 5r/m on /login makes online password guessing impractical. That’s real, and it’s why the login zone is separate.

What it does not buy you: protection from a real DDoS (that has to be absorbed upstream of your server, by a network that can hold the volume), or a substitute for authentication.

burst and nodelay

The two parameters everyone gets wrong:

• rate=20r/s is enforced per millisecond internally — 20r/s means one request every 50ms, not 20 arriving together. Without burst, a page loading 15 assets at once gets rejected immediately.
• burst=40 allows a queue of 40 beyond the rate.
• nodelay serves that burst immediately rather than spacing it out. Without nodelay, excess requests are delayed to fit the rate, which turns a fast page into a slow one and looks like your server is broken.

For web traffic you almost always want burst with nodelay. Without both, the limiter fires on ordinary page loads.

limit_req_status 429 is worth setting: nginx returns 503 by default, which tells clients and CDNs “server error” rather than “you are being rate limited”. 429 is the correct code and well-understood by every HTTP client.

Verify it worked

Confirm nginx sees real client addresses — do this first, because everything else depends on it:

log_format realip '$remote_addr real=$realip_remote_addr xff="$http_x_forwarded_for"';
access_log /var/log/nginx/realip.log realip;

awk '{print $1}' /var/log/nginx/realip.log | sort | uniq -c | sort -rn | head

If a handful of addresses account for all traffic, those are your proxies and real_ip is not configured — your limits are per-proxy, not per-client.

Then prove the limit fires:

for i in $(seq 1 30); do
  curl -s -o /dev/null -w '%{http_code} ' https://your.site/login
done; echo

Expect 200s then 429s. All 200 means the limit isn’t applying; immediate 429 means it’s far too tight.

Watch rejections in the log:

sudo grep -c 'limiting requests' /var/log/nginx/error.log

Before you apply this

Rate limiting is the easiest way on this list to take your own site down, and the damage is invisible in your metrics — it looks like a traffic drop, not an error.

Three specific traps:

The shared-address problem is real. Offices, universities, mobile carrier NAT and VPNs put hundreds of genuine users behind one address. A limit that seems generous per person is instantly hit by a NAT’d campus.

Deploy it in observation mode first. There is no dry-run flag, but you can set a deliberately loose rate, log the rejections, and see who would have been hit:

sudo grep 'limiting requests' /var/log/nginx/error.log | \
  grep -oE 'client: [0-9.]+' | sort | uniq -c | sort -rn | head -20

If your own health check, CDN origin-fetch or monitoring appears there, tighten nothing until they’re excluded.

Exempt what must not be limited. Health checks and internal callers should bypass it:

geo $limit_exempt {
    default 0;
    10.0.0.0/8 1;
}
map $limit_exempt $limit_key {
    0 $binary_remote_addr;
    1 "";        # empty key = not counted
}
limit_req_zone $limit_key zone=general:10m rate=20r/s;

An empty key is excluded from the zone entirely — that’s the documented way to whitelist.

Related

• Add a default server block — dropping unwanted traffic before it costs anything.