Turning on the Cloudflare proxy (the orange cloud) puts a second caching and SSL layer in front of a host that usually already has one. When both layers try to terminate SSL, cache HTML, and rewrite headers, you get redirect loops, white-screen admin fatals, and a site that only loads with the proxy switched back to DNS Only.
Why does turning on the Cloudflare proxy break a WordPress site?
Because the proxy is not a DNS setting. It is a full reverse proxy that terminates TLS, caches responses, rewrites headers, and changes the IP address your origin server sees. Your host's stack was configured assuming it sat directly in front of visitors. Add a second edge and the two start contradicting each other.
The failure looks dramatic and the cause is almost always boring. A client called me on a Saturday because the homepage loaded fine but /wp-admin returned a blank white page on a GoDaddy Managed WordPress plan. He had flipped the orange cloud on Friday afternoon to "get free CDN." Nothing in WordPress had changed. The host's gateway cache was now receiving requests from Cloudflare IPs, its logged-in-user bypass rule stopped firing correctly, and the admin was being served cached, half-built pages.
Flip to DNS Only, site works. Flip to Proxied, site breaks. That loop burns a weekend, and it is the moment most owners find out their host and their CDN do not talk to each other, and neither will own the ticket.
According to Cloudflare's own Q3 2025 DDoS and threat reporting, the network blocked an average of 227 billion cyber threats per day during that quarter. The service is doing real work. The problem is stacking it on top of a host that is already doing a version of the same work.
What conflicts between Cloudflare and your host
Five things, in roughly the order they cause support tickets.
SSL termination happens twice. Cloudflare offers Flexible, Full, and Full (Strict). Flexible encrypts visitor-to-Cloudflare but sends plain HTTP to your origin. If your host force-redirects HTTP to HTTPS (every managed host does), Cloudflare asks for HTTP, the host says "go to HTTPS," Cloudflare asks again, and the browser gives up with ERR_TOO_MANY_REDIRECTS. This one accounts for more broken WordPress sites than every other item on this list combined.
Two HTML caches with different rules. Your host's gateway cache knows to bypass cached pages for logged-in users, WooCommerce cart cookies, and /wp-admin. Cloudflare, by default, does not cache HTML, but the moment someone enables APO, a "Cache Everything" page rule, or a bundled optimization toggle, you have two caches making independent decisions. Cart totals go stale. The logged-out version of a page gets served to an admin. If you have been chasing performance problems through layers like this before, the pattern in 7 bottlenecks that keep WordPress slow after caching will feel familiar.
The origin sees the wrong IP. Without Cloudflare's restore-visitor-IP module or the CF-Connecting-IP header handled correctly, every request arrives from a Cloudflare IP. Security plugins see thousands of requests from one address and start rate-limiting or banning legitimate traffic, including you.
Rocket Loader and auto-minify break page builders. Elementor, Bricks, and most checkout flows load JavaScript in a specific order. Rocket Loader reorders it. The result is a page that renders but where nothing clicks.
Host-level firewalls block the proxy. Some hosts allowlist specific edge IPs. Cloudflare's IP ranges change. When they do, your origin starts refusing traffic that was fine yesterday.
Which hosts conflict with Cloudflare proxy, and how badly
Here is the practical breakdown of what happens when you put the orange cloud in front of common WordPress hosting setups.
| Host setup | What it already runs | What breaks with proxy on | Workable? |
|---|---|---|---|
| GoDaddy Managed WordPress | Built-in gateway cache and CDN | Admin fatals, white screens, stale pages, cache purge stops working | Supported but fragile |
| WP Engine | EverCache plus its own global edge | Double caching, IP restore issues, plan-level CDN already included | Redundant |
| Kinsta | Cloudflare integration already built in | Running your own account on top causes SSL and cache conflicts | Do not stack |
| SiteGround | SiteGround Optimizer plus SG CDN | Conflicting minification, stale HTML | Pick one |
| Basic shared cPanel host | Apache plus maybe LiteSpeed cache | Mostly fine; SSL mode is the only real risk | Good fit |
| Unmanaged VPS | Whatever you installed | Fine, because you control both ends | Good fit |
The pattern is clear. Cloudflare's proxy is excellent in front of hosting that is deliberately thin, and a liability in front of hosting that already includes an edge layer, which describes most managed WordPress plans sold today.
Kinsta is the clearest case to call out. They ship a Cloudflare integration as part of the plan. Adding your own Cloudflare account in front of theirs means two Cloudflare zones fighting over the same hostname. I have seen that produce SSL handshake errors that take a full day to untangle because both vendors insist the configuration is correct on their side.
How to fix a WordPress site that only loads in DNS Only mode
Work through this in order. Most sites are back inside 20 minutes.
- Set SSL/TLS encryption mode to Full (Strict). In Cloudflare, go to SSL/TLS, Overview. If it says Flexible, that is your redirect loop. Full (Strict) requires a valid certificate on your origin, which every managed host provides. Change it, hard-refresh, test.
- Turn off Automatic HTTPS Rewrites and "Always Use HTTPS" temporarily. Get the site loading first, then re-enable one at a time.
- Confirm your WordPress site URL is HTTPS. Settings, General. If it still says
http://, Cloudflare plus the host redirect will loop regardless of SSL mode. - Disable Rocket Loader and auto-minify. Speed, Optimization. These are the two settings that break page builders.
- Remove any Cache Everything page rule. If you did not deliberately configure HTML caching with proper bypass cookies, you do not want it on.
- Install Cloudflare's official WordPress plugin or enable the host's real-IP module. This restores visitor IPs so your firewall and analytics stop seeing one address.
- Exclude
/wp-admin/*and/wp-login.phpfrom caching and from Rocket Loader. Non-negotiable on any site where someone logs in. - Clear both caches. Cloudflare's purge everything, then your host's cache. In that order.
If the site still only loads with the proxy off, the problem sits on the origin rather than at Cloudflare. Check whether your host's firewall is rejecting Cloudflare IP ranges, and check for a fatal PHP error that only triggers when $_SERVER['HTTPS'] is not set the way your theme expects. The triage order in check DNS before you assume your WordPress site was hacked applies here too: rule out the boring configuration causes before you start suspecting anything worse.
What two vendors cost you when the site goes down
This is where it stops being a technical problem and starts being a business one.
When Cloudflare sits in front of a host that runs its own edge, every incident becomes a jurisdiction dispute. Cloudflare support tells you the request left their network with a 200 response, which is true. Your host tells you they are serving the page correctly to the origin IP, which is also true. Both are right. The breakage lives in the handoff, and nobody owns the handoff.
Price that out. A $200/hour freelance developer spending three hours on a redirect loop is $600. If you run WooCommerce, add lost orders: we covered the range in what website downtime costs a business, where the per-minute figures for small and midsize sites land between $137 and $427. Three hours at the low end of that is roughly $24,000 in theoretical exposure for a store doing real volume, and even a conservative haircut on that number dwarfs what you saved on hosting.
For agencies the arithmetic is uglier because it repeats. If you manage 20 client sites and four of them have a Cloudflare-plus-host conflict surface, that is four potential Saturday incidents a year, each one eating two to four billable hours you will never invoice. A lot of agency owners discover this during an audit and realize their recurring care plan margins were funding unpaid vendor mediation.
According to the W3Techs survey of web technologies, Cloudflare is used by roughly 21% of all websites as a reverse proxy service (2025). It is everywhere. That ubiquity is exactly why so many WordPress owners turn it on without checking what their host already provides.
When you should keep Cloudflare proxied anyway
There are three cases where the orange cloud earns its keep even with a managed host behind it, and I will not pretend otherwise.
You need WAF rules your host does not offer. Cloudflare's managed rulesets, bot management, and rate limiting are strong, and some compliance requirements name them specifically.
You are under active DDoS attack. Nothing your host sells at the shared or managed tier absorbs volumetric traffic the way Cloudflare's network does.
You run multiple origins behind one hostname. Load balancing, Workers, or a headless front end in front of a WordPress backend all need a programmable edge.
In every one of those cases, the fix is to make the host layer thin on purpose rather than to pull Cloudflare out: disable the host's own CDN and HTML cache, set Full (Strict), and document which layer owns which job. One cache, one SSL termination point, one place to purge.
What you should not do is run both edges fully enabled and hope. That configuration works until a plugin update, a cert renewal, or an IP range change breaks it, and then you are back to Saturday.
How a single coherent layer removes the finger pointing
The reason we built TopSyde's stack the way we did is that two edges means two support queues. Our caching, SSL, and WAF sit in one place, tuned for WordPress specifically, with /wp-admin and WooCommerce cart cookies excluded by default rather than by a page rule someone has to remember to write. You can see exactly what sits where on our hosting spec sheet, and the full stack breakdown is on our technology page.
When something breaks at 9pm, there is no "open a ticket with your CDN provider" step. Our support target is a response in under 2 hours during business hours, and monitoring runs 24/7 with TopSyde Sentinel watching for malware and anomalies rather than waiting for you to notice. If you want Cloudflare in front of us for WAF or Workers, we will configure the origin correctly for it and tell you which of our layers to turn off. That conversation takes 10 minutes when one vendor owns the whole path.
Plans start at $89/mo per site. Migration is handled on our side, including the DNS and SSL cutover, which is the part people get wrong when they move themselves. If you have ever lost a weekend to a host that would not own a problem, what happens when a web host shuts down is a useful reminder that vendor accountability is a feature you are paying for.
Every plan comes with a 30-day money-back guarantee. Compare plans and pricing, or send us the site and we will tell you which layer is breaking before you commit to anything.
Frequently asked questions
Does Cloudflare's orange cloud slow down WordPress?
Proxied mode adds a small amount of latency on cache misses because requests take an extra hop, but the edge cache usually more than compensates for static assets. The slowdown people report is almost always double caching or Rocket Loader reordering scripts rather than the proxy itself. Fix the configuration before you blame the hop.
Should I use Cloudflare with managed WordPress hosting?
Only if your managed host does not already run its own edge cache and CDN, or if you need a specific Cloudflare feature like advanced WAF rules, bot management, or Workers. If your host includes a CDN in the plan, running Cloudflare proxied on top of it gives you two caches, two SSL terminations, and two support teams who will each blame the other.
Why does my site work in DNS Only but break when proxied?
Nine times out of ten it is the SSL encryption mode. Flexible SSL sends plain HTTP to an origin that force-redirects to HTTPS, which produces an infinite redirect loop. Switch to Full (Strict) in Cloudflare's SSL/TLS settings and confirm your WordPress site URL starts with https://.
Can Cloudflare break my WordPress admin dashboard?
Yes. The two usual causes are HTML caching that does not bypass logged-in sessions and Rocket Loader reordering admin JavaScript. Exclude /wp-admin/* and /wp-login.php from caching entirely, turn Rocket Loader off, then clear both the Cloudflare and host caches before testing again.
Is it safe to turn the proxy off while I troubleshoot?
Yes, and it is the fastest way to isolate the problem. DNS Only mode exposes your origin IP and removes Cloudflare's protection, so treat it as a temporary diagnostic step rather than a permanent state. DNS changes propagate within minutes on most registrars, so you can toggle back once you have identified the conflicting setting.
Topics
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
