Last reviewed by Netlify Support in May 2024
Netlify’s CDN automatically routes your web visitors’ traffic to a network-nearby server to give them the fastest possible response time…as long as you let their browsers talk directly to our CDN!
We know you want your your web traffic to be fast; your deploys and rollbacks to be atomic; and your Analytics data to be useful.
If you proxy to Netlify, you’ll have problems with all of the above - since those features of our service are only possible if you configure your DNS to point directly to Netlify, rather than through a proxy server or service. Why’s that?
Let’s dig in!
There are many capable network providers out in the world - from the Google- and Amazon-sized giants, through more CDN-specific offerings like Cloudflare and Akamai and Fastly. We do not disagree - they’re great at what they do! Our own CDN is partially powered by Google and Amazon’s cloud offerings. But, when you use them in front of Netlify’s CDN, they break all of those great features I described above.
Here’s why putting a proxy in front of our network is a bad idea:
- Speed: putting an extra network hop like Cloudflare or Fastly in front of us adds another point of failure in the request path, and “more network hops” is nearly guaranteed to make the connection slower.
- Atomic rollbacks and deploys: Most CDN providers cache some content, which can break our atomic rollbacks and deploys - making sure your site content is consistent across all browsers accessing the site at any specific moment in time.
- More accurate analytics: Our Analytics service counts IP addresses to approximate “Unique Visitors”. If you put Cloudflare in front, only Cloudflare’s IPs talk to us, so you get situations like: “104 unique visitors loaded how many hundred thousand pages?”
- Our split testing feature will not work reliably: When you enable split testing, requests directly to our CDN are handled correctly. Requests to other CDN’s that cache content will break the affiliation and potentially serve visitors mixed content from all of your actively-testing branches.
- Quicker, more straightforward help: And finally, we can’t usefully provide tech support when there’s a “black box” between the browser and our service. The owners of the black box may be able to, but we can’t help with what we can’t see, no matter how much you pay us.
- In some cases, we’ll rate limit vast numbers of connections to your site (returning an HTTP 429), more than a visitor would make in the same time frame, to help block abusive traffic. Your proxy host could look like abusive traffic to our CDN, if it sends enough quickly enough from the same IP address - this would cause your site to appear down for many visitors, even though Netlify is up and running and willing to serve your site - to any other IP than the one that is flooding us.
This article goes into some more depth about how to configure Cloudflare’s DNS to NOT proxy to us, and goes into more details about the specific pitfalls we’ve seen before using Cloudflare “in front of” Netlify. Can you do it? Sure! Thousands do! But… from the members of that group who’ve written in for tech support, the overwhelming majority of our “problem solved!” successful answers have been achieved by this answer: “It will work if you turn off that proxying…”
If you cannot change your proxying-to-Netlify configuration for some reason, on a plan without our HP Edge CDN, you should ensure it points to yoursitename.netlify.app.
Please note that we will not provide any further tech support on that configuration for any customers below the Enterprise account level, as it causes all the problems listed in this article and we generally do not intend for people to configure their sites this way.