Cloudflare in DNS-only mode isn’t doing anything for you.

A WordPress site running on Cloudflare in "DNS only" mode is getting almost none of what Cloudflare actually does. Edge caching, HTTP/3, modern compression, bot mitigation, DDoS protection, origin hiding — all of it requires the orange-cloud toggle that most sites never flipped. This is the highest-leverage WordPress infrastructure upgrade that's already paid for and waiting to be turned on. Here's what changes when you flip it, and what to handle before you do.

Most WordPress sites that have Cloudflare set up have it in “DNS only” mode. In that mode, Cloudflare is functioning as nothing more than a DNS provider: the site’s traffic bypasses Cloudflare’s edge network entirely and connects directly to the origin server. The site owner gets none of the security, performance, or reliability benefits Cloudflare actually offers. Flipping one toggle in the Cloudflare dashboard changes that.

This is the most common “you already have the tool, you just haven’t turned it on” situation on the modern WordPress stack. The upgrade is free, takes an afternoon, and unlocks most of what Cloudflare exists to do.

DNS-only vs Proxied: what the modes actually mean.

The toggle is the orange-cloud icon next to each DNS record in the Cloudflare dashboard. Gray cloud is DNS-only; orange cloud is Proxied. The difference in behavior:

• DNS only (gray cloud). Cloudflare provides the DNS records that map the domain to the origin server’s IP address. The visitor’s browser resolves the domain through Cloudflare, gets back the origin IP, then connects directly to the origin. Cloudflare never sees the traffic itself, only the DNS lookup.
• Proxied (orange cloud). Cloudflare resolves the domain to a Cloudflare IP. The visitor connects to Cloudflare’s edge network. Cloudflare then forwards the request to the origin (or serves it from cache). All traffic passes through Cloudflare’s infrastructure.

Every meaningful feature Cloudflare offers — caching, security, performance optimization, DDoS protection — requires traffic to actually go through Cloudflare. Which means it requires the orange cloud. In DNS-only mode, none of it is active.

What flipping to Proxied actually gives you.

With the proxy on, the relevant features (most of them free, available on every Cloudflare account) become live:

• Edge caching. Static assets (images, CSS, JavaScript, and optionally HTML) get served from the Cloudflare edge node closest to the visitor. The visitor sees the page faster; the origin server handles less load. For sites with global traffic, this alone is a meaningful speed-up.
• Tiered Cache. A hierarchical cache where regional upper-tier data centers cache content before it reaches the edge. Even cache misses are faster because the upper tier often has what’s needed and the origin doesn’t get hit.
• HTTP/3 with QUIC. The current generation of HTTP protocol. Faster initial connection (no separate TLS handshake round-trip), better recovery from packet loss, materially better performance on mobile networks. Cloudflare turns it on at the edge with one setting; the origin doesn’t have to support it.
• Brotli and Zstandard compression. Modern compression algorithms applied on the fly to text-based responses. Significantly smaller payload than Gzip; faster page render. Again, Cloudflare handles it at the edge; the origin’s compression configuration doesn’t matter.
• Bot Fight Mode. Automated detection and blocking of brute-force login attempts, credential stuffing, and malicious scrapers. Stops the requests at the edge before they reach WordPress, which means the origin server never spends CPU on them and the malicious traffic never gets the chance to log in.
• Full (Strict) SSL. Enforces a valid TLS certificate between Cloudflare and the origin, closing the “encrypted but not validated” gap that exists in less-strict SSL modes. Combined with “Always Use HTTPS,” this gives end-to-end encryption with no mixed-content edge cases.
• DDoS protection. Cloudflare’s network absorbs DDoS attacks at the edge. The origin server doesn’t see the flood. This is the kind of protection enterprise hosting providers charge meaningfully for, and Cloudflare includes the basic version on every plan.
• Origin IP hiding. When Cloudflare is in front of the origin, the origin’s real IP isn’t publicly visible. Direct-to-origin attacks (the technique attackers use to bypass a CDN once they’ve found the origin IP) get significantly harder to execute.
• Geolocation headers. Cloudflare adds country, region, and city headers to every request reaching the origin. The WordPress site can use these for localization, content routing, or analytics without needing a separate IP-lookup service or third-party JavaScript — and without triggering the “allow location” browser prompt.

