Using NGINX limit_req to Shield APIs from Traffic Bursts
Learn how NGINX's limit_req module uses a leaky‑bucket filter to throttle API traffic, with a concrete configuration, trade‑offs, and verification steps.
Loading…
ReadMeFeed / Community knowledge
#limit-req
Real questions. Useful conversations. Find the people who know your stack.
nginxlimit_req burst smoothing or limit_conn hard cap for protecting an upstream during traffic spikes
I have an nginx reverse proxy in front of an application that serves large, expensive dataset queries. Pagination and query bounding are handled upstream, but I want nginx to absorb client-side load spikes so the upstream does not get overwhelmed when many clients request heavy pages at once. Two documented mechanisms seem relevant: limit_req with a zone, ra
nginx limit_req burst behavior: queued requests with nodelay vs without nodelay
Configuration goal I am configuring the limit_req module in nginx to throttle clients per IP using limit_req_zone with a rate of 10 r/s and burst=20 . I want excess requests to be absorbed rather than rejected, and I am deciding whether to add nodelay . Uncertainty My understanding is that with burst=20 and no nodelay , requests above the rate are queued and
limit_req_zone: per‑location burst limits and interaction with limit_conn
Goal To understand how nginx applies burst limits on a per‑location basis when using limit_req_zone and how these limits interact with limit_conn when both directives are enabled on the same location. Constraints & Uncertainty The limit_req_zone directive defines a shared memory zone and a global rate; it does not expose a burst parameter inside the zone