[Support Guide] What problems could occur when using Cloudflare in front of Netlify?

Last reviewed by Netlify Support - June, 2024

Note: We recommend not using both Cloudflare’s CDN (“Accelerate and Protect”, the orange cloud in their UI) and Netlify for the same site at the same time. Why? Read on!

Netlify’s web service is not designed to work optimally with another CDN “in front of” our CDN. Proxying to our service is in general not supported and we advise you not to do it for best hosting results.

Cloudflare has made similar statements that it doesn’t recommend this usage as well:

“A lot of Netlify and Vercel customers actually put Cloudflare in front of their Netlify or Vercel sites,” he added. That doesn’t really make sense when it comes to cost and performance as you’re stacking multiple CDNs."

Using Cloudflare in this way will cause issues with Netlify features such as:

  • atomic deploys and rollbacks (Cloudflare may cache assets for most customers, for longer than our default settings specify). This would lead to changes you make not showing up immediately on the web. Ensure you have no caching set at cloudflare for Netlify-served routes - or you will see problems!
  • Proxying to us completely breaks some of our features and services, like Analytics (you’ll find incorrect visitor counts, since only Cloudflare’s CDN nodes visit your sites) and Split Testing simply won’t work.
  • Provide slower service than using our CDN directly (measured by a customer over a few months, using google webmaster tools, but you can also imagine that without caching, this is an extra network hop for your visitors that cannot reduce the time to first byte…)
  • our Support team do not have any visibility into what happens to network requests that go through Cloudflare’s CDN (which always happens if you use the orange cloud), so we cannot easily advise you on problems in your configuration or help you debug connection trouble.
  • and occasionally, catastrophic failures have been observed using this setup, and something goes wrong in the proxying. In these cases the only effective, quick fix has been disabling Cloudflare’s proxying as shown below.

For these reasons, we recommend disabling Cloudflare’s proxying (also known as “Accelerated and protected” on their service) for your site when it is being served/hosted by Netlify.

This image shows how to disable Cloudflare’s proxying, but continue using their DNS, which works great with our CDN as long as you disable proxying:

If you are making this change, you’ll need two things:

  1. You’ll need to make sure that our UI is configured for ALL OF your production domain(s). On the Domain settings page, ensure that all hostnames that you were using via proxy at Cloudflare are set in our UI.
  2. You’ll need an SSL certificate to cover these names to be in place at Netlify. If you haven’t purchased a certificate from someone else (details in this article), we’ll protect you with an automatically managed and renewed Let’s Encrypt certificate. After you change your DNS settings in our UI, we’ll start repeatedly trying to fetch a certificate for you (for as much as the next 3 days after your change), but there will likely be some downtime while your settings change at Cloudflare (which are DNS changes) propagate. This article describes what kind of delay you can expect on this process and how to make sure it goes as quickly as possible.

If you still want to proxy from Cloudflare, we can’t stop you. You may find this customer-supplied (written by @chrism2671!) Build Plugin helps mitigate the situation around them not providing a “no-cache” option for people below their Enterprise account level: GitHub - chrism2671/netlify-purge-cloudflare-on-deploy: Automatically purge Cloudflare cache on Netlify deploy.

Also please note that even if you are not following our advice, and are connecting to Netlify from Cloudflare, there is no reason to use a Cloudflare Origin Certificate on our systems EVER. You’d connect to your https://sitename.netlify.app directly - instead of installing and having them using the broken-for-use-in-normal-browsers certificate Cloudflare provides. There is no benefit to using their certificate at Netlify, but it has caused downtime for more than one customer when they tried to transition off of it.

If you have any questions about this, we’ll be happy to discuss in more detail! Please feel empowered to ask BEFORE you make changes, so we can guide you to the smoothest migration experience.


(asking for the audience) will I be charged for bandwidth when I am DDOSed? what are some recommended ways to add DDOS protection for my Netlify site?


Netlify pays for all bandwidth that is used by our service. We can only keep our service free for low usage sites when they are in fact low usage. If your site uses more bandwidth than the free allotment for any reason during a billing cycle, you will be liable for it, similar to AWS’ policy on the same topic.

Fortunately, we don’t take your site down when you have high usage - we allow it to keep running, since an appearance on shark tank or hacker news may look like an attack, but we try to keep your site up as long as the attack isn’t affecting the rest of our service.


For this, you may still want to go through Cloudflare.
(For example, increase of transfer amount, attack, etc.)

