In nginx, how does `limit_req_zone` with `rate=10r/s` actually meter requests, and what do the `burst` and `nodelay` parameters on `limit_req` change about which clients get rejected?

## The two directives Rate limiting in nginx needs two things: a place to keep counters, and a rule that uses them. ```nginx http { limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; server { location /api/ { limit_req zone=api burst=20 nodelay; proxy_pass http://backend; } } } ``` `limit_req_zone` lives in the `http` context and takes three things: the **key** (any nginx variable — here the client address in binary form), the **zone** name and size, and the **rate**. `limit_req` then applies that zone in `http`, `server` or `location` context. The zone is a *shared memory* region: all worker processes read and write the same counters, so the limit is per nginx instance, not per worker. Size matters — nginx documents roughly 16,000 64-byte states per megabyte for `limit_req`, so `10m` holds on the order of 160,000 distinct keys. When the zone fills, nginx evicts the least recently used entries, and if it still cannot make room it returns an error for the request. `$binary_remote_addr` is preferred over `$remote_addr` because it stores four bytes for IPv4 (sixteen for IPv6) instead of a text string, which materially changes how many clients fit in the zone. ## Leaky bucket, not "ten per second" The single most common misreading is treating `rate=10r/s` as a per-second quota that resets on a clock boundary. It does not. nginx converts the rate into a minimum interval between accepted requests for that key — 10r/s is one request per 100 ms, 30r/m is one request per two seconds. There is no window that resets; the bucket leaks continuously. So with a bare `limit_req zone=api;` and no burst, a browser that opens a page and fires eight parallel XHRs to the same host has *one* request served and seven rejected, even though the client's average rate over the next second is well under ten. That is why a naive rate limit tends to break real traffic while barely inconveniencing an attacker, whose requests are evenly paced by a script. ## What burst does `burst=N` attaches a queue of N slots to each key. Excess requests occupy a slot instead of being rejected, and nginx releases them at the zone's rate. Requests arriving when the queue is already full are rejected. The cost is **latency**. With `rate=10r/s burst=20` and 21 simultaneous requests, the last queued one waits about two seconds before nginx even proxies it. For a browser this shows up as a page that loads its assets in visible stages; for an API client with a two-second read timeout it shows up as a timeout that no backend log explains, because the backend never saw the request. ## What nodelay does `nodelay` changes only the *scheduling*, not the accounting. Burst slots are still taken and still drain back at the zone rate, but a request that gets a slot is forwarded straight away. The practical shape is: a client may spend its whole burst instantly, and then is held to the steady rate until slots free up. This is almost always what you want in front of a browser-facing or API endpoint: real clients are bursty and idle, abusers are sustained. Without `nodelay` you convert a rejection into a delay, which usually just moves the failure into someone's client timeout. Since nginx 1.15.7 you can split the difference: ```nginx limit_req zone=api burst=20 delay=8; ``` The first 8 excess requests go through immediately; requests 9–20 of the burst are queued and paced; beyond that, rejected. ## Rejection behaviour Rejected requests get **503 Service Unavailable** by default. `limit_req_status 429;` changes that, which is worth doing so callers and your own dashboards can tell a limit from a genuine outage. `limit_req_log_level warn;` (default `error`) controls the log line, and every rejection *is* logged — a badly tuned limit is a fast way to fill a disk. Several `limit_req` directives may apply at once; all configured limits are checked and a request is rejected if it trips any of them. That is how you stack a per-IP limit with a coarser per-server limit. ## Reading it back in practice When someone reports intermittent 503s, the first check is the error log for `limiting requests, excess: ... by zone "..."`. The excess figure tells you how far over the bucket the client was, which is what you tune `burst` against. If the reports are of *slowness* rather than errors, suspect a `burst` without `nodelay`.