Cloudflare is easy to set up and easy to misconfigure in ways that don't show symptoms until something's already gone wrong — an SSL loop, mail suddenly failing, or a "protected" site actually being more exposed than before. Most of that comes down to a handful of settings that get left on defaults when they shouldn't be. Here's the version of Cloudflare setup I actually walk clients through.

What Cloudflare is doing, structurally

Cloudflare sits between visitors and your origin server as a reverse proxy: DNS resolves to Cloudflare's IPs, Cloudflare terminates the connection, and (for proxied records) forwards the request to your actual server, caching what it can and filtering what it should along the way. That's where most of the value comes from — DDoS mitigation, caching, and a WAF layer in front of your origin — and it's also where the confusing failure modes come from, because "your site" now has two SSL contexts (visitor-to-Cloudflare, and Cloudflare-to-origin) that both need to be correct.

The SSL/TLS mode that causes the most tickets

Cloudflare's SSL/TLS setting has four modes, and picking the wrong one is the single most common source of "my site suddenly shows a redirect loop" tickets:

  • Off — no encryption between visitor and Cloudflare. Don't use this in 2026.
  • Flexible — encrypts visitor-to-Cloudflare, but Cloudflare-to-origin is plain HTTP. This is the mode that causes redirect loops on sites that force HTTPS at the origin, because the origin sees an HTTP request from Cloudflare and redirects it to HTTPS, which Cloudflare then re-requests as HTTP again, forever.
  • Full — encrypts both legs, but doesn't validate the origin's SSL certificate, so a self-signed or expired origin cert still "works" without warning you it's weak.
  • Full (strict) — encrypts both legs and validates the origin certificate against a trusted CA. This is the correct setting for any origin with a valid SSL certificate, which should be nearly every production site.

If a client's origin already has a valid certificate (Let's Encrypt, Plesk-issued, or otherwise), Full (strict) is almost always the right answer. Flexible should be treated as a temporary state, not a resting configuration.

DNS proxying: orange cloud vs. grey cloud

Every DNS record in Cloudflare can be "proxied" (orange cloud — traffic routes through Cloudflare) or "DNS only" (grey cloud — Cloudflare just resolves the name, traffic goes straight to your server). This matters more than it looks like:

  • Mail records (MX) should never be proxied. Cloudflare doesn't proxy SMTP traffic; MX records need to point at the real mail server IP, resolved directly.
  • Records used for server-to-server communication (an API endpoint another server calls directly, for instance) are frequently better left DNS-only, since proxying adds a routing hop and can interact unexpectedly with IP-based access rules on the origin.
  • Anything meant to benefit from Cloudflare's caching, WAF, and DDoS protection — the main website, typically — should be proxied.

The WAF and firewall rules worth turning on by default

Cloudflare's free and pro tiers both include a managed WAF ruleset that's worth enabling rather than leaving off "to be safe" — it's tuned to catch common attack patterns (SQL injection attempts, known bad bots) without much tuning required. Beyond that, a small set of firewall rules covers most of what a typical hosting client actually needs: rate limiting on login pages to blunt brute-force attempts, and country or ASN-based challenges if a site sees no legitimate traffic from certain regions.

Origin IP exposure — the mistake that undoes everything else

Enabling Cloudflare's proxy doesn't retroactively hide an origin IP that was already public before Cloudflare was added — old DNS records, previous hosting history, or a misconfigured subdomain still pointing directly at the origin can all leak the real server address. If the origin IP leaks, attackers can bypass Cloudflare's WAF and DDoS protection entirely by hitting the server directly. Firewall rules on the origin server itself, allowing traffic only from Cloudflare's published IP ranges, close that gap regardless of what leaks through DNS history.

A setup order that avoids downtime

  1. Add the domain to Cloudflare and verify all existing DNS records imported correctly — don't trust the automatic scan blindly, cross-check against the previous DNS provider.
  2. Set SSL/TLS mode based on the origin's actual certificate state — Full (strict) if a valid cert exists, otherwise get one issued before switching.
  3. Update nameservers at the registrar, and expect propagation delay before Cloudflare is actually in the traffic path.
  4. Once live, lock the origin firewall down to Cloudflare's IP ranges only.
  5. Enable the managed WAF ruleset and basic rate limiting on sensitive endpoints.

The underlying principle

Cloudflare is a strong layer of protection and performance, but it's a layer — it doesn't replace correct origin configuration, and it can create new, confusing failure modes if the SSL mode or proxy status doesn't match what the origin actually expects. Most "Cloudflare broke my site" incidents are really "the origin and Cloudflare disagreed about which protocol they were speaking," which is a completely avoidable class of problem once you know where to look.