How to Set Up Cloudflare With Shared Hosting

Cloudflare sits between your visitors and your server. Requests hit their network first, get answered from a nearby cache when possible, and only reach your host when they have to.

On shared hosting that is worth more than it is on a big server, because the traffic Cloudflare absorbs is traffic that never touches the resource limits you are paying for. A site serving most of its images and CSS from Cloudflare uses a fraction of the entry processes and I/O it otherwise would.

It is free, it takes about half an hour, and it goes wrong in exactly two ways. Both are below, with the fix.

What you get on the free plan

Worth being precise about, because the marketing blurs it:

• A global CDN for static files — images, CSS, JavaScript. Cached near the visitor.
• DNS hosting, which is faster and easier to manage than most hosts' own DNS.
• A free SSL certificate between the visitor and Cloudflare.
• DDoS mitigation, genuinely good, genuinely free.
• A firewall you can write rules for.
• Brotli compression, HTTP/3, and automatic HTTPS rewriting.

What you do not get free: caching of HTML pages by default (static assets only, unless you write a rule), image resizing, or a guaranteed SLA.

That first one matters. Out of the box Cloudflare does not cache your pages — it caches your assets. That is still a large win, but if you expected your WordPress homepage to be served from the edge, it is not, until you tell it to.

Before you start

Two things to have ready:

1. Access to your domain registrar, because you are changing nameservers there. If we registered your domain, that is the client area.
2. A working SSL certificate on your hosting, from AutoSSL or Let's Encrypt. You need this for the correct SSL mode later; if the site is not already on https, fix that first — a free certificate comes with every one of our hosting plans.

Also write down your server's IP address. You will want it if anything needs checking later, and once Cloudflare is proxying, a DNS lookup will no longer show it.

Step 1 — Add the site and check the records

Sign up, add your domain, and let Cloudflare scan your existing DNS. It imports most records automatically. Then check them against your host's DNS before continuing, because anything it missed will simply stop working when you switch.

The ones most commonly missed:

• MX records — your email. If these are wrong, mail stops. This is the single most damaging mistake in the whole process.
• TXT records for SPF, DKIM and DMARC. Missing these does not break mail immediately, it just quietly moves it to spam.
• Records for subdomains that live somewhere else entirely.

The orange cloud beside each record is the important control:

Mail records must be grey. Cloudflare proxies http and https, not SMTP or IMAP, so an orange cloud on a mail host breaks email.

Step 2 — Change the nameservers

Cloudflare gives you two nameservers. Set them at your registrar, replacing whatever is there.

Propagation is usually minutes and occasionally a day. During that window some visitors get the old answer and some the new, which is fine as long as both point at a working site — so do not change anything on the server until it has finished.

Step 3 — Set the SSL mode. This is mistake number one.

SSL/TLS → Overview, and there are four options. Choosing wrong here is the cause of most Cloudflare problems, including the infamous redirect loop.

Flexible is the trap. It shows a padlock to the visitor while the connection from Cloudflare to your server is plain http — so the site looks secure and is not, and anyone between Cloudflare and your host can read the traffic. It also causes the redirect loop: your server sees an http request, redirects to https, Cloudflare sends it again as http, forever. If you have ever seen ERR_TOO_MANY_REDIRECTS after adding Cloudflare, this was why.

Use Full (strict). It requires a valid certificate on your server, which you already have from AutoSSL, and it is the only mode that is encrypted end to end.

Then, on the same screens:

• Always Use HTTPS — on.
• Automatic HTTPS Rewrites — on. It fixes hard-coded http asset URLs in your pages, which is a common cause of mixed-content warnings on older WordPress sites.
• Minimum TLS Version — 1.2.

Step 4 — Caching

Caching → Configuration:

• Caching Level: Standard.
• Browser Cache TTL: a few hours at least; longer if your assets are versioned.

Then two rules. In the modern dashboard these live under Rules → Cache Rules — the old Page Rules still work but are being retired.

Rule 1 — never cache the admin. For WordPress:

URI Path starts with "/wp-admin" OR URI Path starts with "/wp-login"
→ Bypass cache

Do this first. Caching an admin session serves one logged-in user's page to another.

Rule 2 — cache your uploads hard. Images do not change:

