How does Rate Limiting work?

ratelimiting

#1

Rate Limiting is a feature that allows customers to identify and mitigate high request rates automatically, either for specific URLs or for an entire zone, with up to 100 rules total.

Rate Limiting is available on all plans.

Currently, Rate Limiting can be managed from the Cloudflare dashboard, as well as via API which will be documented on api.cloudflare.com.

You can find a more detailed breakdown of Rate Limiting and its features in our Help Center. Or ask your questions below.


#2

Rate limiting now has a UI (in addition to the API mentioned above).


#3

We have a standard website and I would like to have negative rules.

So, how can i go about allowing all JS, CSS and images but rate limit everything else? The current matching with just a * or folder level is very limiting!


#4

Rate limiting will only apply to requests to your origin, so if you’re utilizing Cloudflare’s caching then your css, js and images would (typically) already be in cache.


#5

thanks for getting back.

So if i have my website.com through standard CF setting. then can i turn on rate limiting on website.com/*? This is because each normal request to the website has around 60 assets (Css, images, js) to download. If i turn on rate limiting to say 50 requests per minute then it could potentially block legitimate traffic.

I would like to have negative rules to make sure that if cache is invalidated then cloudflare does not treat normal requests as a rate limit attack.

I hope I made some sense with comment above.


#6

It does, thanks for the clarification. I’ve taken the feedback for our product team. In the short term, I believe currently we’re allowing all plans to set longer sampling periods via the API which can allow for more focused rules and we are testing a “bypass” feature for rules with our Enterprise customers (so one could theoretically exclude example.com/*.css or example.com/static).

The challenge is that one could potentially mount a denial of service attack against a host by requesting assets which aren’t cachable or which had a short cache value set. So as we get more feedback from customers like you and real world usage statistics we’ll be providing more functionality and tweaks to make the feature more useful to customers.


#7

IMHO rate limit just make sense for those requests that are not cached, as stated by @cscharff. So, it doesn’t have to take into consideration requests for static assets like js, css, images, etc.

If the cache have a stale version of any static asset, Cloudflare proxy pull it from origin server at the next request and then cache it again. Nginx has a cache feature that put subsequent requests in a kind of queue when there is a resource being cached, so just the first request will reach origin.

I’m pretty sure that Cloudflare make good use of, or even better improved, this nginx feature.

I hope that could help you to clarify your question.


#8

Engineer here, working on part of the rate limit project.

Just to clarify, by default the rate limiting only applies to non-cached requests.

If you have static paths that you want to exclude from the rate limiter you can achieve this if you are on the Enterprise plan by using the “bypass” property documented here: https://api.cloudflare.com/#rate-limits-for-a-zone-properties

That would allow you to express: Apply rate limit to /* except if the path is /img/* or /js/* or /css/*

In that scenario, none of the traffic to /img/ /js/ or /css/ would count towards the rate limiter even if the caches were cold.


#9

So, if you use /* as a rule, rate limiter will consider static assets.
Unless you have a enterprise account where you can set a exception for static assets.

Is that assumption correct?


#10

Not quite. It will not count any cache hits, which most static assets fall under (see this KB article).

Thus, with a rule for example.com/* -

  • /admin/you would be rate limited
  • A cache hit against /assets/site.js would not be rate limited
  • A cache fetch (miss) against /assets/style.css would be rate limited, if that connecting IP was already pushing up against the rate limiter.

On a site with 50 same origin requests, a majority of those are likely to be cachable assets (images, JS, CSS) and would thus not count towards a rate limit when served from cache.


#11

So, @london-digi’s point is true, but only if previously cached assets have to be fetched from origin again.

This is a very interesting scenario.


#12

Yes, this could easily happen for a website.

A simple solution is to have some sort of negative list so we can set * URLs except css / js / images or even say exclude directories like wp-content/ or so.


#13

There are three types of response for static images that I can see CF-Cache-Status: HIT, CF-Cache-Status: MISS and CF-Cache-Status: REVALIDATED

I understand that MISS will count towards the rate limiting for the IP. Can you please confirm that HIT and REVALIDATED do not count towards rate limiting?

I am just trying to make sure that we can set the rate limit to as low as possible without affecting normal users.


#14

maybe allow cloudflare users to set a custom header on their origin backends which they can setup in cloudflare rate limiting to detectthat custom header on their origin backends and exclude or include them in rate limiting at cloudflare level ?


#15

Not a bad idea. We are currently testing a bypass feature with our ENT customers which allows you to exclude paths/patterns, but the option for origin to educate us about what resources are OK to be pulled at any rate would be interesting.

Since rate limiting is such a new feature I anticipate we’ll see a number of iterations to tweak and improve the feature over time. We have some other cool items on the roadmap this year which I think will also also help with the larger problem trying to be solved.

From a personal standpoint my worry/concern is that we roll out these kind of features in a way that a non-expert user can take advantage of them without having to be an expert (while still allowing power users to tweak the settings to get even more out of them).


#16

well headers can be added by .htaccess for apache or via nginx directives which isn’t any more difficult than the requirements for setting up real ip detection and/or cloudflare ip whitelisting within apache or nginx i.e. https://support.cloudflare.com/hc/en-us/sections/200805497 :slight_smile:


#17

I was actually a beta tester of the Cloudflare Rate Limiting Product, it’s nice in that Cloudflare does the rate limits at their edge rather than the user’s origin server. Because of this the already overwhelmed origin doesn’t receive additional tasks and become unable to keep up with the tasks. It’s very well implemented.


#18

I guess I am a bit late to this party, but I am looking at enabling rate limiting as well and have some of the same questions. I just want to make sure that my assumptions are correct (as I’m a bit of a noob at this).

I have a page that makes 94 requests upon page load (it’s a list that contains quite a lot of images). Of those requests 68 are images, 9 are js, 5 are css, and 4 are fonts. The remaining 8 are XHR / Other requests.

Now, anything that is cached within Cloudflare will not count as a request if it is successfully retrieved from said cache. Would this statement be true?

So, in theory, since those 68 images are static, they should be cached in Cloudflare. So those shouldn’t count. Same would go for the JS / CSS / Fonts I would assume (which some of those are served from a cdn anyway).

So, in theory, this page loading would potentially hit the rate limiter would tally 8 requests in the two to four seconds it takes this page to load.

Am I following along the correct path, or am I completely helpless? Somewhere in between? Haha. Thanks in advance.


#19

Yes.

Yes, in theory. In practice it depends on are they cached. Maybe the cache will be flushed and you will have a new request again.
A new request from different geo position will hit different CF DC, on which if it is not cached already (and if not using Argo) will hit the origin again.

You will have to set the limits yourself, as you can see what rates are OK for you.
Take a look at the bot rates, at the visitor rates at the site/hosting acceptable rate.
Keep in mind that in one second a bot and a human, can make the same number of requests.
In 1,5 or 10 minutes, not so much. :smile:

Take a look at the How we built rate limiting capable of scaling to millions of domains and a help center.


#20

A post was split to a new topic: “Page isn’t redirecting properly” errors on wp-admin