How to Set Up Nginx Rate Limiting – Protect Against Brute‑Force Attacks

Rate limiting is not optional – it's a necessary security measure[reference:14]. Without it, attackers can hammer your login endpoints, API endpoints, and forms with unlimited requests. Nginx provides built‑in rate limiting that protects your server without adding extra software.

This guide shows you how to configure Nginx rate limiting on Ubuntu.

What Is Rate Limiting?

Rate limiting restricts the number of requests a single IP can make in a given time period. It prevents brute‑force attacks, DDoS attempts, and abusive crawling that can overload your server.

Nginx uses limit_req_zone to define the limit and limit_req to apply it.

Step 1: Define the Rate Limit Zone

Add this to the http block in /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;

What this does:

• $binary_remote_addr – Tracks each client by IP address
• zone=login_limit:10m – Creates a 10 MB shared memory zone named login_limit
• rate=5r/s – Allows 5 requests per second on average

For login endpoints, a stricter limit of 1‑2 requests per second is recommended[reference:15].

Step 2: Apply the Limit to a Location

In your server block, apply the limit to sensitive endpoints:

server {
    listen 80;
    server_name example.com;

    location /login/ {
        limit_req zone=login_limit burst=10 nodelay;
        proxy_pass http://localhost:3000;
    }

    location /api/ {
        limit_req zone=login_limit burst=20;
        proxy_pass http://localhost:3000;
    }
}

Parameters explained:

• burst=10 – Allows a short burst of 10 requests above the rate limit
• nodelay – Processes burst requests immediately instead of delaying them

Step 3: Test and Reload Nginx

sudo nginx -t
sudo systemctl reload nginx

Step 4: Monitor Rate Limiting

Check Nginx logs to see rate limiting in action:

sudo tail -f /var/log/nginx/access.log

When a client exceeds the limit, Nginx returns a 503 error. You can also define a custom error page for rate‑limited responses.

Rate limiting is effective against bots, but legitimate users behind a shared IP (like office networks) might also be affected. Adjust limits based on your traffic patterns and test before deploying to production[reference:16].