Cloudflare: DNS, SSL, Caching, WAF & Tunnels

Cloudflare sits in front of a domain as a reverse proxy, CDN, DNS resolver, and edge firewall at the same time. Instead of visitors connecting directly to your origin server, they connect to the nearest Cloudflare data center, which terminates TLS, checks the request against firewall and WAF rules, serves cached assets when possible, and only reaches back to your origin when it actually has to.

This guide covers the parts of Cloudflare that matter for running a real site or home-lab service in front of it: DNS record management and the proxied vs. DNS-only toggle, the four SSL/TLS encryption modes and which ones are actually safe, caching and cache invalidation, the WAF and rate limiting, and Cloudflare Tunnel — a way to expose an internal service to the internet with zero open inbound ports on your firewall or router.

Who this is for

• Anyone putting a domain in front of Cloudflare for the first time.
• Sysadmins who need to stop a brute-force or scraping attack without touching the origin.
• Home-lab and self-hosting users who want to expose a service without port-forwarding.

You should have the following before working through this guide:

What a reverse proxy / CDN actually does

A normal DNS record points a hostname straight at your server's IP — anyone who resolves the name can connect to that IP directly. A reverse proxy CDN like Cloudflare changes that: your DNS record points at Cloudflare instead, Cloudflare terminates the connection, and it decides — per request — whether to answer from cache, apply security rules, or forward the request on to your real origin. Your origin IP becomes an implementation detail the proxy hides, not something visitors talk to directly.

Anycast networking

Cloudflare announces the same IP address ranges from every data center in its network simultaneously, using anycast BGP routing. A visitor in Mumbai and a visitor in Frankfurt both resolve the same Cloudflare IP, but internet routing sends each of them to whichever announcing data center is topologically closest. This is what makes Cloudflare fast globally (short round trips to the edge) and resilient (a data center going dark just drops out of the anycast announcement, and traffic reroutes to the next-closest PoP with no visible failover).

Where Cloudflare sits

The request path below shows a proxied request from browser to origin and back, including the WAF, rate limiting, and cache decision points at the edge:

"Installing" Cloudflare means onboarding your domain so its DNS is served (and optionally proxied) by Cloudflare. There are two supported paths depending on whether you can change nameservers at your registrar.

1. Dashboard → Add a Site → enter your domain (e.g. example.com)
2. Choose a plan (Free is fine to start)
3. Cloudflare scans existing DNS records and imports them automatically
4. Review the imported records — fix anything the scan missed or got wrong
5. Cloudflare gives you two nameservers, e.g.:
     ada.ns.cloudflare.com
     rex.ns.cloudflare.com
6. Log in to your domain registrar and replace the existing nameservers
   with the two Cloudflare ones
7. Wait for propagation (usually minutes, can take up to 24h) — Cloudflare
   emails you once the zone is active

DNS record types

Proxied (orange cloud) vs. DNS-only (grey cloud)

Every A/AAAA/CNAME record has a proxy toggle in the dashboard. Proxied (orange cloud) routes traffic through Cloudflare's edge — you get caching, WAF, DDoS protection, and your origin IP is hidden. DNS-only(grey cloud) just answers the DNS query with the real IP; the visitor connects straight to your server with none of Cloudflare's protections. Records that need a direct connection — SSH, a mail server, or anything not speaking HTTP/HTTPS — must stay DNS-only, since Cloudflare's proxy only understands HTTP(S) and a handful of other protocols on paid plans.

SSL/TLS encryption modes

This is the single most misconfigured setting in Cloudflare. It controls how the Cloudflare → origin leg of the connection is encrypted — it has no effect on the visitor → Cloudflare leg, which is always HTTPS once Universal SSL is active.

Origin CA certificates

For Full Strict mode, Cloudflare can issue a free Origin Certificate that's trusted by Cloudflare's edge (though not by regular browsers directly hitting the origin) and valid for up to 15 years:

# Dashboard → SSL/TLS → Origin Server → Create Certificate
# generates a cert + private key pair; save them on the origin as:
sudo mkdir -p /etc/ssl/cloudflare
sudo nano /etc/ssl/cloudflare/cert.pem   # paste the Origin Certificate
sudo nano /etc/ssl/cloudflare/key.pem    # paste the private key
sudo chmod 600 /etc/ssl/cloudflare/key.pem

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/cloudflare/cert.pem;
    ssl_certificate_key /etc/ssl/cloudflare/key.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $http_cf_connecting_ip;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Caching

Cloudflare caches based on file extension by default (images, CSS, JS) at the Standard cache level. Browser Cache TTLcontrols how long the visitor's own browser is told to keep a cached copy, separate from how long Cloudflare's edge keeps it. For anything not cached by default — API responses, HTML pages — use Cache Rules (the modern replacement for legacy Page Rules) to opt specific paths into caching:

