NGINX Rate Limiting & The Leaky Bucket Algorithm: Defeating Layer-7 DDoS and Scrapers in Pakistan

When malicious actors target web applications in Pakistan today, they rarely rely on brute-force volumetric bandwidth floods alone. Instead, they launch Layer-7 (Application Layer) DDoS attacks, automated price scraping bots, and credential stuffing swarms aimed directly at resource-heavy endpoints:

• Flooding the WordPress wp-login.php or /xmlrpc.php endpoints with 200 POST requests per second.
• Hammering heavy database search queries (/search?q=...) to lock up MariaDB buffer pools.
• Bombarding OTP/SMS verification endpoints on fintech apps, causing thousands of dollars in telecom SMS gateway bills.

Because each HTTP request appears syntactically legitimate, traditional network firewalls allow them straight through. Downstream, PHP-FPM worker pools and database connections are exhausted within seconds.

The definitive weapon against application-layer abuse is NGINX Rate Limiting based on the Leaky Bucket Algorithm.

This comprehensive technical guide explains how the leaky bucket algorithm operates inside NGINX, how to fine-tune limit_req_zone, burst, and nodelay, and how to implement multi-tiered rate limiting on enterprise Dedicated Servers in Pakistan.

---

The Leaky Bucket Algorithm Explained

NGINX implements rate limiting using the Leaky Bucket Algorithm, a classic traffic-shaping paradigm borrowed from telecommunications:

[Incoming User Requests (Water Droplets)]
                  │
                  ▼
       ┌─────────────────────┐
       │   Bucket Capacity   │ ──► Configured via 'burst=N'
       │                     │
       │  [Req 1] [Req 2]    │ ──► Holds temporary bursts of legitimate requests
       │  [Req 3] [Req 4]    │
       └──────────┬──────────┘
                  │
                  ▼ Fixed Leak Rate (Configured via 'rate=10r/s')
        [Processed by NGINX / Upstream Backend]
                  │
                  ▼ If bucket overflows (Burst exceeded):
     [HTTP 429 Too Many Requests (or HTTP 503)]

How it Works:

1. Imagine a bucket with a small hole in the bottom that leaks water at a fixed, constant rate (e.g., 10 drops per second).
2. If requests arrive at a steady rate, they pass through immediately without delay.
3. If a sudden burst of requests arrives (e.g., a legitimate human user refreshing a page), they are temporarily queued inside the bucket (burst).
4. If requests arrive faster than the bucket can drain and the bucket overflows, the excess requests are immediately dropped or rejected with HTTP 429/503!

---

Core Directives: Syntax and Memory Architecture

Rate limiting in NGINX is configured in two stages: defining the shared memory zone in the http context, and applying the restriction in a server or location block.

1. limit_req_zone (The Memory Tracker)

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

• $binary_remote_addr: Uses the binary representation of the client’s IP address. In IPv4, this consumes only 4 bytes per client (or 16 bytes for IPv6), rather than the 7-15 bytes consumed by the text-based $remote_addr.
• zone=api_limit:10m: Allocates a 10-megabyte shared memory pool. A 10MB zone can track approximately 160,000 distinct IP addresses simultaneously in RAM!
• rate=10r/s: The maximum permissible sustained request rate (10 requests per second, or 1 request every 100 milliseconds). You can also specify rates per minute (e.g., rate=30r/m).

2. limit_req with burst and nodelay

limit_req zone=api_limit burst=20 nodelay;

• burst=20: Allows a user to temporarily exceed the 10r/s rate by up to 20 additional requests in a burst.
• nodelay (CRITICAL): Without nodelay, NGINX introduces artificial delays, pacing the burst requests by 100ms each, making the site feel sluggish. With nodelay, burst requests are executed immediately at full speed; only when the user exceeds the total burst capacity ($10 + 20 = 30$) are subsequent requests rejected!

---

