Cloudflare in Front of a Shared Host: What It Fixes and What It Doesn't

Someone — a forum, a developer, a hosting upsell page — has probably told you to "put Cloudflare in front of it" as the answer to your site's speed or security problems. The advice is half right, which makes it dangerous: the half it fixes, it fixes for free, and the half it does not gets covered up for a while and then blamed on something else.

This site runs exactly this setup — Cloudflare in front of ordinary shared hosting — so this guide is written from the plumbing, not the marketing page. If your underlying problem is a slow origin server, start with the triage order in our slow-website guide and come back; Cloudflare is step four of that order, not step one.

What "in front of" actually means

When you onboard a domain to Cloudflare, you change your nameservers at the registrar so Cloudflare answers DNS for your domain. From then on the chain looks like this:

Visitor → nearest Cloudflare edge node → (only if needed) your shared host

Cloudflare answers what it can — cached pages, images, TLS, blocked attacks — and forwards the rest to your origin server. Your host's real IP stops being public, which is where most of the security benefit comes from: attackers cannot easily target a server they cannot find.

What it genuinely fixes on the free plan

As of 2026, Cloudflare's plan comparison puts all of this in the $0 tier:

The honest counterpoint, in the same breath: Cloudflare labels Free as for projects "that aren't business-critical," and support is community forums only. For a brochure site that is fine; if downtime costs you money, Pro (typically $20/month billed annually as of 2026) is mostly buying ticket support plus extras, not a different network.

What it cannot fix

This is the oversold half:

1. A slow origin stays slow for anything uncached. Every dynamic request — wp-admin, a cart, a logged-in page, a cache miss — travels all the way to the same overloaded shared server. Our rule of thumb: if your time-to-first-byte is consistently over ~800 ms, that is the host or the CMS, and no edge network changes it. A CDN hides a slow origin for cacheable traffic; it does not repair one.
2. A hacked site stays hacked. Cloudflare filters traffic; it does not clean malware, patch an end-of-life plugin, or remove a backdoor already on the server. If the CMS itself is the problem, see the end-of-life PHP guide before spending time on the edge.
3. Hosting outages are still outages for anything not fully cached. The edge cannot serve a page it does not have.
4. It adds a dependency and a control panel. DNS now lives at Cloudflare; a misconfigured rule can take the site down, and "free" also means you are on the cheapest tier of a company whose incentive is upgrading you.

The one setting that matters most

Cloudflare's encryption mode controls both connections — visitor-to-edge and edge-to-origin — and the default choice on old tutorials is the dangerous one. Per the SSL/TLS modes documentation, the modes as of 2026 are:

• Flexible: visitor-to-Cloudflare is encrypted, but Cloudflare-to-origin is plain HTTP. Common when the origin has no TLS — and the classic source of redirect loops when the origin does redirect to HTTPS. Also: your visitors' traffic crosses the internet unencrypted on the second hop.
• Full: edge-to-origin uses HTTPS when the visitor used HTTPS, without validating the origin certificate — fine with a self-signed or host-issued cert on shared hosting.
• Full (strict): like Full, but validates the origin certificate — the strongest option, and easy when your host issues free Let's Encrypt certificates.
• Automatic (rolling out as the default): Cloudflare probes your origin monthly and picks the most secure mode it supports, upgrading gradually and rolling back on failure.

Set Full (strict) if your host gives you a real certificate, Full if it does not, and treat Flexible as a temporary bridge you plan to leave. A redirect loop after onboarding is almost always a Flexible-mode artifact — ask the host for a cert and move up a mode.

Cache behavior: the two settings that matter

The defaults are already sane for a small site — Cloudflare caches static file types (images, CSS, JS) automatically. Two deliberate choices remain:

1. HTML caching. By default Cloudflare does not cache HTML. If your site is fully static, a cache rule that caches HTML turns every page into an edge serve — this is where the "under-200 ms responses worldwide" stories come from. Do not do this on a CMS with logged-in users or personalized pages unless you enjoy debugging stale dashboards.
2. Purging on deploy. Cached content outlives your updates unless you purge. This site's deploy pipeline calls Cloudflare's API to purge everything after each push, and pairs it with deliberately short origin cache TTLs (images a week, HTML an hour) because the filenames are not fingerprinted — a stale edge copy is the most common "I updated the page but nothing changed" mystery.

A detail worth knowing for logs and form handling: behind Cloudflare, your server sees edge IPs, not visitor IPs — the real visitor arrives in the CF-Connecting-IP header, which is why this site's form endpoint reads that header first.

Setup, in the order that avoids surprises

1. Confirm your origin has TLS first. Free Let's Encrypt on most shared panels; needed for Full mode.
2. Sign up and add the domain at dash.cloudflare.com — it scans existing DNS records automatically.
3. Verify the DNS records it found against your registrar/host before switching anything — mail records (MX, SPF) are the ones that get missed.
4. Change nameservers at the registrar, then wait — this is the 2-24 hour part.
5. Set SSL mode to Full (strict) or Full — not Flexible.
6. Enable what you actually need: Web Analytics, Turnstile for forms, a cache rule if the site is static.
7. Test: homepage, one deep page, the contact form, and yoursite.com/some-old-page.html if you migrated URLs.

When it is not worth it

Skip the exercise if your host already provides comparable anycast DNS and free TLS and your site is a pure CMS doing personalized pages — you would be adding a proxy layer for features you already have. And if your real problem is that the site is old, slow, and unloved, Cloudflare is a coat of paint: decide whether it needs the refresh-or-rebuild treatment first. Otherwise, for the typical brochure site on $10 hosting, the free plan is close to a free lunch — the case study shows what the full version of this stack looks like in production.

— Editorial team. Facts current as of 2026; we revise guides when the ground shifts.