How to put Cloudflare in front of your website
If your site runs on Nginx, Apache, IIS, GitHub Pages, Netlify, or another platform that doesn't expose server logs, you can fix that — and pick up DDoS protection, faster global delivery, and a free TLS certificate at the same time — by routing your traffic through Cloudflare. This guide walks through the whole thing, end to end, with the gotchas most tutorials skip.
Why bother? Cloudflare's free plan terminates HTTPS at the edge, blocks the obvious bad traffic for you, and — once you turn on a Cloudflare Worker — gives you per-request log access. That's what unblocks real-time log analysis with LogLens on stacks that would otherwise be a black box.
Before you start
You'll need three things:
- Access to your domain registrar (where you bought the domain — GoDaddy, Namecheap, Google Domains, OVH, etc.). You'll be changing the nameservers there.
- The current IP address or hostname your domain points to (the origin server). You can usually see this in your existing DNS provider or by running
dig +short yourdomain.comfrom a terminal. - About 15 minutes for the active work, plus up to 24 hours for nameserver propagation (most propagate in under an hour).
If you're on Shopify (standard plan), Wix, Squarespace, or any other fully-managed platform that controls your DNS, this guide doesn't apply — those platforms don't let you point your domain at Cloudflare. Get in touch and we'll talk through your options.
Create a Cloudflare account
Go to dash.cloudflare.com/sign-up and create a free account. You don't need to enter a card — the Free plan stays free.
Add your domain
From the dashboard, click Add a site, type your apex domain (e.g. example.com, not www.example.com), and pick the Free plan when prompted. Cloudflare will scan your existing DNS in the background — this usually takes 30–60 seconds.
Review the imported DNS records
Cloudflare will show you the records it found. Two things to check before you click continue:
- The orange cloud icon. A record with an orange cloud is proxied through Cloudflare — that's what you want for
@(the apex) andwww. Records with a grey cloud are DNS-only (Cloudflare resolves them but traffic doesn't pass through). Email records (MX, autodiscover, mail subdomains) should stay grey. - Anything missing. Cloudflare's import is good but not perfect. If you have unusual records (TXT records for SPF/DKIM/DMARC, custom subdomains pointing to other services), spot-check that they made it across. Add any that didn't.
Tip: If you have an MX record for receiving email, make sure it's grey-clouded. Cloudflare doesn't proxy SMTP traffic — leaving it orange will silently break inbound mail.
Change nameservers at your registrar
Cloudflare will give you two nameservers, something like kate.ns.cloudflare.com and walt.ns.cloudflare.com. The exact names are unique to your zone — copy them as shown.
Now log into your registrar and replace the existing nameservers with Cloudflare's. The exact path varies:
| Registrar | Where to change nameservers |
|---|---|
| GoDaddy | My Products → DNS → Nameservers → Change → "I'll use my own nameservers" |
| Namecheap | Domain List → Manage → Nameservers → Custom DNS |
| Google Domains / Squarespace Domains | DNS → Nameservers → Use custom name servers |
| OVH | Domains → your domain → DNS servers → Modify DNS servers |
| Gandi | Nameservers → External nameservers |
| 123-reg | Manage Domain → Nameservers → Change Nameservers |
| AWS Route 53 | Registered domains → your domain → Add or edit name servers |
Save the change. Most registrars apply the update within minutes; some take longer.
Don't delete your old DNS records. Once nameservers point at Cloudflare, the records you reviewed in step 3 are what serves traffic. Leave the old DNS provider alone for a week in case you need to roll back.
Wait for activation and verify
Cloudflare checks every few minutes; you'll get an email when activation completes. To verify it's actually proxying your traffic, open a terminal:
server: cloudflare
cf-ray: 8d2c4a1b8e0f1234-LHR
Two confirmations: server: cloudflare and a cf-ray header. If you see both, your traffic is going through Cloudflare. If you see your old origin's server header (e.g. nginx, Apache, Microsoft-IIS), nameserver propagation hasn't completed yet — wait and try again.
You can also re-run the LogLens compatibility checker on the homepage. Once Cloudflare is active, it'll detect Cloudflare and show you "Compatible — connect in minutes".
Get the SSL/TLS mode right
This is the one setting most setups get wrong. In Cloudflare, go to SSL/TLS → Overview and pick the right mode:
| Mode | When to use |
|---|---|
| Full (strict) | Recommended. Your origin already has a valid HTTPS certificate (Let's Encrypt, paid cert, etc.). Cloudflare verifies the cert end-to-end. Most secure. |
| Full | Your origin has HTTPS but with a self-signed or invalid cert. Encrypts the link to the origin but doesn't verify it. |
| Flexible | Avoid. Encrypts only browser-to-Cloudflare; origin runs plain HTTP. Looks secure to browsers but creates redirect loops on most modern sites and is fundamentally less safe. Don't pick this unless you have no other option. |
If your origin doesn't have HTTPS yet, the simplest fix is to enable Cloudflare's Origin Server certificate (SSL/TLS → Origin Server → Create Certificate) and install it on your origin. That gives you a free, 15-year cert specifically for the Cloudflare-to-origin link, which then lets you switch to Full (strict).
Common pitfalls
Worker is deployed but not seeing real traffic
If you've deployed the LogLens Worker but the dashboard only shows a handful of events — usually two or three from your own setup tests — the most likely cause is that traffic isn't going through Cloudflare at all. Workers only run on requests that hit Cloudflare's edge. If the relevant DNS records are grey-clouded (DNS-only), visitors resolve straight to your origin and skip Cloudflare entirely — and so does the Worker.
Confirm in 5 seconds from a terminal:
cf-ray: 8d2c4a1b8e0f1234-LHR
If you see a cf-ray header, traffic is being proxied through Cloudflare and the Worker should be running. If you see no cf-ray, proxying is off — even if your domain is on Cloudflare's nameservers.
Fix: Cloudflare dashboard → DNS → Records. Click the cloud icon next to your apex (@) and www A/AAAA records and flip them from grey to orange. Watch out for any caveats:
- Your origin must accept proxied requests — if it has IP allowlists, add Cloudflare's IP ranges.
- If your host (Kinsta, Shopify Plus, Squarespace, etc.) puts their own Cloudflare in front of you, they own the Cloudflare zone. The Worker has to be installed inside their Cloudflare account, not yours.
- Don't orange-cloud MX records, mail subdomains, or any record that handles SMTP / FTP / non-HTTP protocols.
Mixed-content errors after enabling Cloudflare
If your site loads http:// assets (images, scripts, stylesheets) hard-coded in templates, switching to HTTPS will break them. Two fixes: turn on SSL/TLS → Edge Certificates → Always Use HTTPS and Automatic HTTPS Rewrites. If that's not enough, fix the hard-coded URLs in your codebase or CMS.
Email stops working
Almost always because an MX record was orange-clouded. Go to DNS → Records and click the cloud icon next to MX records to grey them out. Same for SPF, DKIM, and DMARC TXT records — those are DNS-only.
Caching the wrong things
Cloudflare's default caching is conservative — it caches static assets but not HTML. If you have user-specific pages (logged-in views, cart pages) and you've enabled aggressive caching via Page Rules or "Cache Everything", you can serve User A's cart to User B. If you don't know what you're doing here, leave the defaults.
Hiding your origin IP
Cloudflare protects your origin from direct attacks only if attackers don't know the origin's real IP. Audit:
- Old DNS history (services like SecurityTrails will show historical records). Consider rotating to a new origin IP if your current one was public for years.
- Email headers — outbound mail from your origin can leak its IP. Use a separate mail server or a relay.
- Subdomains pointing directly at the origin (
direct.example.com,api-internal.example.com). Either proxy them or move them off the apex zone.
Real client IP at the origin
Your origin will see Cloudflare's IPs in REMOTE_ADDR, not your visitor's IP. The real client IP is in the CF-Connecting-IP header (and the standard X-Forwarded-For). Most web servers and frameworks have a "trusted proxies" setting — point it at Cloudflare's published IP ranges and read the right header. Skip this and your access logs will all show Cloudflare IPs.
Once you're live: connect to LogLens
With Cloudflare active, deploying LogLens takes about two minutes:
- Sign up for a LogLens account (free, no card).
- Add your domain. We'll provision an API key and give you a one-click Cloudflare Worker to install.
- The Worker captures every request at the edge and streams it to LogLens. You'll see live traffic on your dashboard within seconds — humans, bots, and AI crawlers, all classified.
If anything in this guide didn't go to plan, message us and we'll help you get unstuck.