Rate Limiting Generator
Protect APIs from DDoS, brute force, and scraping with strict traffic shaping.
Configuration Health
API security analysis based on rate limit rules.
Detailed Analysis
Best Practice Analysis
- Apply rate limits aggressively on login routes.
- Use header/JWT rate limiting for APIs rather than just IP.
- Enable concurrent connection limits to stop Slowloris.
Production Readiness
- Valid Target Path
- Limiting Enabled
Overview
The API Rate Limiting Generator configures strict traffic control mechanisms for NGINX and HAProxy to protect your backend APIs from abuse, DDoS attacks, and brute-force login attempts.
Rate limiting is your first line of defense against malicious actors. By defining memory zones that track client IP addresses, you can restrict how many requests a single user can make per second. This tool helps you fine-tune these zones, configure burst tolerances, and implement distinct limits for different URL paths (like aggressive limits on /login and relaxed limits on /api/data).
How It Works
1. Define Shared Memory Zones: A zone is a block of RAM used by the load balancer to keep track of client request rates. You define the size (e.g., 10MB) and the average allowed rate (e.g., 5 requests per second).
2. Configure Burst & Nodelay: The 'burst' parameter defines how many requests a user can make above the average rate in a short spike before getting blocked. 'Nodelay' processes those burst requests instantly rather than artificially slowing them down.
3. Apply to Paths: You can create multiple rate limit zones and apply them selectively. For example, you can limit global traffic to 50 req/s, but restrict /api/login to just 2 req/s to prevent password guessing.
4. Handle Rejections: When a user exceeds the limit, the server drops the request and returns an HTTP 429 (Too Many Requests) or HTTP 503 status code.
Best Practices
- Always use the `nodelay` flag in NGINX. Without it, NGINX will artificially 'delay' burst requests by holding them in a queue, which ties up server worker connections and increases latency.
- Do not apply global rate limits to static assets (images, CSS, JS). Browsers request dozens of static files simultaneously; applying strict rate limits will cause your webpage to load partially or break completely.
- Use a specific zone just for authentication endpoints (e.g., `/auth/login`, `/password/reset`). These should have extremely strict limits (like 1r/s) because a human cannot type passwords faster than that.
- If your load balancer sits behind a CDN like Cloudflare, ensure you rate limit based on the `X-Forwarded-For` header or Cloudflare's `CF-Connecting-IP`, not the direct `$binary_remote_addr`.
Common Mistakes
- Making the shared memory zone too small. In NGINX, a 1MB zone can track about 16,000 IP addresses. If your site gets massive traffic and the zone fills up, NGINX will start dropping the oldest IP tracking data, rendering the limit ineffective.
- Confusing Rate Limiting with Connection Limiting. Rate Limiting (`limit_req`) controls HTTP requests per second. Connection Limiting (`limit_conn`) controls the number of simultaneous TCP connections from a single IP.
- Setting the burst too low. APIs often make 'bursty' requests on page load. A limit of 2r/s with a burst of 0 means if a user clicks two links within the same second, the second one fails.
Security Recommendations
- Return HTTP 429 (Too Many Requests) instead of the NGINX default HTTP 503 (Service Unavailable). This correctly informs API clients that they are being throttled and should back off.
- Use rate limiting in combination with GeoIP blocking if you notice brute-force attacks originating entirely from countries you don't serve.
- Log all rate-limited requests by ensuring `limit_req_log_level error;` is set. Monitor these logs in Grafana/ELK to adjust your limits if legitimate users are being blocked.
Production Tips
- For globally distributed architectures with multiple NGINX nodes, local memory zones will not sync. In highly scaled environments, you must implement distributed rate limiting at the application layer (using Redis) or use an API Gateway like Kong.
- Use HAProxy's `stick-table` feature for advanced, multi-dimensional rate limiting (e.g., limiting based on an API Key header rather than just the IP address).
- Temporarily run rate limits in 'dry-run' mode (if supported by your enterprise software) or analyze your access logs before enforcing strict limits in production to establish a baseline.