limit_req_zone and limit_req in Nginx - Commands & Configuration

Introduction

When many users visit a website at the same time, the server can get overwhelmed and slow down or crash. Nginx has tools called limit_req_zone and limit_req that help control how many requests each user can make in a short time. This keeps the server stable and fair for everyone.

When you want to stop one user from sending too many requests and slowing down your website.

When you want to protect your server from simple attacks that flood it with requests.

When you want to make sure your website stays fast even if many people visit at once.

When you want to limit API usage per user to avoid abuse.

When you want to control traffic from certain IP addresses to prevent overload.

Config File - nginx.conf

nginx.conf

http {
    # Define a shared memory zone named 'mylimit' to track requests by IP
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        listen 80;
        server_name example.com;

        location / {
            # Apply the request limit using the 'mylimit' zone
            limit_req zone=mylimit burst=10 nodelay;

            # Usual proxy or root settings
            root /var/www/html;
            index index.html;
        }
    }
}

limit_req_zone defines a shared memory area named 'mylimit' that tracks requests per user IP address ($binary_remote_addr). It sets a limit of 5 requests per second.

limit_req applies this limit in the server's location block. The burst=10 allows short bursts of up to 10 extra requests, and nodelay makes Nginx delay excessive requests instead of rejecting them immediately.

Commands

Check the Nginx configuration file for syntax errors before applying changes.

Terminal

sudo nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload Nginx to apply the new rate limiting configuration without stopping the server.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Send a request to the server to verify it responds normally under the rate limit.

Terminal

curl -i http://localhost/

Expected Output

HTTP/1.1 200 OK

Server: nginx

Content-Type: text/html

Content-Length: 612

Connection: keep-alive



<!DOCTYPE html>...

Send 20 quick requests to test if Nginx limits requests and returns 503 status when limit is exceeded.

Terminal

for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost/; done

Expected Output

200

200

200

200

200

200

200

200

200

200

503

503

503

503

503

503

503

503

503

503

Key Concept

If you remember nothing else from this pattern, remember: limit_req_zone sets the request rate limit, and limit_req enforces it per user to protect your server from overload.

Common Mistakes

Not defining limit_req_zone before using limit_req.

Nginx will fail to start or ignore the limit because the zone is missing.

Always define limit_req_zone in the http block before applying limit_req in server or location blocks.

Setting rate too low without burst, causing many 503 errors.

Users get blocked too quickly, harming user experience.

Use a reasonable rate and add burst to allow short spikes in traffic.

Using $remote_addr instead of $binary_remote_addr in limit_req_zone.

$remote_addr uses string IP which is slower and uses more memory.

Use $binary_remote_addr for better performance and less memory usage.

Summary

Define a shared memory zone with limit_req_zone to track request rates by IP.

Apply the rate limit in server or location blocks using limit_req with burst and nodelay options.

Test the configuration syntax and reload Nginx to apply changes safely.

Verify the limit works by sending multiple requests and observing 503 errors when exceeded.

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