Why rate limiting prevents abuse in Nginx - Why It Works

Introduction

Rate limiting helps stop too many requests from one user or device in a short time. This protects websites from being overwhelmed or attacked by too many requests at once.

When a website gets too many requests from one IP and slows down for others

When you want to stop automated bots from spamming your login page

When you want to protect an API from being called too often by one user

When you want to avoid extra costs caused by excessive traffic

When you want to keep your server stable during traffic spikes

Config File - nginx.conf

nginx.conf

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        listen 80;

        location / {
            limit_req zone=mylimit burst=10 nodelay;
            proxy_pass http://localhost:8080;
        }
    }
}

limit_req_zone defines a shared memory zone named 'mylimit' that tracks requests per IP address, allowing 5 requests per second.

limit_req applies the rate limit to the location, allowing bursts of up to 10 requests without delay.

This setup protects the server by slowing down or rejecting excessive requests from the same IP.

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 check if 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



<html>...</html>

Send 20 quick requests to test if rate limiting blocks some requests with status 503.

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

503

503

503

503

503

503

503

503

503

503

503

503

503

503

503

Key Concept

If you remember nothing else from this pattern, remember: rate limiting controls how many requests a user can make to protect your server from overload and abuse.

Common Mistakes

Not testing the Nginx configuration before reloading

This can cause Nginx to fail to reload and stop serving requests if there is a syntax error.

Always run 'sudo nginx -t' to check configuration syntax before reloading.

Setting the rate limit too low without allowing bursts

This can block normal users who occasionally make multiple requests quickly.

Use the 'burst' parameter to allow short bursts of requests without blocking.

Not reloading Nginx after changing the config file

Changes won't take effect until Nginx reloads the configuration.

Run 'sudo systemctl reload nginx' after editing the config.

Summary

Define a rate limit zone in nginx.conf to track requests per IP.

Apply the rate limit to a location with 'limit_req' and configure burst handling.

Test the configuration syntax with 'nginx -t' before reloading.

Reload Nginx to apply changes without downtime.

Verify rate limiting works by sending multiple requests and checking for 503 errors.

Practice

1. What is the main purpose of rate limiting in nginx?

easy

A. To increase the speed of all incoming requests

B. To control how many requests a user can make in a given time

C. To allow unlimited access to all users

D. To block all requests from unknown IPs

Solution

1. Step 1: Understand rate limiting concept

   Rate limiting restricts the number of requests a user can send in a certain time to prevent overload.

2. Step 2: Identify the main purpose in nginx

   In nginx, rate limiting is used to control request rates to protect the server from abuse.

3. Final Answer:

   To control how many requests a user can make in a given time -> Option B

4. Quick Check:

   Rate limiting = control request count [OK]

Hint: Rate limiting means controlling request numbers per time [OK]

Common Mistakes:

• Thinking it speeds up requests
• Believing it blocks all unknown users
• Assuming it allows unlimited access

2. Which of the following is the correct nginx directive to set a rate limit zone named 'mylimit' with 10MB shared memory?

easy

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

B. limit_req_zone $remote_addr zone=mylimit:10mb rate=10r/s;

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

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

Solution

1. Step 1: Check syntax for limit_req_zone

   The correct syntax uses $binary_remote_addr, zone name with size (10m), and rate with r/s, ending with a semicolon.

2. Step 2: Identify correct option

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; matches correct syntax exactly: 'limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;'

3. Final Answer:

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

4. Quick Check:

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

Hint: Remember $binary_remote_addr and 'zone=name:size' syntax [OK]

Common Mistakes:

• Using '10mb' instead of '10m' for memory size
• Missing semicolon at end
• Using $remote_addr instead of $binary_remote_addr

3. Given this nginx config snippet:

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

What happens if a user sends 4 requests in 1 second?

medium

A. 1 request is processed immediately, others are delayed or rejected

B. All 4 requests are processed immediately

C. All requests are rejected

D. Requests are queued indefinitely

Solution

1. Step 1: Understand rate and burst settings

   The rate=1r/s allows 1 request per second. The burst=2 allows 2 extra requests to be queued temporarily.

2. Step 2: Analyze 4 requests in 1 second

   First request is processed immediately, next 2 are allowed by burst (delayed), the 4th exceeds burst and is rejected.

3. Final Answer:

   1 request is processed immediately, others are delayed or rejected -> Option A

4. Quick Check:

   Rate 1r/s + burst 2 = 1 immediate + 2 delayed, 4th rejected [OK]

Hint: Burst allows extra requests beyond rate, but not unlimited [OK]

Common Mistakes:

• Assuming all requests pass immediately
• Thinking burst means unlimited queue
• Believing all requests get rejected

4. You configured nginx rate limiting but users still flood your server. Which mistake might cause this?

medium

A. Using $remote_addr instead of $binary_remote_addr in limit_req_zone

B. Using rate=10r/s instead of 10r/m

C. Setting burst value too low

D. Not enabling limit_req in the server block

Solution

1. Step 1: Check if limit_req is enabled

   Defining limit_req_zone alone does not apply rate limiting; limit_req must be enabled in location or server block.

2. Step 2: Identify why flooding continues

   If limit_req is missing, nginx does not limit requests despite zone definition, causing flooding.

3. Final Answer:

   Not enabling limit_req in the server block -> Option D

4. Quick Check:

   limit_req must be active to enforce limits [OK]

Hint: Define zone and enable limit_req to activate rate limiting [OK]

Common Mistakes:

• Thinking limit_req_zone alone limits requests
• Confusing $remote_addr and $binary_remote_addr as critical error here
• Misunderstanding burst effect

5. You want to protect your nginx server from abuse by limiting requests to 5 per second per IP, allowing bursts of 10. Which configuration snippet correctly applies this?

hard

A. limit_req_zone $binary_remote_addr zone=addr:10m rate=5r/s;\nserver {\n location / {\n limit_req zone=addr burst=10 nodelay;\n }\n}

B. limit_req_zone $remote_addr zone=addr:10m rate=5r/s;\nserver {\n location / {\n limit_req zone=addr burst=10 delay;\n }\n}

C. limit_req_zone $binary_remote_addr zone=addr:10m rate=10r/s;\nserver {\n location / {\n limit_req zone=addr burst=5 nodelay;\n }\n}

D. limit_req_zone $binary_remote_addr zone=addr:5m rate=5r/m;\nserver {\n location / {\n limit_req zone=addr burst=10 nodelay;\n }\n}

Solution

1. Step 1: Verify rate_req_zone parameters

   The zone must use $binary_remote_addr, 10m memory, and rate=5r/s to limit 5 requests per second per IP.

2. Step 2: Check limit_req settings

   limit_req must use the same zone, burst=10 to allow 10 extra requests, and nodelay to process bursts immediately.

3. Final Answer:

   limit_req_zone $binary_remote_addr zone=addr:10m rate=5r/s; server { location / { limit_req zone=addr burst=10 nodelay; } } -> Option A

4. Quick Check:

   Correct zone + burst + nodelay = limit_req_zone $binary_remote_addr zone=addr:10m rate=5r/s;\nserver {\n location / {\n limit_req zone=addr burst=10 nodelay;\n }\n} [OK]

Hint: Match zone name and use burst with nodelay for immediate bursts [OK]

Common Mistakes:

• Using $remote_addr instead of $binary_remote_addr
• Mixing rate units (r/s vs r/m)
• Setting burst lower than required