Site throttled due to congestion - possibly a result of 7z/Zip inclusion in default cached file extensions

Dear Cloudflare Community,

We are a long time Cloudflare user and Pro customer and it has saved out butts on many occasions (DDOS). Today we received an email that we’d been throttled due to excess usage. Upon looking into the issue we noticed Cloudflare recently changed their default cache file extensions to include 7z and zip (according to Wayback machine this occurred between October and November of 2021). We suspect this may have inadvertently caused our property to start violating Cloudflare’s ToS as we serve ton of archive files - but we never intended Cloudflare to cache these and have always served them via our own CDN.

My question is - is there a way to determine if the temporary throttling has been lifted?

Any help much appreciated.


ToS doesn’t distinguish between cached and non-cached. If it uses Cloudflare bandwidth, then ToS applies.

1 Like

Does anyone have any advice on what to do about this? We noticed our property is still considerably throttled when turning proxying back on. We have added page rules to bypass all caching of images and other static files. We have not received a response to a ticket we created yesterday, and also have not received a response from sales about upgrading to Business to end the throttling.

Thanks for any thoughts

You need enterprise for this, consider reaching out via chat and letting them know you’d like to schedule a meeting ASAP.
Just be aware that enterprise is pricey, especially if you are catching the attention of the abuse team since that means that you are consuming a considerable amount of bandwidth.
I think you might be able to get a cheaper quote if you let them know that you only need extra bandwidth and nothing else from the enterprise package.

Alternatively, you could use workers or host the problematic files elsewhere (CloudFront, BunnyCDN, etc).

1 Like

Thanks for your response. The email we received said the throttling would be temporary. We have completely switched off Cloudflare proxying for now. Are you aware of if/when the throttling is usually lifted? We have not used any Cloudflare bandwidth for about 20 hours.

We actually don’t need extra bandwidth - we believe we were throttled due to a configuration error we introduced a couple of weeks ago relating to 7z/zip archives.

It’s temporary in an effort for you to stop those activities completely; if those aren’t solved, then you will face more frequent and more strict throttles.

You do; otherwise, you wouldn’t have received that notification.

This is the problem.

2.8 Limitation on Serving Non-HTML Content

The Services are offered primarily as a platform to cache and serve web pages and websites. Unless explicitly included as part of a Paid Service purchased by you, you agree to use the Services solely for the purpose of
(i) serving web pages as viewed through a web browser or other functionally equivalent applications, including rendering Hypertext Markup Language (HTML) or other functional equivalents, and
(ii) serving web APIs subject to the restrictions set forth in this Section 2.8. Use of the Services for serving video or a disproportionate percentage of pictures, audio files, or other non-HTML content is prohibited, unless purchased separately as part of a Paid Service or expressly allowed under our Supplemental Terms for a specific Service. If we determine you have breached this Section 2.8, we may immediately suspend or restrict your use of the Services, or limit End User access to certain of your resources through the Services.

1 Like

Being curious what’s the historic bandwidth consumption numbers for 7z/zip archives and what size are these archives?

We serve archives of all different sizes, from a few kb to over a gb, and we transfer about a petabyte of them each month. We didn’t realize Cloudflare added these archive extensions as default cache extensions late last year. Before this, they were being bypassed. But we also accidentally enabled proxying of an archive serving subdomain about 3 weeks ago after migrating our file servers between hosts. We’d been using Cloudflare without issue for almost 10 years until yesterday.

It comes as a surprise that Cloudflare would add these archive extensions as default cache types - they can be absolutely massive and I wonder if other webmasters could inadvertently create congestion due to this change.

Sounds like this subdomain proxying is probably what put you over the ToS threshold as CF doesn’t care if it’s cached/uncached but rather if it’s proxied requests. So adding the extensions to default cached extensions wouldn’t have made the difference in your case if you still enabled CF proxy + uncached/bypassed. As that would still count in ToS. So only thing to do is makes sure that subdomain is the culprit and unproxy it (disable orange cloud) and let Cloudflare know that you have remedied the issue.

You can check your web analytics and filter by file extensions/mime types and hostnames to see historical bandwidth consumption to narrow the culprit down :slight_smile:

Thanks for the advice - we have switched off all proxying and have a ticket with support. I’m hoping they’re understanding of it being accidental rather than deliberate.

I did a quick calculation and it looks like 89% of our data transfer through Cloudflare was zip, rar and 7z over the past 7 days. Woops. Sincerely it was a configuration error.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.