Cloudflare Rate Limiting protects against denial-of-service attacks, brute-force login attempts, and other types of abusive behavior targeting the application layer.
Cloudflare Rate Limiting is a feature that allows customers to identify and mitigate high request rates automatically, either for specific URLs or for an entire domain.
The most common uses for Rate Limiting are:
Protect your site against a layer 7 (HTTP-based) DDoS attack that is either not stopped by I'm Under Attack mode or in situations when using I'm Under Attack mode is not desired; for example:
- If you have legitimate automated traffic that would be unable to pass a challenge
- When you do not wish to show an interstitial challenge page to your users
Brute-force attack protection
Protect your site from brute-force, password guessing login attempts.
Limited access to high-cost resources
Limit how often a client can access a resource that has a high processing cost on your origin; for example: forum searches, certain API calls, or other database-intensive actions.
How do I create a rule?
You can create a Rate Limiting rule via:
- The Cloudflare dashboard - see Configuring Rate Limiting from the Cloudflare Dashboard.
- The Cloudflare API - see the API documentation for Rate Limiting. Also, see Common Rate Limiting API issues.
It depends on your Cloudflare customer plan:
What happens when a rule activates?
Once a client (an individual IPv4 address or IPv6 /64 block) exceeds a rule threshold, requests will match the rule pattern and will no longer be sent to the origin web server. Clients receive an HTTP 429 with a
Retry-After: X header to indicate how long their timeout period before they will be able to send requests again.
Request rates are calculated locally in individual Cloudflare points of presence (PoP). In practice, this should not matter as all requests from a given client will almost always route to the same PoP. The PoP may change due to routing modifications, but these are infrequent.
How will I be charged?
Rate Limiting charges are usage-based. Once you activate a rule, Cloudflare tracks and bills for requests that match the URL but that are not blocked but rather sent to your origin (unless you configure to rate limit on edge requests). Your invoice is calculated at the end of your billing cycle.
What are the components of a Rate Limiting rule?
A Rate Limiting rule consists of three distinct elements as described below.
1. Request matching criteria
Incoming requests are matched based on:
The request path
This criteria is case insensitive and cannot match against a query string. An asterisk (*) will match any sequence of characters, including an empty sequence. For example, you'd use:
*.example.com/*to match any path on any subdomain of
*example.com/example.htmlto match example.html on example.com or any subdomain of example.com
*to match any page on your site
Pattern matching takes any trailing slash "/" character into account. A request for
example.com/path is not the same as
example.com/path/. As such, you should create rules for both if you want to match requests for that path and do not wish to use a wildcard. The one exception is the homepage:
example.com will match requests for "
Additionally, patterns cannot match content after query strings (?) or anchors (#).
The request scheme
That is, HTTP or HTTPS. If none is specified, both are matched, and the rule will list
The request method
That is, POST or GET. If none is specified, all methods are matched, and the rule will list
The response code returned by the origin (optional)
For example, 401 or 403.
If you include this criteria and the rule triggers, subsequent requests from that client will be blocked regardless of which code is returned. Since any of these codes cannot be seen without sending the request first, we must block all requests.
2. Rate matching criteria
A rule can match on the number and time period of all requests coming from the same client:
Number of requests
Rules should specify a minimum of two requests, since a single request would match any request and should instead be handled by making the path unavailable completely; for example, by configuring the origin to return a 403.
Once a client exceeds the threshold specified in the time period, the rule will trigger. The periods available, by plan, are:
- 1 second or 1 minute (Free and Pro)
- 1 second, 1 minute, or 10 minutes (Business)
- Any period between 1 second and 1 hour (Enterprise)
3. Rule mitigation
Rule mitigations consist of:
Options are based on the customer plan :
|Block||Cloudflare issues a 429 error when the threshold is exceeded.||All plans|
|Challenge||User has to pass a Google reCaptcha Challenge before proceeding. If successful, Cloudflare accepts the request. Otherwise, the request is blocked.||Pro, Business, and Enterprise plans|
|Simulate||Cloudflare does not block any requests but instead, logs them in Enterprise Log Share (ELS) as simulate. You can use this option to test your rule before applying any of the other options in your live environment.|
Time-out/ or ban period
This must be greater than the threshold, and attempting to set a timeout shorter than the threshold will result in the API automatically increasing the timeout to equal the threshold. The periods available, by plan, are:
- 1 minute or 1 hour (Free and Pro)
- 1 minute, 1 hour, or 24 hours (Business)
- Any period between 10 seconds and 24 hours (Enterprise)
Custom error page
If you don't specify a custom error page, rate limiting visitors will get a default HTML page.
All paid plans can create a custom response to rate-limited clients, at most 32kB, in text, HTML via the Customize App.
In additon, Business and Enterprise customers can specify content-types and a response in the rule itself:
What thresholds should I use?
All domains are different and the appropriate threshold depends on your typical traffic profile and needs.
Generally speaking, you can calculate a rough estimate of your normal traffic volume across your entire site by dividing the uncached requests over a 24-hour period by unique visitors for the same period. Then, divide that number by the estimated average length of a visit, in minutes, to give you a rough idea of average requests per client per minute. Then, multiply that value by 4 (or larger) to establish a rough per-minute threshold for your entire site. If you are unsure, using a higher value is typically fine--most attacks are an order of magnitude above typical traffic rates.
To obtain a more specific threshold, you may wish to compare request rates over multiple days, or review individual days and base thresholds off of peak traffic times.
For specific URLs, you should be able to calculate a similar value by reviewing your local access logs (or your Enterprise log share if you are an Enterprise customer)/unique clients logged for that URL. If you have not done so already, you should restore original IPs in your access logs.
You should set your threshold well above this request rate to account for clients that send more legitimate requests than both. While valid outlying client traffic patterns will vary per site, quadruple the average request rate is probably a good baseline to defend against attacks. You can then adjust the thresholds based on user reports and your own monitoring.
If you are actively under attack and are unsure how best to mitigate it, file a support ticket and Cloudflare Support will help you review your traffic and make recommendations on appropriate thresholds.
How can I see how rules have been applied?
Self-service (Free, Pro, Business plans) customers will not see specific clients/requests that are rate limited. They can only see the aggregate data available in Analytics.