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 Salience on stacks that would otherwise be a black box. The zone is free at any traffic level; the Worker has its own allowance, covered at the end of this guide.
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.com from 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.
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) and www. 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 the previous step 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:
curl -sI https://yourdomain.com | grep -i 'server\|cf-ray'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 Salience compatibility checker on the homepage. Once Cloudflare is active, it'll detect Cloudflare and show you that you're compatible and can 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 Salience 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:
curl -sI https://yourdomain.com | grep -i 'cf-ray'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 published IP ranges (cloudflare.com/ips).
- 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 Salience
With Cloudflare active, deploying Salience takes about two minutes:
- 01Sign up for a Salience account (free, no card).
- 02Add your domain. We'll provision an API key and give you a one-click Cloudflare Worker to install.
- 03The Worker captures every request at the edge and streams it to Salience. The connection confirms within seconds, and within about fifteen minutes your dashboard fills with 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.
Set Fail open and know your Workers allowance
Three things to check once the Worker is deployed. They take a minute and they are the difference between a Worker that can only ever stop logging and one that could return errors to your visitors.
1. Every route must be set to Fail open
Fail open means that if the Worker cannot run, because the daily allowance is used up or it errors, Cloudflare serves your site directly, so your site can never go down because of this Worker. Fail closed would return errors instead.
Where: Cloudflare dashboard → Workers & Pages → the Salience Worker → Settings → Domains & Routes. Edit each route the Worker is on and set Failure mode to Fail open. Check every route, not just the first one.
2. The Workers Free plan allows 100,000 requests a day
Cloudflare's Workers Free plan allows 100,000 Worker requests a day across the whole account, resetting at 00:00 UTC. The Worker runs once for every request to the routed hostnames, including images, scripts and bot traffic, so a busy site can use the allowance in a few hours. When it runs out, Cloudflare stops running the Worker until midnight and Salience stops receiving logs for the rest of the day. With Fail open set, the site itself stays up.
3. Workers Paid removes the daily cap for $5 a month
Workers Paid, $5 a month, includes 10 million requests and removes the daily cap. If your site sees more than 100,000 requests a day, including bots, it is the plan to be on for complete logs. Cloudflare bills it in USD.
Cloudflare's pricing page
The current allowances and prices for Workers Free and Workers Paid are on Cloudflare's developer site.