So instead of using Let’s Encrypt, you can apply Origin certificates issued by Cloudflare.
It can be issued for free and can last up to 15 years.

Hi, @balloon, while you can do this it greatly limits our support team’s ability to troubleshoot any redirect, proxy, or site down issues for your site.

Please note we may ask you to disable the Cloudflare proxy to troubleshoot any connectivity or routing issues as we are not able to do so with another service proxying to ours.

@balloon, is Full (strict) mode required when using Cloudflare in front of Netlify?

I just tried to set this up and was receiving intermittent certificate warnings when accessing my site. I set the intermediate cert on Netlify using the root certificate from the page you linked.

Now I have it set to Full and it seems to be working fine …

Yes. If you have introduced Origin Certificates, you can choose Full (strict). That is the perfect choice.
Or TLS communication is maintained even with Full.

I often see the troubles associated with Let’s Encrypt when using Cloudflare. This is not only a problem with Netlify, but some services have staff in trouble.
For example, ZEIT Now (zeit.co and now.sh) adds this to the documentation:
Domains – Vercel Docs

But we around the world are choosing Cloudflare. And we also chose Netlify. Please recognize that fact and utilize it in the future.
I got your response and once I moved all the services I had from Netlify to other services.

1 Like

Thanks for the suggestion, @balloon ! As Luke mentioned, using Cloudflare to front to our services has tons of problems (the ones that started this post, and more general descriptions of the higher level problems here: [Support Guide] Why not proxy to Netlify?). Since this isn’t a use pattern we can support for our CDN, I don’t think we’ll probably write code to enable the unsupported setup to incorporate lets encrypt SSL - we already provide SSL at the netlify hostname which you can tell cloudflare to connect to directly :)).

If you want to use Cloudflare, please do! It’s a great service! It just doesn’t work well in proxy mode with our CDN, so we won’t try to imply that it might work well by working around configurations that currently make it obvious to the end-user that this is not a good setup.

Hey guys,
Does using Cloudflare has any impact on the deploy preview generated by Netlify under the netlify.app domain (i.e: caching) ? as in:


Hi, @zanona. No URLs with domain names ending with netlify.app will go through Cloudflare, so that is not the issue here.

The root cause in this case is that these are manual deploys. Manual deploys which use an “alias” or “branch” option are not treated identically to branch deploys with a build at Netlify.

You cannot use the branch subdomain feature with manual deploys at this time. We have an open feature request to make manual deploys with a branch option to work identically to branch deploys at Netlify. However, at this time, that feature request remains “open”.

If/when it is possible to use the branch subdomain features with manual deploys we will post an update here to let you know. If there are other questions, please let us know.

Thanks so much for clarifying, Luke, and apologies for the noise under this thread, as my case feels unrelated.

So I take it that aliases will never override past branch deploys URLs. What you would recommend in this case? Recreating the site on Netlify and disable auto-publishing? Would those aliases such as next become available if we do that? — So far, aliases were working fine for the ‘alpha’ branch for us, as we never had an auto published branch deploy for that one

I guess that’d be simpler than changing the git development branch name itself :smile: Just trying to think on a way to clear all those cached URLs. Perhaps is there anything else you could advise?

Thanks again for following up

I bumped into the same problem and solved it. The image in the OP needs some explainer text.

Basically, to disable Cloudflare’s DNS Proxy to be “DNS only”, you have to click Edit, and in the edit panel, click on the orange cloud icon and it will toggle to DNS only. Hit save.

Then I was able to renew my cert at Netlify right after.

What about the A records? I use an IP that showed up when I entered my domain in netlify and disabled the proxy.
I redirect to non-www so i can’t delete it.
Can I use those shown by dig netlify.app and www.netlify.app as backup or are there official ones?

As I understand it now, the way would be to add a CNAME with the root pointing to the app subdomain and let cloudfares CNAME flattening do the work. Am I correct?

A records are fine on Cloudflare (and everywhere). However, you should never use any A records for Netlify, except the ones we publish in our documentation (our many CDN nodes all have A records and none should be used directly since they can and will go in and out of rotation.) You can successfully use regular CNAME or flattened CNAME - without the proxy - which will both give better results performancewise and stabilitywise.

Here’s the docs you need on that configuration: Configure external DNS for a custom domain | Netlify Docs

Thank’s for the link. Indeed that’s the A record I used. Changed to unproxied flattended CNAME, it realy doesn’t make a difference to me performance wise.
Only difference is that for the apex I don’t need the www subdomain, wheras for the flattened CNAME i need both.