Every item on this list is something a typical WordPress site needs and most don’t have. The Cloudflare account already has all of it sitting one toggle away.

Why so many sites are stuck in DNS-only.

A few common reasons the orange cloud never got turned on:

• The site was set up on Cloudflare for “free SSL” or DNS management without anyone explaining what the proxy actually does.
• The hosting provider’s documentation says to use DNS-only mode because the host runs its own CDN and doesn’t want to interact with another one. (Sometimes the host’s CDN is excellent; sometimes the recommendation is left over from a previous architecture.)
• The team tried Proxied mode once, hit a configuration issue, switched back, and never returned — often a TLS mismatch or an unrelated origin issue that got blamed on Cloudflare.
• Migration risk. Flipping a production site’s DNS routing without testing first feels scary, so the toggle never gets touched.

None of these are reasons to leave the upgrade indefinitely on the table.

What can break (the honest part).

Things to handle before flipping the toggle:

• Origin SSL certificate. Cloudflare’s Full (Strict) mode requires a valid TLS certificate on the origin. Self-signed or expired certs will fail. The fix is usually a free Let’s Encrypt cert or a Cloudflare Origin Certificate (free, issued by Cloudflare specifically for the origin).
• Real visitor IP. Once traffic flows through Cloudflare, the origin sees Cloudflare’s IP addresses instead of the real visitor IPs. WordPress and any logging or rate-limiting plugins need to be configured to read the visitor’s actual IP from the CF-Connecting-IP header. There’s a single-line code fix or several well-maintained plugins that handle it.
• Hard-coded origin IPs in firewall rules. Anywhere outside of Cloudflare that’s whitelisting traffic from the origin needs to be updated.
• WebSocket connections. Usually fine on Cloudflare’s free tier, but worth testing if the site uses real-time features.
• Caching of dynamic content. The default cache rules are sensible for most sites, but if anything custom is going on (logged-in user content, geo-personalized pages), the cache settings need a review.

All of these are solvable. None of them are reasons to skip the upgrade. They’re reasons to plan the upgrade rather than fire it blind on a Friday afternoon.

The realistic migration.

An afternoon, roughly in this order:

1. Make sure the origin has a valid TLS certificate. Install a Cloudflare Origin Certificate if it doesn’t.
2. Set Cloudflare’s SSL/TLS mode to Full (Strict).
3. Enable “Always Use HTTPS.”
4. Configure WordPress to read the real visitor IP from the CF-Connecting-IP header (filter or plugin).
5. Flip the relevant DNS records to Proxied (orange cloud). Start with non-critical subdomains if there are any; production root domain last.
6. Verify the site loads, forms submit, the admin works, and visitor IPs are being read correctly in logs.
7. Enable HTTP/3, Brotli, Tiered Cache, Bot Fight Mode.
8. Monitor for a week. Most issues surface within the first day or two.

For larger sites with edge cases, this is a more careful project, but the structure is the same: validate the prerequisites, flip the toggle, verify, then turn on the optional optimizations.

The takeaway.

Cloudflare’s entire value proposition lives at the edge. DNS-only mode is using one feature and ignoring the other 95 percent. Most WordPress sites that already have Cloudflare set up can flip the proxy toggle in an afternoon and immediately get the security, performance, and reliability benefits they thought they already had — without changing hosts, without buying additional tools, without writing custom code.

For sites where the origin is on a serious managed host already, the combination is meaningful: the host handles the WordPress operational layer, Cloudflare handles the edge. The two together is the architecture serious WordPress sites should default to.

One concrete example: a regional theater rescue engagement used Cloudflare’s edge-layer protection as part of the stabilization. The edge WAF and bot mitigation that come with the proxied configuration closed off the attack vectors the site had been getting compromised through, holding it exploit-free for 8 months while a full custom rebuild ran in parallel. See platform architecture built to last for what that looks like in practice.