Overview

Cloudflare's dashboard has roughly four hundred switches. About nine of them matter for a small site, and two of them are the reason your site is showing a redirect loop. This is the short list, plus the mistakes I keep seeing in support threads.

Start with the DNS records

Add your domain, then recreate your existing DNS records. For a typical setup that's an A record for the root pointing at your server IP and a CNAME for www pointing at the root.

The orange cloud next to a record toggles proxying. Proxied means traffic goes through Cloudflare — you get caching, DDoS protection, and your origin IP is hidden. DNS-only (grey cloud) means Cloudflare just answers the DNS query and the client connects straight to your server.

A few records should almost always stay grey:

  • Mail records (MX, and any A record used for mail). Proxying mail breaks it.
  • Any subdomain you need to SSH into by hostname.
  • Anything serving a protocol Cloudflare doesn't proxy, like a game server or a raw TCP service.

SSL mode: get this right or nothing else matters

This is the one that generates the most confused forum posts. Cloudflare's SSL/TLS mode controls how Cloudflare talks to your server, not how visitors talk to Cloudflare.

ModeWhat it doesWhen to use it
OffNo encryption anywhereNever, at this point
FlexibleHTTPS to the visitor, plain HTTP to your serverOnly if your origin has no certificate at all
FullHTTPS both ways, certificate not validatedTemporary, while fixing a cert
Full (strict)HTTPS both ways, certificate must be validWhat you actually want

Flexible is the trap. Your server sees an HTTP request, so if your app or web server redirects HTTP to HTTPS — which it probably does — you get an infinite loop, because Cloudflare keeps re-requesting over HTTP and your server keeps redirecting. If you're seeing ERR_TOO_MANY_REDIRECTS, this is why nine times out of ten.

The fix is not to disable the redirect. The fix is to get a certificate on your origin — Let's Encrypt via Caddy or Certbot, or a Cloudflare Origin Certificate that's valid for fifteen years and installs in thirty seconds — then set Full (strict).

Origin certificates are issued under SSL/TLS → Origin Server → Create Certificate. They're only trusted between Cloudflare and your server, which is exactly the scope you need.

Always Use HTTPS and HSTS

Under SSL/TLS → Edge Certificates:

  • Always Use HTTPS — on. This redirects at the edge, which is free and fast.
  • Automatic HTTPS Rewrites — on. Catches mixed-content links in your own HTML.
  • HSTS — on, once you're sure every subdomain works over HTTPS. Start with a low max-age. HSTS is a one-way door: browsers remember it, and backing out takes months.
  • Minimum TLS version — 1.2. Nothing legitimate needs 1.0 anymore.

Caching, without breaking things

Default caching behavior is reasonable: Cloudflare caches static file extensions (.css, .js, .jpg, .woff2) and skips HTML. That default is correct for most sites, and the most common mistake is overriding it to cache everything.

If you do want HTML cached at the edge, do it deliberately with a Page Rule or Cache Rule for specific paths, not globally. Otherwise you'll publish a new post and stare at the old one for an hour.

Two things that save a lot of confusion:

  • Cloudflare serves cached content from its edge without hitting your server. Your access logs will look suspiciously empty. That's expected.
  • Purge the cache after deploys. Caching → Configuration → Purge Everything is fine for a small site; use the API if you deploy often.

Set a Browser Cache TTL too. For static assets with fingerprinted filenames, a year is right. For anything else, keep it short — the browser cache is the one you can't purge.

Security settings worth flipping

SettingValueWhy
Bot Fight ModeOnCheap protection against scrapers, minimal false positives
Security LevelMediumHigh will challenge real visitors during traffic spikes
Browser Integrity CheckOnBlocks requests with obviously bogus headers
Email Address ObfuscationOnStops naive scrapers from harvesting your contact page

Skip the WAF unless you have a specific problem. It's a paid feature, and for a small site the managed rules mostly generate alerts you'll learn to ignore.

Rate limiting is worth the money only if you've actually been hammered. If you have a login page or a search endpoint that hits your database, it's cheap insurance. Otherwise, wait until you need it.

Getting real visitor IPs back in your logs

Once you're proxied, every request in your access log comes from a Cloudflare IP. That breaks fail2ban, geo lookups, and any analytics you built yourself.

For Nginx, the module-based approach is slow at scale. The faster route is ngx_http_realip_module, which ships with most distro builds:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... the full list from cloudflare.com/ips
real_ip_header CF-Connecting-IP;

The current list is always at cloudflare.com/ips, and it does change. Fetch it in a script rather than pasting it once and forgetting.

Things people get wrong

  • Leaving DNS records that expose the origin. If direct.example.com points at your server and isn't proxied, the whole point of hiding the IP is gone. Audit your records.
  • Assuming the free plan is a full cdn. It caches static assets and absorbs attacks. It won't do image resizing, fancy edge logic, or per-request transformations.
  • Turning on Rocket Loader. It's under Speed → Optimization, and it breaks inline scripts in ways that are miserable to debug. Skip it.
  • Forgetting that Cloudflare terminates TLS. Your origin sees HTTP unless you've configured Full (strict) correctly. Test with curl -I https://yourdomain and check what your server logs show.

Is it worth it for a small site?

Yes, mainly for three reasons: free certificates that renew themselves, DDoS absorption you don't have to think about, and DNS that's faster than your registrar's. The performance benefit for a low-traffic site is honestly marginal — if your site is slow, it's almost certainly your origin, not the edge.