Guides · DNS, Cloudflare & delivery · Published 2026-09-13 · 3 min read

Cloudflare DNS-Only vs Proxied in Front of Cloud Run — Why Domain Mappings Need the Grey Cloud, What the Orange Cloud Adds, and How to Import a Zone File Without Breaking Existing Records

Cloud Run domain mappings issue their own certificate and expect to see the domain resolve directly to Google. What breaks when Cloudflare proxies the records, when proxying is worth it anyway, and a safe way to bulk-import DNS records for a new site.

Cloudflare offers two modes for every DNS record: DNS-only, shown as a grey cloud, where Cloudflare answers the DNS query and nothing else; and proxied, the orange cloud, where traffic passes through Cloudflare's edge. For a site on Cloud Run with a domain mapping, the choice is not cosmetic. The mapping's certificate issuance depends on it.

Why domain mappings want DNS-only

When you map a custom domain to a Cloud Run service, Google provisions a managed certificate for it. To do that it needs to see the domain's A and AAAA records pointing at Google's front-end addresses and to complete a validation over HTTP or TLS on that path. If Cloudflare is proxying, the domain resolves to Cloudflare's addresses instead, validation cannot reach Google, and the mapping sits in a pending state indefinitely. The fix is to set the root and www records to DNS-only, wait for the certificate to be issued, and then decide whether to proxy.

What proxying adds, and costs

Proxied (orange)	DNS-only (grey)
Cloudflare's edge cache, WAF and bot rules in front of the app	Requests go straight to Google's front end
A second TLS certificate at the edge; origin certificate must still be valid	One certificate, managed by Cloud Run
Cloudflare's SSL mode must be Full (strict); Flexible causes redirect loops with a service that forces HTTPS	Nothing to configure
Visitor IP arrives in a header, not the connection	Visitor IP is in the connection
Domain mapping validation may fail if enabled before issuance	Validation works

For a small content site, DNS-only is simpler and Google's front end already terminates TLS and absorbs bursts. Proxying makes sense when you want Cloudflare's cache rules or firewall, or when you have a service that needs its origin hidden. If you switch to proxied later, do it after the mapping shows the certificate as active, and set SSL mode to Full (strict).

Importing a zone file for a new site

For a fresh domain you can add the records in one go by importing a BIND-format zone file: four A records and four AAAA records for the root pointing at the Cloud Run front-end addresses the mapping tells you to use, and a www CNAME to ghs.googlehosted.com. Two things to check first. If Cloudflare created placeholder records when the zone was added, such as a proxied www A record pointing at a documentation address, delete them; an import that conflicts with an existing record fails for that record and the rest are silently applied, which leaves a half-configured zone. And set the import's records to DNS-only for the reasons above.

Never bulk-delete records in a zone that also carries email or other services. If a domain already has MX records and a www CNAME to another host, add only the new names you need and leave the existing ones alone.

Verifying

Use dig or nslookup from a machine outside your network to check the root resolves to Google's addresses, then curl -I https://example.com and look for a server header and an x-cloud-trace-context header, which confirm the request reached Google rather than an error page at the edge. A root that briefly returns connection resets in the first minutes after the mapping is normal; it settles once the certificate is active. The full sequence from mapping to sitemap is in Cloud Run custom domains with Cloudflare DNS, and the health-check path caveat that looks like a DNS problem but is not is in the Cloud Run /healthz gotcha.

Common mistakes

Proxying before the certificate is issued. The mapping never completes.
Flexible SSL mode with an app that redirects HTTP to HTTPS. Infinite redirects.
Importing a zone file over placeholder records.
Touching records that belong to email.

Summary

Point the root and www at Cloud Run with DNS-only records, wait for the managed certificate, and only then consider the orange cloud with Full (strict) SSL. Import zone files onto a clean zone, and never disturb records that other services depend on.

cloudflare dns cloud run tls devops

Related guides

Redirect link service with Firestore — Build a go.example.com redirect service in Node and Express backed by Firestore: one document per slug, a 302 to the target, a per-month click counter, and an admin list. Why routing every outbound link through it saves you when programs change.
Node TLS errors behind antivirus or a proxy — When npm, fetch or gcloud fail TLS verification on one machine only, something is intercepting HTTPS and re-signing it. How to see whose certificate you are being handed, why Node ignores the Windows store by default, and the one flag that fixes it safely.
Search Console domain verification with Cloudflare — The fastest way to get a new domain into Search Console when DNS is on Cloudflare: choose a domain property, let Domain Connect add the TXT record, confirm, and submit the sitemap. What to do when the first sitemap fetch fails because the site is minutes old.
Cloud Run cold starts for Express — A scale-to-zero service pays for its first request after idle with a cold start. Where the time goes for a typical Node and Express app, how to measure it honestly, the changes that help (and the ones that do not), and the arithmetic for min-instances.