URI Path starts with "/wp-content/uploads"
→ Cache eligible, Edge TTL 1 month

If you run WooCommerce, add /cart, /checkout and /my-account to rule 1. Serving a cached cart is the kind of bug that takes a week to notice and a long time to explain.

Do not enable "Cache Everything" site-wide on a WordPress site unless you have set up cookie-aware bypass rules for logged-in users. It is a real optimisation and it is also how people accidentally serve a logged-in header to every visitor on the internet.

Step 5 — Security, lightly

The defaults are sensible. Three things worth turning on:

• Bot Fight Mode — on. It absorbs a surprising amount of junk traffic before it reaches your plan's process limits.
• Security Level — Medium. High challenges real people.
• A rate-limiting rule on your login page. /wp-login.php is the most-attacked URL on the internet, and this stops brute-force attempts at the edge rather than on the machine you are sharing with other people.

Skip "Under Attack" mode unless you are actually under attack. It puts an interstitial in front of every visitor, and search crawlers do not wait for it.

The second mistake: your server stops seeing real visitor IPs

Once Cloudflare proxies your traffic, every request arrives at your server from a Cloudflare IP address. Your server has no idea who the visitor was.

The consequences turn up one at a time, over weeks:

• Analytics shows all traffic from a handful of IPs.
• Security plugins ban Cloudflare's IPs — which locks out everyone.
• Comment spam filters stop working.
• Rate limits and geo rules behave nonsensically.

The real IP is in the CF-Connecting-IP header; the fix is to make your server read it. On cPanel this is usually mod_cloudflare or an equivalent — ask your host, most have it available. For WordPress specifically, the official Cloudflare plugin handles it, and most security plugins have a "site is behind Cloudflare" setting that must be switched on.

Do this at setup, not after your security plugin has banned Cloudflare and taken the site down.

What Cloudflare does not fix

Worth being clear, because it gets blamed and credited for things it does not do:

• A slow origin is still slow. Cloudflare caches assets; an uncached HTML page is still generated by your server at whatever speed it manages. If your TTFB is bad, fix the site and the host first.
• It does not replace backups.
• It does not fix a hacked site. It will happily serve malware from the edge, faster than before.
• It is not a substitute for the right server location. For a Bangladeshi audience, ours run in Dhaka on BDIX-connected servers, which is the difference between 30 ms and 300 ms for a Bangladeshi visitor — the origin's location still decides every request Cloudflare has to pass through.

A ten-minute verification

After the nameservers have propagated:

# Is Cloudflare actually in front?
curl -sI https://yoursite.com/ | grep -i "server\|cf-cache-status"

# Are assets being cached? Run twice — the second should say HIT.
curl -sI https://yoursite.com/wp-content/uploads/example.jpg | grep -i cf-cache-status

Then, by hand: load the site logged out, log into the admin and confirm it behaves normally, send yourself an email from the site's contact form, and check that a post you publish appears immediately rather than after a cache expiry.

The email test is the one people skip, and mail is what the DNS import most often gets wrong.

Frequently asked questions

Is Cloudflare's free plan enough for a small site? Yes. The free tier includes the CDN, DNS, SSL, DDoS protection and firewall rules. Paid plans add image optimisation, more page rules and an SLA — none of which a typical business site or blog needs.

Will Cloudflare speed up my site? For static assets and for distant visitors, substantially. For the initial HTML of an uncached page, not by itself — that is still your server. Treat it as a layer on top of hosting-level caching, not a replacement for it.

Why did my site break after enabling Cloudflare? Almost always the SSL mode. Set it to Full (strict) and confirm your server has a valid certificate. The second most common cause is a missing DNS record, usually MX, which breaks email rather than the site.

Does Cloudflare hide my server's IP address? For proxied records, yes, and that is a genuine security benefit. But an unproxied subdomain — a mail record, an old ftp entry, a staging site — will expose it. Check every grey-cloud record.

Should I use Cloudflare's DNS if I do not want the CDN? You can. Set every record to grey cloud and you get fast, free, easy DNS with none of the proxying. It is a reasonable setup, and you can switch individual records to orange later.

Does Cloudflare work with cPanel hosting? Yes, and it is the most common combination there is. Keep using AutoSSL on the server for the origin certificate — Full (strict) requires it.