Rate Limiting & Throttling with Nginx

Imagine a popular website or API. What happens if one user or a malicious bot sends thousands of requests per second?

This is where rate limiting comes in! It's a crucial technique to control the number of requests a client can make to your server within a specific timeframe.

• Prevents abuse and DDoS attacks.
• Ensures fair resource usage for all clients.
• Protects your backend services from overload.

Nginx provides powerful directives to implement rate limiting. We'll focus on two main ones:

• limit_req_zone: Defines the parameters for a rate limiting zone. Think of it as setting up the rules for a specific type of traffic.
• limit_req: Applies the defined rate limiting rules to requests within a specific location or server block. This is where the magic happens!

The limit_req_zone directive is typically placed in the http block of your Nginx configuration. It defines a shared memory zone where Nginx keeps track of request states.

Here's its structure and what each part means:

• key: What Nginx tracks (e.g., $binary_remote_addr for client IP).
• zone: A name for your zone and its size (e.g., my_limit:10m). The size determines how many unique keys Nginx can track.
• rate: The actual rate limit (e.g., rate=1r/s for 1 request per second).

Let's define a simple rate limiting zone that tracks requests by client IP address and allows 5 requests per second.

After defining a limit_req_zone, you need to apply it to specific parts of your website or API using the limit_req directive.

This directive is placed inside a server or location block. It simply references the zone you created earlier.

For example, to apply the my_ip_limit zone to a specific location:

When a client exceeds the defined rate, Nginx will return a 503 Service Unavailable error by default.

Here's how you can combine both directives to limit requests to your /api/ endpoint to 2 requests per second per unique IP address.

Strict rate limits can sometimes be too restrictive for legitimate users. The burst parameter allows a client to make requests exceeding the defined rate temporarily.

• burst=N: Allows requests up to N more than the rate limit. These requests are queued and processed at the rate limit.
• nodelay: When used with burst, Nginx processes burst requests immediately if possible. If the queue is full, subsequent requests are dropped (503 error) instead of being delayed.

Without nodelay, requests exceeding the rate will be delayed to conform to the rate.

Let's update our previous example to allow a burst of up to 5 additional requests, processing them immediately if resources permit.

While often used interchangeably, there's a subtle difference:

• Rate Limiting: Enforces a hard limit on the number of requests over a period (e.g., 100 requests per minute). Nginx's limit_req primarily implements rate limiting.
• Throttling: Is a more dynamic process that might slow down requests rather than outright rejecting them. It often considers server load or resource availability. While Nginx can delay requests with burst (if nodelay is absent), it's more focused on strict limits.

For most API protection needs, Nginx's rate limiting capabilities are robust and highly effective.

You've learned about the core Nginx directives for rate limiting. Now, let's test your knowledge!

In this lesson, you've learned how to implement rate limiting with Nginx to protect your backend services and ensure fair usage.

• We defined a rate limiting zone using limit_req_zone.
• We applied these limits to specific locations using limit_req.
• We explored the burst and nodelay options to handle temporary traffic spikes more gracefully.

Rate limiting is a fundamental security and performance pattern, especially when dealing with public APIs or high-traffic web applications.