limit_req_zone and limit_req in Nginx - Step-by-Step Execution

Process Flow - limit_req_zone and limit_req

Define limit_req_zone

↓

Store request rate info

↓

Incoming request

↓

Check request rate

↓

Allow request

↓

Serve response

First, we define a zone to track request rates. Then each incoming request is checked against this zone. If the rate is within limits, the request proceeds; if not, it is delayed or rejected.

Execution Sample

Nginx

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

server {
  location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
  }
}

This config limits requests from each IP to 1 request per second with a burst of 5 requests allowed immediately.

Process Table

Step	Request Number	Client IP	Current Rate (r/s)	Action	Result
1	1	192.168.1.10	0.0	Allow	Request served immediately
2	2	192.168.1.10	1.0	Allow	Request served immediately
3	3	192.168.1.10	2.0	Burst allowed	Request served immediately (burst)
4	4	192.168.1.10	3.0	Burst allowed	Request served immediately (burst)
5	5	192.168.1.10	4.0	Burst allowed	Request served immediately (burst)
6	6	192.168.1.10	5.0	Burst allowed	Request served immediately (burst)
7	7	192.168.1.10	6.0	Reject	429 Too Many Requests
8	1	10.0.0.5	0.0	Allow	Request served immediately

💡 Request 7 from 192.168.1.10 exceeds burst limit, so it is rejected with 429 error.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7
Current Rate (r/s) for 192.168.1.10	0.0	1.0	2.0	3.0	4.0	5.0	6.0	6.0
Burst Used	0	0	1	2	3	4	5	5

Key Moments - 3 Insights

Why are the first 6 requests allowed even though the rate exceeds 1r/s?

Because the 'burst=5' setting allows up to 5 extra requests to be served immediately beyond the rate limit, as shown in rows 3 to 6 of the execution_table.

What happens when the burst limit is exceeded?

The request is rejected with a 429 error, as seen in step 7 where the burst used reaches 5 and the next request is denied.

Why does the rate reset for a different IP address?

Because limit_req_zone tracks rates per client IP ($binary_remote_addr), so a new IP starts with zero rate, shown in step 8.

Visual Quiz - 3 Questions

Look at the execution_table, what is the action taken at request number 4 from IP 192.168.1.10?

A Reject the request

B Allow the request immediately using burst

C Delay the request

D Ignore the request

💡 Hint

Check row 4 in the execution_table under 'Action' column.

At which request number does the client 192.168.1.10 get rejected due to exceeding limits?

A 5

B 6

C 7

D 8

💡 Hint

Look for the first 'Reject' action in the execution_table for 192.168.1.10.

If the 'burst' was set to 3 instead of 5, what would happen at request number 6?

A Request 6 would be rejected

B Request 6 would be delayed

C Request 6 would be allowed immediately

D Request 6 would be ignored

💡 Hint

Compare burst usage in variable_tracker and relate to burst limit.

Concept Snapshot

limit_req_zone defines a shared memory zone to track request rates by key (e.g., IP).
limit_req applies rate limiting using that zone in a location.
'burst' allows extra requests beyond the rate to be served immediately.
Requests exceeding burst are delayed or rejected (429).
Use to protect servers from too many requests quickly.

Full Transcript

This visual execution shows how nginx's limit_req_zone and limit_req work together to limit request rates per client IP. First, limit_req_zone defines a memory zone to track request rates keyed by client IP. Then, limit_req in a location uses that zone to check each incoming request. If the request rate is within the limit, the request is allowed immediately. If the rate exceeds the limit but is within the burst allowance, the request is still allowed immediately. Once the burst limit is exceeded, requests are rejected with a 429 error. Different client IPs have separate rate tracking. This protects the server from too many requests in a short time.