Practical Nginx Rate Limiting: Elegantly Defending Against CC Attacks and Traffic Spikes

Nginx is the default entry layer for most internet services, but without built‑in rate limiting a sudden surge—whether from a CC attack, a flash sale, or aggressive crawlers—can quickly exhaust CPU, fill connection tables and cause a full‑site outage.

The core of Nginx rate limiting consists of three directives: limit_req_zone to define a shared memory zone, limit_req to apply request‑rate limits in a location, and limit_conn_zone / limit_conn for concurrent‑connection limits. The limit_req implementation uses a leaky‑bucket algorithm: tokens are added at a fixed rate, a request consumes one token, and excess requests are either queued (up to burst) or rejected.

The article details the subtle differences between burst, burst N nodelay and burst N delay=M. With plain burst the excess requests are queued; adding nodelay rejects them immediately; adding delay queues them for a limited time before rejection. A comparison table clarifies when each mode is appropriate.

Choosing the right key is critical. The most common key is $binary_remote_addr (IP‑based), but the article shows how to combine IP with URI, user ID, domain, or custom variables to limit specific dimensions such as per‑API or per‑user traffic.

Common pitfalls are highlighted: setting a rate or burst that is too high renders the limit ineffective, using an undersized zone leads to LRU eviction, and assuming that merely adding a limit guarantees protection. The guide recommends measuring baseline QPS, estimating peak load (3‑5× normal), and then tuning rate and burst accordingly.

Configuration examples cover basic IP limiting, multi‑level limits (per‑API, per‑endpoint, per‑IP+URI), white‑list/black‑list handling with geo and map, CC‑attack mitigation by blocking known user‑agents, and graceful fallback pages. Advanced distributed limiting using OpenResty with Redis is also provided.

Testing and validation steps include syntax check ( nginx -t), reload, load testing with ab, wrk or vegeta, and log analysis to verify 429 ratios. Monitoring suggestions cover custom log formats, Prometheus metrics, and alert rules for sudden 429 spikes or high connection counts.

Finally, the article outlines a complete troubleshooting workflow for 429 spikes, CC attacks, and traffic bursts, with concrete shell commands to isolate offending IPs, UA strings, or URIs, and provides rollback procedures and gray‑release strategies to safely roll out or revert rate‑limit changes.