Feb 7, 2026

Last updated on Apr 9, 2026

Cloudflare DNS Guide: Root and www Setup, Proxy Mode, and Vercel Checks

Cloudflare DNS problems rarely look like “just DNS” in the real world. What usually breaks is the public request path around DNS: the wrong host becomes the public version, www and the root domain behave differently, proxy mode adds another layer, SSL settles slowly, or ads.txt is only reachable on one hostname.

That is why a setup can look correct in Cloudflare or Vercel dashboards while search engines, ad network review, or real visitors still see something inconsistent.

This guide is the practical version:

which records Vercel usually expects
how to decide between the root domain and www
when Cloudflare proxy mode is useful
what to check before you trust the setup

The short version: pick one public hostname, configure both hosts intentionally, keep DNS and redirects simple, and verify the final browser path instead of trusting the dashboard alone.

Quick answer

For a typical Cloudflare plus Vercel blog or frontend:

choose one public host such as www.example.com
add both the apex domain and www in Vercel
configure the apex with the record Vercel asks for and the subdomain with the expected CNAME
make the non-primary host redirect cleanly to the primary host
check robots.txt, sitemap-index.xml, and ads.txt on the public host
only add Cloudflare proxy behavior or redirect rules that you truly need

If any of those are inconsistent, the issue will often show up as an indexing, review, or SSL problem instead of an obvious DNS error.

Start with one public host

The biggest practical DNS mistake is not the record type. It is failing to decide which hostname is actually public.

For example, do you want:

https://example.com/
or https://www.example.com/

Vercel’s domain documentation says that if you add an apex domain, Vercel will prompt you to add the www subdomain too, and it recommends explicitly adding and redirecting the alternate host for more robust protection.

That matters because the public host should be consistent across:

the homepage
blog posts
canonical URLs
hreflang
robots.txt
sitemap-index.xml
ads.txt

If your public host is www, the apex should redirect to www. If your public host is the apex, www should redirect to the apex. What matters is not the choice itself. It is the consistency.

The DNS records Vercel usually expects

Vercel’s domain setup docs are fairly direct:

apex domain like example.com: usually configure an A record
subdomain like www.example.com: usually configure a CNAME
domain verification: often uses a TXT record when required

That simple mapping solves most setups.

Cloudflare also supports CNAME flattening at the zone apex, which allows apex CNAME usage in some cases. But if Vercel is explicitly asking you for an apex A record, the safest starting point is to follow the record type Vercel expects instead of getting clever early.

Proxy mode is a tradeoff, not a religion

Cloudflare’s DNS docs recommend proxying A, AAAA, and CNAME records that serve web traffic. That is the normal reason people use Cloudflare in front of a site.

At the same time, Vercel’s reverse proxy documentation says it does not recommend placing a reverse proxy in front of a Vercel project because it affects firewall visibility and real client IP handling. Vercel also documents that Cloudflare is one of the supported providers for Verified Proxy Lite.

So the practical answer is:

if you need Cloudflare edge protection or other proxy features, proxied mode can be valid
if you only need a clean domain connection and easier incident isolation, avoid stacking unnecessary proxy, cache, and redirect behavior

That means DNS only is not automatically “better” and proxied mode is not automatically “wrong.” The right question is whether you actually need the extra layer.

Root and www must behave like one system

Many deployments fail review or indexing not because the domain is down, but because the two hostnames do not behave as one coherent site.

Common examples:

https://example.com/ loads, but https://www.example.com/ fails
both hosts load, but each serves different canonicals
the homepage redirects correctly, but /ads.txt does not
Search Console is watching one host while the live site resolves on the other

For ad network review in particular, this becomes painful fast. The host you submit, the host that serves the site, and the host that exposes /ads.txt should not disagree.

If your chosen public host is https://www.example.com, make sure all of these are true:

https://example.com/ redirects to https://www.example.com/
https://example.com/ads.txt also ends up at the public host in a clean way
the canonical URL rendered in page HTML matches the public host
the sitemap and robots paths are aligned with the same host

Check the public path, not just the dashboard

You can confirm the important path with a few quick header checks:

curl -I https://example.com/
curl -I https://www.example.com/
curl -I https://www.example.com/ads.txt

What you want to see is one clean story:

the non-primary host redirects once
the primary host returns 200 OK
key review files such as ads.txt resolve on the public host

If the dashboard is green but the public path still bounces, loops, or splits by hostname, the domain setup is not actually finished.

If you proxy Cloudflare in front of Vercel

This is the part many teams skip.

If you intentionally keep Cloudflare proxying in front of Vercel, Vercel’s reverse proxy documentation says you should avoid breaking:

http://<DOMAIN>/.well-known/acme-challenge/* with forced HTTP to HTTPS redirects on port 80 during TLS setup
https://<DOMAIN>/.well-known/vercel/* with caching

You should also avoid duplicating host and HTTPS redirect logic across both platforms at the same time.

A common bad pattern looks like this:

Vercel forces HTTPS
Cloudflare forces HTTPS
a Cloudflare redirect rule rewrites hostnames again

Each step looks reasonable by itself. Together, they produce loops or confusing partial failures.

Common mistakes

1. Only one hostname is fully configured

The apex works but www is not added in Vercel, or the reverse.

2. Proxy mode is enabled without a clear reason

Extra layers are fine when they are intentional. They are expensive when they only make debugging harder.

3. `ads.txt` works on one host but not the public host

This is especially risky during ad network troubleshooting because the review host and file path stop matching.

4. Canonical metadata disagrees with the live host

The browser ends at one host, but the HTML points search engines to another.

5. CNAME flattening is treated like a shortcut for every case

Cloudflare supports apex CNAME flattening, but it is still better to start from the DNS record type your platform expects. Cloudflare also notes that flattening all CNAME records can break some third-party verification flows.

6. The dashboard looks healthy, so no one checks the final response

The dashboard is not the final truth. The public response path is.

A practical debugging order

When something feels wrong, check in this order:

which hostname is meant to be public
whether both the apex and www are added in Vercel
whether the record type matches what Vercel expects
whether Cloudflare proxy status is intentional
whether redirects end in one clean host with a 200
whether robots.txt, sitemap-index.xml, and ads.txt resolve on that public host
whether canonical and hreflang output match the final host

This order usually finds the real cause faster than staring at the DNS table alone.

FAQ

Q. Should I always use `www` with Vercel?

Not always, but Vercel does explicitly prompt you to add www when you add an apex domain and recommends adding and redirecting the alternate host. The important part is choosing one public host and being consistent.

Q. Is Cloudflare proxy mode wrong for Vercel?

No. Cloudflare is listed as a supported provider for Vercel’s Verified Proxy Lite. But Vercel also explains that reverse proxy layers add operational tradeoffs, so use proxying intentionally instead of by habit.

Q. Should I use an apex CNAME because Cloudflare supports CNAME flattening?

Only if it matches your platform requirements and you know why you are doing it. If Vercel asks for an apex A record, start there.

Q. Why does the dashboard say connected while the browser still looks broken?

Because DNS, SSL, redirects, and proxy behavior do not always settle at the same time or in the same place.

Official References

Start Here

Continue with the core guides that pull steady search traffic.