Nginx rate limiting: zones, burst, 429

• limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m — the pool
• limit_req zone=api burst=20 nodelay — inside a location
• limit_req_status 429 — otherwise it's 503 by default
• limit_conn — concurrent connections (not requests)
• Logs: log_format with $limit_req_status for a fail2ban filter

# /etc/nginx/conf.d/rate-limits.conf
limit_req_zone  zone=api:10m rate=60r/m;
limit_req_zone  zone=login:10m rate=5r/m;
limit_req_status 429;

server {
  location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
  }
  location /login {
    limit_req zone=login burst=3 nodelay;
    proxy_pass http://backend;
  }
}

# fail2ban filter (jail.d/nginx-rate.conf)
[Definition]
failregex = limiting requests, excess.*client: <HOST>

• Setup fail2ban
• Token Bucket

While rate limiting is a powerful tool for controlling traffic to your Nginx server, it does come with certain limitations that administrators should be aware of. Understanding these limitations can help you configure your server more effectively and avoid potential pitfalls.

1. Memory Usage: The limit_req_zone directive allocates shared memory for storing request data. A 10 MB zone can accommodate approximately 160,000 unique IP addresses in RAM. If your application experiences traffic from more unique IPs than the configured zone can handle, excess requests may not be tracked, leading to unintended access.

2. Granularity of Rate Limiting: The rate limiting applies at the level of the defined zone. If you have multiple applications or services running on the same server, they will share the same limits unless separate zones are defined. This can lead to unfair limitations on some services if not configured properly.

3. Bursting Behavior: The burst parameter allows for short spikes in traffic, but it can also lead to a surge in requests that exceed the defined rate. If not managed carefully, this can temporarily overwhelm your resources, especially if combined with other traffic spikes.

4. Logging and Monitoring: By default, Nginx returns a 429 status code for rate-limited requests. It is crucial to log these events to a custom file for monitoring and analysis. This data can be invaluable for adjusting your rate limits and understanding traffic patterns.

In summary, while rate limiting is essential for protecting your Nginx server, it requires careful consideration and ongoing management to ensure optimal performance and security.