Rate limiting is one of the core protection layers in network security. Its essence is simple — limit the number of requests from one IP or user in a given time. If the limit is exceeded the server rejects additional requests and returns an error. This protects from DDoS attacks, brute force attempts and API abuse. It also helps fairly distribute server resources among all users.
Why rate limiting is needed
Since internet services are open, anyone can connect and send requests. A malicious user or bot can send thousands of requests per second and bring down the server. Additionally, repeated password guessing attempts are dangerous. Rate limiting solves these problems — if too many requests come from one source they are automatically stopped. The important thing is that rate limiting is a structural protection layer, and even if there is a vulnerability in some application, an attacker cannot quickly exploit it.
Configuring rate limiting in Nginx
In Nginx rate limiting is configured via limit_req_zone and limit_req directives. First a zone is defined — by which key to limit (IP, user, header) and memory size. Then in server or location how many requests are allowed and what burst. Burst is a reserve for short peaks, for example when a user loads a page and needs many resources, this is normal. In Nginx you can create multiple zones and set different limits for different endpoints.
Rate limiting via Cloudflare
Cloudflare offers cloud rate limiting and it is the most effective option because the attack stops at Cloudflare servers and does not reach your server at all. Rules are created in the Cloudflare dashboard — URL pattern, request count, time interval and action. The action can be blocking, CAPTCHA or simply dropping. On the free plan there is also basic rate limiting but for advanced rules a paid plan is needed. This is especially useful for protecting login pages and API endpoints.
Application-level rate limiting
Web server level rate limiting is good but when business logic restrictions are needed implementation in the application is necessary. For example a user should not request a verification code more than 5 times a day or submit an order more than 3 times a minute. Redis is the best tool for this — stores counters in memory and automatically clears with TTL. In Laravel, Django and other frameworks there are ready middleware for rate limiting, only configuration is needed.
Sayt.uz practice
Sayt.uz uses multi-layer rate limiting at the Nginx level. For general sites 30 requests per second per IP is set, for login pages 5 requests per minute. For API endpoints there is token-based limiting — each client has a limit based on their plan. If a client exceeds the limit, a warning appears in the cabinet and an offer to upgrade the plan. Through Cloudflare an additional protection layer is also enabled — DDoS peak loads are automatically detected and blocked.