Production Configuration: Multi-Tiered Rate Limiting

Below is an enterprise-grade NGINX configuration implementing three specialized rate-limiting tiers:

# /etc/nginx/conf.d/rate-limiting.conf

# 1. Global Rate Limit (Covers general browsing: 20 req/sec)
limit_req_zone $binary_remote_addr zone=general_zone:10m rate=20r/s;

# 2. Strict Authentication Limit (Logins, Registration: 5 req/minute)
limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;

# 3. High-Concurrency API Limit (Public API endpoints: 50 req/sec)
limit_req_zone $binary_remote_addr zone=api_zone:20m rate=50r/s;

# Configure custom status code (Default is 503; 429 is RFC 6585 compliant)
limit_req_status 429;
limit_req_log_level warn;

server {
    listen 80;
    listen [::]:80;
    server_name portal.nextgen.pk;

    # Apply general rate limiting across the entire site
    location / {
        limit_req zone=general_zone burst=30 nodelay;
        proxy_pass http://backend_cluster;
    }

    # Lock down login endpoints against credential stuffing
    location /auth/login {
        limit_req zone=login_zone burst=3 nodelay;
        proxy_pass http://backend_cluster;
    }

    # API endpoints with higher burst tolerance
    location /api/v1/ {
        limit_req zone=api_zone burst=100 nodelay;
        proxy_pass http://backend_cluster;
    }
}

---

Advanced: Rate Limiting Behind Cloudflare / CDNs

If your server sits behind Cloudflare, Fastly, or an upstream CDN, $binary_remote_addr will evaluate the CDN’s edge server IP rather than the actual visitor’s IP. If one visitor triggers a rate limit, NGINX will accidentally block thousands of innocent users sharing that CDN edge node!

To fix this, use NGINX’s real_ip module to extract the true visitor IP from the CF-Connecting-IP header:

# Trust Cloudflare IPv4 ranges (sample snippet)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;

# Use the Cloudflare header for client IP extraction
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

# Now $binary_remote_addr accurately tracks the real client in Pakistan!
limit_req_zone $binary_remote_addr zone=trusted_zone:10m rate=15r/s;

---

Whitelisting Office IPs and Monitoring Bots

You should never rate-limit your internal office VPNs, automated uptime monitors, or Googlebot indexing crawlers. You can use an NGINX geo and map block to bypass rate limiting for trusted IPs:

geo $whitelist {
    default 0;
    103.151.43.0/24 1; # Nextgen Internal Subnet
    127.0.0.1 1;       # Localhost
}

map $whitelist $limit_key {
    0 $binary_remote_addr; # Untrusted users are rate limited
    1 "";                  # Whitelisted users evaluate to empty string (bypassed!)
}

# The zone tracks $limit_key: Empty keys are completely ignored by NGINX!
limit_req_zone $limit_key zone=smart_zone:10m rate=10r/s;

---

Benchmarking Under Attack: Observing the Defense

To verify your rate limiter, run an automated concurrency test:

# Send 100 concurrent requests to the login endpoint
ab -n 100 -c 10 https://portal.nextgen.pk/auth/login

Inspecting the output will reveal:

• Completed Requests: 100
• Failed Requests: 92 (Returned HTTP 429 Too Many Requests)
• Backend Server Load: Zero spike. Your PHP workers and MariaDB databases processed only the 8 permitted requests, completely ignoring the remaining 92 abusive hits!

---

Defend Your Production Workloads with Nextgen

Software rate limiting is your first line of defense against application-layer abuse. However, sustaining tens of thousands of rate-limited evaluations per second requires high-throughput memory controllers, pure ECC RAM, and dedicated network interfaces.

Deploy your mission-critical web applications on high-performance bare-metal hardware for guaranteed compute and zero noisy neighbors.

Explore Nextgen’s high-performance bare-metal Dedicated Servers and locally hosted Dedicated Servers in Pakistan.