Rule name: Cache static assets aggressively
When incoming requests match:
  URI Path contains "/static/" OR URI Path ending in .js, .css, .woff2, .jpg, .png
Then:
  Cache eligibility: Eligible for cache
  Edge TTL: 30 days
  Browser TTL: 4 hours

After a deploy, stale cached assets are cleared from Caching → Configuration → Purge Cache — either purge everything, or purge by exact URL to avoid a full cold-cache stampede on the origin.

cloudflared — the Cloudflare CLI / tunnel daemon

# Install (Debian/Ubuntu)
curl -L https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

# Authenticate this machine to your Cloudflare account
cloudflared tunnel login

# Create a named tunnel (generates a credentials JSON file)
cloudflared tunnel create home-lab

# List tunnels and their IDs
cloudflared tunnel list

# Route a hostname to the tunnel (creates the DNS CNAME automatically)
cloudflared tunnel route dns home-lab app.example.com

# Run the tunnel in the foreground (test) or as a system service
cloudflared tunnel run home-lab
sudo cloudflared service install
sudo systemctl enable --now cloudflared

Cloudflare API via curl

Almost everything in the dashboard has an API equivalent, authenticated with a scoped API token (Profile → API Tokens) rather than the old global API key:

export CF_TOKEN="your-scoped-api-token"
export ZONE_ID="your-zone-id"

# List zones on the account
curl -s -X GET "https://api.cloudflare.com/client/v4/zones" \
  -H "Authorization: Bearer $CF_TOKEN" | jq

# Create a proxied A record
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"app","content":"203.0.113.10","proxied":true,"ttl":1}'

# Purge the entire cache for a zone
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

# Purge specific URLs only (avoids a full cold-cache stampede)
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/static/app.js"]}'

# Set the SSL/TLS mode to Full (strict)
curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ssl" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"strict"}'

Exposing an internal service (e.g. a home-lab dashboard on 192.168.1.50:8080) to the internet through Cloudflare Tunnel, with no inbound firewall or router rules at all:

tunnel: homelab-dashboard
credentials-file: /home/deploy/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: dash.example.com
    service: http://192.168.1.50:8080
  - hostname: git.example.com
    service: http://192.168.1.51:3000
  - service: http_status:404

Scenario: a marketing blog post goes viral and, within the same hour, login-endpoint traffic spikes abnormally — a mix of legitimate readers and a credential-stuffing bot run trying to exploit the sudden attention.

• Run SSL/TLS in Full (Strict) with a Cloudflare Origin Certificate — never Flexible or Off in production.
• Enable "Always Use HTTPS" and HSTS once every subdomain genuinely supports HTTPS, so nothing accidentally falls back to plaintext.
• Use Cache Rules for static assets and purge by specific URL after deploys instead of purging everything, to avoid a cold-cache stampede on the origin.
• Automate DNS and cache-purge operations with scoped API tokens instead of the account-wide global API key.
• Prefer Cloudflare Tunnel over exposed origin IPs and port-forwarding wherever the workload allows it — it removes an entire class of direct-to-origin attacks.

• Full (Strict) SSL only — anything less leaves the Cloudflare-to-origin leg unencrypted or unverified.
• WAF managed rules — keep the Cloudflare Managed Ruleset and OWASP Core Ruleset enabled; they cover the common injection, XSS, and protocol-abuse patterns without custom rule authoring.
• Bot Fight Mode — free-tier bot mitigation that challenges known bad bot signatures before they reach the origin.
• Hide the origin IP — proxy every record that serves web traffic, avoid leaking the real IP in old DNS history/subdomains, and restrict the origin firewall to Cloudflare's published IP ranges only.
• Firewall rules for admin paths — a custom rule like (http.request.uri.path contains "/wp-admin" and not ip.src in {office IP range}) blocks admin panel access from anywhere but trusted networks.

Putting Cloudflare in front of a site means treating the edge as a real part of your infrastructure, not just a DNS host. Get the fundamentals right — proxied records where they belong, Full (Strict) SSL with an Origin Certificate, sensible caching with a real purge workflow, and WAF/rate limiting rules scoped to what actually needs protecting — and you get a CDN, a firewall, and a DDoS shield for free, plus Cloudflare Tunnel as a way to expose internal services without ever opening an inbound port. Most production incidents trace back to one of a small number of causes: the wrong SSL mode, a stale cache, or a WAF rule that was never scoped narrowly enough — all of which are covered in the Troubleshooting section above.

• Official Cloudflare documentation — developers.cloudflare.com
• Cloudflare engineering blog — blog.cloudflare.com
• Cloudflare community forums — community.cloudflare.com
• cloudflared source and releases — github.com/cloudflare/cloudflared
• Cloudflare Radar (global internet traffic and attack trends) — radar.cloudflare.com
• Cloudflare API reference — api.cloudflare.com