Netlify and Cloudflare work together in two distinct configurations. The simple one keeps Cloudflare as the DNS host only: two CNAME records pointing at your Netlify site, both set to DNS only, and Netlify issues and renews the certificate exactly as it would with any registrar. The proxied one puts Cloudflare’s edge in front of Netlify’s edge, which requires the SSL mode set to Full (strict), a certificate on the Netlify side that Cloudflare can verify, and the .well-known/acme-challenge path left reachable over plain HTTP, or Netlify’s automatic certificate renewal silently fails a few months in. Most sites want the simple one. The proxied one is for people who need Cloudflare’s firewall, access rules or caching in front of a site that already has a CDN.
Netlify already is a CDN with TLS and a global edge. Putting Cloudflare in front of it adds a second edge with its own cache, its own certificate, and its own opinions about redirects. That can be worth it, and it is worth it for fewer sites than the number of tutorials suggests. This post does both setups and states when each one is the right call.
Table of contents
- Setup A: Cloudflare for DNS only
- Setup B: Cloudflare proxied in front of Netlify
- The problems that only appear with the proxy on
- Do you need the proxy at all?
- Checking it is right
- How this fits the rest of the stack
- FAQ
Setup A: Cloudflare for DNS only
This is the configuration Netlify’s own documentation recommends when you keep DNS at a third party, and it has no moving parts once the records are in.
- In Netlify, add the custom domain under Domain management. Note the site’s
something.netlify.apphostname. - In Cloudflare DNS, add a CNAME for
wwwpointing at that hostname, and a CNAME for the apex@pointing at the same. Cloudflare flattens the apex CNAME into an A record automatically, so you do not need Netlify’s load balancer IP. - Set both records to DNS only, the grey cloud. This is the step most guides get wrong by omission.
- Back in Netlify, wait for the domain to verify, then let it provision the certificate. It uses an ACME HTTP challenge against
/.well-known/acme-challenge/, which succeeds because traffic is going straight to Netlify. - Set your primary domain in Netlify so it redirects the other to the canonical one.
That is complete. Netlify serves the site from its edge, renews the certificate itself, and handles redirects from its _redirects file or netlify.toml. Cloudflare’s only job is answering DNS queries, which it does quickly and for free.
Setup B: Cloudflare proxied in front of Netlify
Turning on the orange cloud puts Cloudflare between visitors and Netlify. Three things must be true or the site breaks in ways that look random.
- SSL/TLS mode must be Full (strict). Flexible mode makes Cloudflare talk plain HTTP to Netlify, and Netlify redirects HTTP to HTTPS, which produces an infinite redirect loop. Full without strict accepts any certificate on the origin and is a downgrade in security for no benefit. Full (strict) verifies Netlify’s certificate, which is valid, so it just works.
- Netlify’s certificate must keep renewing. Netlify’s automatic certificate uses an HTTP-01 challenge. With the proxy on, the challenge request reaches Cloudflare first. If Always Use HTTPS or an HTTPS-redirect rule catches
/.well-known/acme-challenge/, the challenge fails and the certificate lapses at the next renewal. Either add a Configuration Rule that disables the HTTPS redirect for that path, or upload a Cloudflare Origin CA certificate to Netlify as a custom certificate, which does not need renewing through ACME. - Redirects must live in one place. If Cloudflare redirects
wwwto apex and Netlify redirects apex towww, you have another loop. Pick Netlify’s primary-domain setting or Cloudflare’s rules, not both.
Cloudflare SSL/TLS -> Overview -> Full (strict)
Cloudflare Rules -> Configuration Rules ->
match URI Path starts with /.well-known/acme-challenge/
-> Automatic HTTPS Rewrites: off, Always Use HTTPS: off
With those in place, add the same two CNAME records as Setup A and toggle them to proxied. Cloudflare’s cache will now serve static assets from its edge, its WAF and rate-limiting rules apply, and the IP visitors connect to is Cloudflare’s.
The problems that only appear with the proxy on
Beyond the redirect loop and the certificate lapse, a few things change behaviour and are worth knowing before they become a support ticket.
- Two caches. Netlify invalidates its cache on every deploy. Cloudflare does not know a deploy happened. HTML is not cached by default, but assets with long cache headers can be served stale by Cloudflare after a deploy unless you purge or use versioned filenames, which most build tools do.
- Netlify’s analytics and edge features see Cloudflare’s IPs. Anything on the Netlify side keyed on visitor IP, including its own rate limiting, sees one of Cloudflare’s addresses instead of the visitor. Netlify does read the forwarded headers for most purposes, but do not be surprised when a country-based redirect behaves oddly.
- Netlify Forms and Functions. Both work through the proxy. Function response times gain a hop; form submissions pass through unchanged.
- Deploy previews and branch subdomains are on
netlify.apphostnames and unaffected.
Do you need the proxy at all?
The honest answer for a static marketing site, a documentation site or a portfolio is no. Netlify already serves from a global edge over TLS with HTTP/2 and Brotli, and the second edge adds latency for cache misses, two places to debug, and the certificate trap above, in exchange for caching that was already happening.
The proxy earns its place when you want something Cloudflare provides that Netlify does not: firewall rules that block by country or ASN, managed WAF rules, bot filtering, Access in front of a staging site, or Workers that rewrite requests at the edge. If you are turning it on for speed alone, measure first, because the measurement often shows no gain.
A middle option is to leave the site records DNS only and proxy only the subdomains that need protecting, such as an API or an admin tool that lives somewhere other than Netlify. Cloudflare’s proxy is per record, and mixing is fine.
Checking it is right
# who answers: Netlify directly, or Cloudflare?
curl -sI https://www.example.com | grep -iE "server|cf-ray"
# certificate issuer and expiry as seen by a visitor
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -enddate
# ACME path reachable over plain HTTP without a redirect?
curl -sI http://www.example.com/.well-known/acme-challenge/test | head -1
A cf-ray header means the proxy is on. An issuer of Let’s Encrypt with a date more than a couple of months out means Netlify’s renewal is working. A 301 on the ACME path check means the next renewal will fail and you should fix the rule now rather than when the certificate expires.
How this fits the rest of the stack
The reason to keep a diagram of which edge does what is that each edge is a line on a bill and a place to look when something is slow. On RunxBuild, custom domains are handled the way Setup A works: set the CNAME, the certificate is issued and renewed for you, and headers and redirects live in one place in the repository. The RunxBuild hosting calculator shows the static site with its 120GB of included bandwidth next to any service behind it, so the value of a second CDN can be judged against what the first one already covers.
Useful related references:
- Django on Netlify: Why It Does Not Work, and What To Do Instead
- Branch Deploy on Netlify: How It Works and When to Use One
- Netlify Templates: What Starter Templates Give You and What They Do Not
- Services on RunxBuild
FAQ
How do I point a Cloudflare domain at Netlify?
Add two CNAME records in Cloudflare DNS, one for www and one for the apex, both pointing at your site’s netlify.app hostname, and set both to DNS only. Cloudflare flattens the apex CNAME automatically. Then let Netlify verify the domain and issue the certificate.
Which Cloudflare SSL mode should I use with Netlify?
Full (strict), if you proxy traffic through Cloudflare. Flexible causes a redirect loop because Netlify redirects HTTP to HTTPS. If the records are DNS only, the Cloudflare SSL mode has no effect because traffic never touches Cloudflare’s proxy.
Why did my Netlify certificate stop renewing after enabling the Cloudflare proxy?
Netlify renews via an HTTP-01 challenge at /.well-known/acme-challenge/. If Cloudflare redirects that path to HTTPS or blocks it, the challenge fails. Add a Configuration Rule that disables Always Use HTTPS for that path, or upload a Cloudflare Origin CA certificate to Netlify as a custom certificate.
Does using Cloudflare in front of Netlify make the site faster?
Usually not measurably, because Netlify already serves from a global edge over TLS with compression. The proxy adds a hop on cache misses. Enable it for Cloudflare’s firewall, bot filtering, Access or Workers, and measure before enabling it for speed alone.
Can I proxy some records and not others?
Yes. The proxy toggle is per DNS record. A common pattern is to leave the Netlify site records DNS only and proxy only an API or admin subdomain hosted elsewhere that benefits from Cloudflare’s protection.