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.

Practice

1. What is the main purpose of the limit_req_zone directive in nginx?

easy

A. To log requests that exceed the limit

B. To apply the rate limit rules to a specific location

C. To define the key and rate limit parameters for request limiting

D. To restart nginx when limits are reached

Solution

1. Step 1: Understand the role of limit_req_zone

   This directive sets the shared memory zone and key used to track requests for limiting.

2. Step 2: Differentiate from limit_req

   limit_req applies the rules, but limit_req_zone defines them.

3. Final Answer:

   To define the key and rate limit parameters for request limiting -> Option C

4. Quick Check:

   limit_req_zone defines limits [OK]

Hint: Remember: zone defines limits, limit_req applies them [OK]

Common Mistakes:

• Confusing limit_req_zone with limit_req
• Thinking it applies limits directly
• Assuming it logs requests

2. Which of the following is the correct syntax to define a rate limit zone named mylimit with 10MB memory and 5 requests per second per IP?

easy

A. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

B. limit_req_zone zone=mylimit:10m $binary_remote_addr rate=5r/s;

C. limit_req_zone $remote_addr zone=mylimit:5m rate=10r/s;

D. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/m;

Solution

1. Step 1: Check the correct order of parameters

   The syntax is limit_req_zone key zone=name:size rate=rate; so key first, then zone with name and size, then rate.

2. Step 2: Validate values

   $binary_remote_addr is preferred key, zone name is mylimit, size is 10m, rate is 5r/s (requests per second).

3. Final Answer:

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s; -> Option A

4. Quick Check:

   Correct syntax = limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s; [OK]

Hint: Syntax: key zone=name:size rate=numberr/s [OK]

Common Mistakes:

• Swapping zone and key order
• Using wrong memory size units
• Confusing rate units (r/s vs r/m)

3. Given this nginx config snippet:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
  location /api/ {
    limit_req zone=one burst=2;
  }
}

What happens if a client sends 4 requests instantly to /api/?

medium

A. All 4 requests are processed immediately

B. 1 request processed immediately, 2 delayed, 1 rejected

C. 1 request processed immediately, 3 rejected

D. All 4 requests rejected

Solution

1. Step 1: Understand rate and burst

   Rate is 1 request per second, burst=2 allows 2 extra requests to queue.

2. Step 2: Analyze 4 instant requests

   First request passes immediately, next 2 are delayed (burst), 4th exceeds burst and is rejected.

3. Final Answer:

   1 request processed immediately, 2 delayed, 1 rejected -> Option B

4. Quick Check:

   burst=2 allows 2 queued requests [OK]

Hint: burst allows extra queued requests before rejection [OK]

Common Mistakes:

• Assuming all requests pass immediately
• Ignoring burst parameter
• Thinking burst rejects requests

4. You configured:

limit_req_zone $binary_remote_addr zone=rlimit:10m rate=10r/s;
server {
  location / {
    limit_req zone=rlimit burst=5;
  }
}

But nginx logs show no rate limiting is applied. What is the likely error?

medium

A. Incorrect key used in limit_req_zone

B. The limit_req_zone directive must be inside server block

C. No nodelay option causing silent ignoring

D. Missing limit_req directive inside server block

Solution

1. Step 1: Check key correctness

   Using an incorrect key in limit_req_zone (e.g., $remote_addr instead of the preferred $binary_remote_addr) prevents proper rate limiting from being applied.

2. Step 2: Confirm directive placement

   limit_req_zone must be in http context, limit_req in server/location; placement here is correct.

3. Final Answer:

   Missing limit_req directive inside server block -> Option D

4. Quick Check:

   limit_req directive is required to apply limits [OK]

Hint: Check that limit_req directive is present inside server/location block [OK]

Common Mistakes:

• Placing limit_req_zone inside server block
• Assuming nodelay is required
• Not matching key with client IP

5. You want to limit requests to 10 per second per user IP but allow bursts of up to 20 requests without delay. Which configuration correctly achieves this?

hard

A. limit_req_zone $binary_remote_addr zone=fastlimit:10m rate=10r/s;
limit_req zone=fastlimit burst=20 nodelay;

B. limit_req_zone $remote_addr zone=fastlimit:10m rate=20r/s;
limit_req zone=fastlimit burst=10;

C. limit_req_zone $binary_remote_addr zone=fastlimit:10m rate=10r/s;
limit_req zone=fastlimit burst=20;

D. limit_req_zone $remote_addr zone=fastlimit:20m rate=10r/s;
limit_req zone=fastlimit burst=10 nodelay;

Solution

1. Step 1: Define correct rate and burst

   Rate is 10r/s, burst 20 means allow 20 extra requests queued without delay.

2. Step 2: Use nodelay to avoid delaying burst requests

   nodelay makes burst requests processed immediately, matching requirement.

3. Step 3: Validate key and zone size

   $binary_remote_addr is preferred key, 10m memory is sufficient.

4. Final Answer:

   limit_req_zone $binary_remote_addr zone=fastlimit:10m rate=10r/s; limit_req zone=fastlimit burst=20 nodelay; -> Option A

5. Quick Check:

   burst=20 with nodelay = immediate burst allowed [OK]

Hint: Use burst with nodelay for instant burst requests [OK]

Common Mistakes:

• Swapping burst and rate values
• Omitting nodelay causing delays
• Using wrong key variable