Cloudflare

01Step by step: connecting a domain

1) Create a Cloudflare account with two-factor authentication and add your site (the root domain, for example example.com). Choose a plan; Free is fine to start. 2) Cloudflare scans your current DNS and imports the records it finds. Compare them carefully with your current zone, because the scan can miss records: check A, AAAA, CNAME, MX, every TXT (SPF, DKIM selectors, DMARC, verifications) and SRV. 3) Cloudflare gives you two nameservers. At your registrar, replace the existing nameservers with those two, and turn off DNSSEC at the registrar first if it is on (re-enable it through Cloudflare later). 4) Wait until the zone shows Active; usually minutes, up to 24 hours. 5) Prepare the origin certificate and SSL mode before enabling the proxy on important records (next sections). 6) Verify with dig and curl.

1# Nameservers switched?
2dig example.com NS +short
3# Proxied records return Cloudflare IPs, not your server's
4dig example.com A +short
5# Response passes through Cloudflare
6curl -sI https://example.com/ | grep -iE "server|cf-ray|cf-cache-status"

02Proxied (orange cloud) vs DNS only (grey cloud)

Each A, AAAA and CNAME record has a proxy status. Proxied means DNS answers with Cloudflare's IPs; visitors connect to Cloudflare, which then connects to your origin. You get caching, WAF, DDoS protection and a hidden origin IP. DNS only means Cloudflare just answers with your real IP, like any DNS host, and none of the protection applies. Proxy your website hostnames (example.com, www). Keep DNS only for things that are not HTTP or must reach the server directly: mail hosts used in MX records, SSH or database hostnames, and services on ports Cloudflare does not proxy. Remember that a single DNS-only record pointing at the same server reveals the origin IP, so do not create one for the web server's address unless you need it.

• Proxy: web traffic on standard HTTP(S) ports.
• DNS only: mail, SSH, FTP, game or custom TCP/UDP services.
• MX records cannot point at a proxied hostname.

03SSL/TLS modes: why Full (strict)

There are two connections: visitor to Cloudflare, and Cloudflare to your origin. The SSL/TLS encryption mode controls the second one. Off: no HTTPS at all. Flexible: HTTPS to the visitor, plain HTTP to your server; the padlock shows, but traffic to the origin is unencrypted, and an origin that redirects HTTP to HTTPS creates an endless loop. Full: HTTPS to the origin, but the certificate is not checked, so a self-signed or expired one passes and a man in the middle could too. Full (strict): HTTPS to the origin and the certificate must be valid and match the hostname, issued by a public CA or by Cloudflare's Origin CA. Always aim for Full (strict). Install either a Let's Encrypt certificate (certbot) or a free Cloudflare Origin Certificate on the server, then switch the mode. Cloudflare also offers an Automatic mode that picks the strongest mode your origin supports, but setting Full (strict) explicitly is clearer.

1# nginx on the origin with a Cloudflare Origin Certificate
2server {
3    listen 443 ssl;
4    http2 on;
5    server_name example.com www.example.com;
6    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
7    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;
8    root /var/www/example/public;
9}

04HTTPS everywhere, caching and performance

Under SSL/TLS > Edge Certificates turn on Always Use HTTPS, which redirects every http:// request at the edge, and set Minimum TLS Version to 1.2. Enable HSTS only after the whole site and every subdomain you include work on HTTPS, starting with a short max-age; once browsers cache it, they refuse plain HTTP. By default Cloudflare caches static files by extension (images, CSS, JS, fonts) and does not cache HTML. Cache Rules let you change that: cache public HTML for a short time, bypass anything with a session cookie, /admin, /api and /checkout, and set Edge and Browser TTLs. The cf-cache-status header shows HIT, MISS, BYPASS or DYNAMIC. Purge by URL after deploys, or better, use versioned asset filenames so purges are rarely needed. HTTP/3 and Brotli are on by default on current plans.

• Never cache pages that depend on cookies or login state.
• Use Development Mode or purge to test changes; do not disable caching globally.
• Avoid Rocket Loader and HTML minification tricks that can break JavaScript apps; test first.

05Security: WAF, rate limiting, DDoS, locking the origin

DDoS protection for network and HTTP floods is automatic on every plan for proxied traffic. The managed WAF ruleset (with broader rulesets on paid plans) blocks common attacks such as SQL injection patterns. Custom rules let you block or challenge by country, path, user agent or bot score; for example, a managed challenge on /wp-login.php or /admin from outside expected countries. Rate limiting rules cap requests per IP to sensitive endpoints such as login, OTP and password reset. Bot Fight Mode adds basic bot protection. The proxy only helps if attackers cannot reach the origin directly: firewall the server so ports 80 and 443 accept only Cloudflare's published IP ranges (or use Cloudflare Tunnel, which needs no open inbound ports), and keep SSH limited to keys and trusted IPs. Under Attack Mode is an emergency switch that challenges every visitor.

1# ufw: allow web traffic only from Cloudflare (ranges from cloudflare.com/ips)
2for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
3  sudo ufw allow proto tcp from "$ip" to any port 80,443
4done
5sudo ufw status numbered

06Real visitor IP on the origin

Behind the proxy, every request reaches your server from a Cloudflare IP. Logs, rate limiting, fail2ban and fraud checks then see Cloudflare instead of the visitor and can even ban Cloudflare itself. Cloudflare sends the original address in the CF-Connecting-IP header (and in X-Forwarded-For). Tell nginx to trust that header only when the request comes from Cloudflare ranges, using the realip module. Then $remote_addr becomes the visitor's IP everywhere. In Laravel or Node apps behind nginx, also configure trusted proxies so the framework reads the correct client IP and scheme. Never trust the header from arbitrary sources, or anyone can fake their IP.

