{"id":4321,"date":"2026-09-12T15:50:50","date_gmt":"2026-09-12T10:20:50","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/how-to-setup-nginx-rate-limiting-ddos-protection\/"},"modified":"2026-09-12T15:50:50","modified_gmt":"2026-09-12T10:20:50","slug":"how-to-setup-nginx-rate-limiting-ddos-protection","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/how-to-setup-nginx-rate-limiting-ddos-protection\/","title":{"rendered":"How to Set Up Nginx Rate Limiting to Stop Scrapers, Bots and Application Layer DDoS"},"content":{"rendered":"
\n Quick Technical Answer:<\/strong><\/p>\n

\n To enforce rate limiting in Nginx<\/strong>: In the http {}<\/code> block of \/etc\/nginx\/nginx.conf<\/code>, define a shared memory zone: limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r\/s;<\/code>. Then apply it to sensitive endpoints (such as wp-login.php<\/code> or \/api\/<\/code>) inside your server {}<\/code> block: limit_req zone=api_limit burst=20 nodelay;<\/code> and configure limit_req_status 429;<\/code>. This buffers legitimate user spikes while dropping malicious bot floods.\n <\/p>\n<\/div>\n

Why Application Layer (Layer 7) DDoS Floods Overwhelm Unprotected Web Servers<\/h2>\n

Unlike volumetric network floods (such as UDP reflection attacks) that can be mitigated upstream by data center firewalls, Application Layer (Layer 7) attacks<\/strong> mimic legitimate human HTTP requests. An attacker targeting search endpoints (e.g. \/?s=query<\/code>) or login portals (\/wp-login.php<\/code>) can launch 5,000 requests per second from a residential proxy network.<\/p>\n

Because each of these dynamic queries triggers PHP execution, database table locks, and memory allocation, a low-cost botnet can easily drive server CPU utilization to 100% and exhaust MySQL database connection pools, bringing down a business website on an otherwise powerful cloud VPS.<\/p>\n

Nginx provides an ultra-high-speed, in-memory rate limiting module built on the leaky bucket algorithm<\/strong>. Operating in compiled C with binary IP representations, Nginx processes rate limiting checks in less than 5 microseconds per request\u2014terminating abusive bots before they ever touch your backend application code.<\/p>\n

Step 1: Understanding the Leaky Bucket Algorithm<\/h2>\n

Imagine a bucket with a small hole at the bottom. Water (incoming HTTP requests) enters the bucket at random speeds and leaks out at a constant, controlled rate. If the bucket overflows (excessive request velocity), any additional incoming water spills over (requests are rejected with HTTP 429 Too Many Requests).<\/p>\n

Step 2: Defining Rate Limiting Zones in nginx.conf<\/h2>\n

Open your main Nginx configuration file:<\/p>\n

sudo nano \/etc\/nginx\/nginx.conf<\/code><\/pre>\n
Inside the http { ... }<\/code> context, define specialized memory zones for different application tiers:<\/p>\n
http {\n    # 1. Standard API Rate Limit: 10 requests\/second per IP\n    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r\/s;\n\n    # 2. Strict Authentication & Login Rate Limit: 1 request\/second per IP\n    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r\/s;\n\n    # 3. Aggressive Bot Scraper Limit: 5 requests\/minute per IP\n    limit_req_zone $binary_remote_addr zone=search_limit:10m rate=5r\/m;\n\n    # Return standard HTTP 429 (Too Many Requests) instead of 503\n    limit_req_status 429;\n\n    # Log rate-limited requests at warning level\n    limit_req_log_level warn;\n}<\/code><\/pre>\n
Why $binary_remote_addr?<\/strong> The standard $remote_addr<\/code> variable stores IPv4 addresses as text strings (7 to 15 bytes). The $binary_remote_addr<\/code> variable stores IPv4 addresses in binary form (always 4 bytes) and IPv6 in 16 bytes. A 10MB memory zone<\/strong> can track roughly 160,000 distinct IP addresses<\/strong> simultaneously in high-speed RAM.<\/p>\n
Step 3: Applying Rules to Server Blocks and Locations<\/h2>\n
Open your site’s server block configuration:<\/p>\n
sudo nano \/etc\/nginx\/sites-available\/yourdomain.conf<\/code><\/pre>\n
Apply rate limits with appropriate burst<\/code> and nodelay<\/code> parameters:<\/p>\n
server {\n    listen 443 ssl http2;\n    server_name yourdomain.com;\n\n    # Protect WordPress Login \/ Admin Authentication\n    location = \/wp-login.php {\n        limit_req zone=login_limit burst=3 nodelay;\n        include snippets\/fastcgi-php.conf;\n        fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n    }\n\n    # Protect Search & Heavy Database Query Endpoints\n    location \/search\/ {\n        limit_req zone=search_limit burst=5;\n        proxy_pass http:\/\/127.0.0.1:3000;\n    }\n\n    # General REST API Protection\n    location \/api\/ {\n        limit_req zone=api_limit burst=20 nodelay;\n        proxy_pass http:\/\/127.0.0.1:3000;\n    }\n\n    # Standard Static & Page Traffic\n    location \/ {\n        try_files $uri $uri\/ \/index.php?$args;\n    }\n}<\/code><\/pre>\n
Step 4: The Crucial Difference Between burst and nodelay<\/h2>\n\n\n\n\n\n\n\n
Configuration Syntax<\/th>\nQueue Behavior<\/th>\nUser Experience Impact<\/th>\n<\/tr>\n<\/thead>\n
limit_req zone=api_limit;<\/code><\/td>\nZero buffer; any 2nd request in the same 100ms interval drops instantly.<\/td>\nBreaks web pages loading multiple CSS\/JS assets concurrently.<\/td>\n<\/tr>\n
limit_req zone=api_limit burst=20;<\/code><\/td>\nAllows 20 requests into queue, but delays delivery to match exact rate.<\/td>\nAssets load slowly with artificial latency pauses.<\/td>\n<\/tr>\n
limit_req zone=api_limit burst=20 nodelay;<\/code><\/td>\nProcesses up to 20 burst requests instantly; rejects excess.<\/strong><\/td>\nIdeal for real humans; stops high-velocity automated scrapers.<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Step 5: Testing Rate Limiting with ApacheBench (ab)<\/h2>\n
Verify that your rate limits trigger correctly using the ApacheBench benchmarking tool:<\/p>\n
# Send 50 concurrent requests to test endpoint\nab -n 50 -c 10 https:\/\/yourdomain.com\/api\/test\n\n# Inspect Nginx error log to observe rate limit triggers\nsudo tail -f \/var\/log\/nginx\/error.log | grep \"limiting requests\"<\/code><\/pre>\n
Frequently Asked Questions (FAQ)<\/h2>\n
\n
How do I whitelist search engine crawlers like Googlebot from rate limits?<\/h3>\n
Use an Nginx geo<\/code> mapping block to set a variable (e.g. $limit = 0<\/code> for trusted IP CIDR blocks, and $binary_remote_addr<\/code> for the public internet). When the mapping returns 0 or an empty string, Nginx skips rate limiting entirely.<\/p>\n
What is the difference between limit_req and limit_conn?<\/h3>\n
limit_req<\/code> restricts the velocity<\/strong> of requests over time (e.g. requests per second). limit_conn<\/code> restricts the number of concurrent open TCP connections<\/strong> from a single IP address (e.g. stopping users from opening 50 simultaneous file download streams).<\/p>\n<\/div>\n
\n
\ud83d\udd17 Recommended Related Technical Guides<\/h3>\n