1# /etc/nginx/conf.d/cloudflare-realip.conf (list all current ranges)
2set_real_ip_from 173.245.48.0/20;
3set_real_ip_from 103.21.244.0/22;
4set_real_ip_from 2400:cb00::/32;
5# ... remaining ranges from https://www.cloudflare.com/ips/
6real_ip_header CF-Connecting-IP;

07Troubleshooting 52x errors and redirect loops

When Cloudflare shows an error page, the problem is almost always between Cloudflare and your origin. 521 Web server is down: the origin refused the connection; nginx stopped, or a firewall blocks Cloudflare IPs. 522 Connection timed out: Cloudflare could not complete a TCP connection; server overloaded, wrong IP in DNS, or packets dropped by a firewall. 524: the connection worked but the app took longer than about 125 seconds (the default proxy timeout) to respond; move long work to queues. 525 SSL handshake failed: the origin does not speak TLS on 443 or has no certificate for that hostname (SNI). 526 Invalid SSL certificate: in Full (strict) the origin certificate is expired, self-signed or for another name. Too many redirects: usually Flexible mode plus an origin that redirects HTTP to HTTPS; switch to Full (strict). Check origin logs and test the origin directly.

1# Test the origin directly, bypassing Cloudflare
2curl -svI https://example.com/ --resolve example.com:443:203.0.113.10 2>&1 | grep -E "HTTP/|subject|expire|issuer"
3sudo systemctl status nginx
4sudo tail -n 50 /var/log/nginx/error.log

08What happens to a request inside Cloudflare

When a visitor connects to a proxied hostname, anycast routes them to the nearest Cloudflare data center, where TLS ends with the edge certificate. The request then passes a series of phases in a fixed order. Network and HTTP DDoS mitigation come first. Then security rules: IP access rules, WAF custom rules, rate limiting rules and the managed WAF rulesets, plus bot checks. Configuration rules, redirect rules and URL rewrites adjust the request. Workers, if attached to the route, run next and can answer or modify the request. Only then does the cache look up the cache key. On a miss, Origin Rules can change the host, port or SNI, and the request goes to your origin, possibly through a regional tier first. Knowing this order explains things like a WAF rule blocking a request that would have been a cache hit anyway.

• Security runs before cache, so blocked requests never consume cache or origin.
• Use Trace in the dashboard to see which rules matched a given URL.
• Workers run before the cache; use the Cache API inside a Worker to cache its output.

09Cache keys, tiered cache and origin cache headers

The cache key decides what counts as the same object. By default it includes the scheme, host, path and full query string, so ?utm_source=x creates a separate copy; a Cache Rule can ignore or sort query strings, or add a header or cookie to the key. Cloudflare respects origin Cache-Control by default for cacheable content: s-maxage and max-age set the edge lifetime, private and no-store prevent storage, and Set-Cookie on a response usually stops it being cached. Edge TTL in a Cache Rule can override origin headers, which is powerful and dangerous. Tiered Cache makes lower-tier data centers ask an upper tier instead of your origin, which raises hit ratio and protects a small VPS. Purge options include single URL, everything, and on some plans tag, prefix or hostname purges.

1# Let the origin control edge vs browser caching
2location /blog/ {
3    add_header Cache-Control "public, max-age=60, s-maxage=600, stale-while-revalidate=300";
4}
5location /account/ {
6    add_header Cache-Control "private, no-store";
7}
8# Check: curl -sI https://example.com/blog/ | grep -iE "cf-cache-status|age|cache-control"

10Locking the origin: Authenticated Origin Pulls and Tunnel

Firewalling to Cloudflare IP ranges stops random scanners, but any Cloudflare customer's traffic also comes from those ranges. Two stronger options exist. Authenticated Origin Pulls use mutual TLS: Cloudflare presents a client certificate when connecting to your origin, and nginx refuses any TLS connection without it. Zone-level pulls use a Cloudflare-issued certificate; per-hostname pulls let you upload your own, which is stricter because only your zone uses it. Cloudflare Tunnel goes further: a small daemon, cloudflared, runs on your server and opens outbound connections to Cloudflare, so the server needs no public inbound web ports at all. Tunnel also works for internal tools when combined with Cloudflare Access, which puts login in front of an app. The trade-off is one more agent to monitor and update.

1# nginx: accept only connections that present Cloudflare's client cert
2ssl_client_certificate /etc/ssl/cloudflare/authenticated_origin_pull_ca.pem;
3ssl_verify_client on;
4 
5# Or: no open ports, with Cloudflare Tunnel
6cloudflared tunnel login
7cloudflared tunnel create web-prod
8cloudflared tunnel route dns web-prod app.example.com
9cloudflared tunnel run web-prod

11Limits and edge cases to plan for

A few platform limits shape architecture. Request body size for uploads through the proxy is capped per plan (100 MB on Free and Pro), so large uploads should go directly to object storage with presigned URLs. The proxy read timeout produces a 524 when the origin is silent too long; current documentation gives a default of about two minutes, raisable only on Enterprise, so long reports and imports belong in background jobs with polling or webhooks. WebSockets are supported but long-lived connections can be reset during Cloudflare maintenance, so clients must reconnect. Only certain ports are proxied (for HTTPS, for example 443, 2053, 2083, 2087, 2096 and 8443). The free Universal certificate covers the apex and one level of subdomain, so deeper names like a.b.example.com need an advanced certificate. Check current plan limits before committing to a design.