A CDN is wonderfully uneventful when it is configured well: images arrive from a nearby edge, TLS works, the origin breathes easier, and nobody sees someone else’s cart. The dangerous version is a dashboard session where every promising switch gets enabled at once. Cloudflare is a reverse proxy, cache, security boundary, and transformation layer; each change deserves evidence.

Request flow and trust boundaries

  • Visitor resolves a proxied hostname to Cloudflare anycast addresses, not directly to the origin.

  • Visitor TLS terminates at Cloudflare’s edge; a separate connection carries the request from Cloudflare to the origin.

  • Cloudflare may answer from cache or forward to the origin according to eligibility, cache key, TTL, rules, cookies, and response headers.

  • The origin normally sees Cloudflare network addresses unless the application/web server restores the verified client address from Cloudflare headers.

  • CDN availability does not fix a slow database, expensive PHP, oversized images, render-blocking code, or third-party scripts on cache misses/dynamic pages.

Build a rollback-ready baseline

  • Export or record authoritative DNS, registrar nameservers, DNSSEC/DS state, TLS mode, edge certificates, origin certificate, rules and their order, cache configuration, WAF/security settings, redirects, transforms, Workers, and API integrations.

  • Record origin and proxied results for critical URLs: status, headers, TTFB, bytes, cache-control, cookies, HTML identity, forms, login, checkout, API, feeds, sitemaps, media, and errors.

  • Define the canonical host and HTTPS redirect ownership so CDN, origin, and WordPress do not create chains or loops.

  • Schedule a low-risk window and keep registrar, DNS, origin, SSH/console, and Cloudflare account recovery access available.

  • Use least-privilege API tokens and strong MFA; never share a global API key in plugins, scripts, tickets, or screenshots.

Audit DNS before proxying

  • Import tools can miss records; compare Cloudflare’s zone with the current authoritative zone and service inventory.

  • Proxy only supported A, AAAA, or CNAME records that serve compatible web traffic.

  • Keep MX, TXT, mail-related hosts, third-party verification endpoints, and unsupported/non-HTTP services DNS-only as required.

  • Preserve SPF, DKIM, DMARC, CAA, ACME challenges, SRV, verification, and subdomain records exactly.

  • Remove stale DNS-only records that reveal the origin; consider rotating an origin address that was historically public.

  • Plan DNSSEC carefully: disable/remove old DS at the correct time during nameserver migration, activate Cloudflare DNSSEC, then publish the new DS according to registrar guidance.

Confirm the hostname is actually proxied

External Linux shellbash
dig +short A www.example.com
dig +short AAAA www.example.com
curl -sS -I https://www.example.com/
104.16.x.x
2606:4700:...
HTTP/2 200
server: cloudflare
cf-ray: ...
cf-cache-status: DYNAMIC

Use several signals, not an IP guess

  • Proxied DNS commonly returns Cloudflare shared anycast addresses rather than the origin.

  • server: cloudflare, cf-ray, and related headers show the request traversed Cloudflare, subject to product/header behavior.

  • cf-cache-status: DYNAMIC can be correct for HTML or a bypass rule; proxying and caching are separate decisions.

  • Query multiple public resolvers and test IPv4/IPv6 because stale delegation and partial records can disagree.

  • Do not publish an actual origin address while troubleshooting; use controlled internal tests.

Use Full (strict) encryption to the origin

  • Install a valid, unexpired certificate on the origin whose SAN/CN matches the target hostname. A public CA or Cloudflare Origin CA can be appropriate depending on direct-origin requirements.

  • Allow HTTPS to the origin on the configured port and verify the full certificate chain.

  • In SSL/TLS → Overview, choose Full (strict) after origin validation.

  • Avoid Flexible mode for a site that can support HTTPS: it leaves the Cloudflare-to-origin leg unencrypted and commonly causes WordPress redirect loops.

  • A 526 error in Full (strict) usually indicates an origin certificate validation problem, not a browser-edge certificate problem.

Test the origin certificate privately

Authorized diagnostic host; replace the documentation addressbash
openssl s_client \
  -connect 192.0.2.10:443 \
  -servername www.example.com \
  -verify_hostname www.example.com \
  </dev/null
...
Verification: OK
Verify return code: 0 (ok)

SNI and hostname verification must match production routing

  • 192.0.2.10 is an IANA documentation address; use the private/controlled origin endpoint, never copy it literally.

  • SNI selects the intended origin virtual host and -verify_hostname checks certificate identity.

  • Also validate HTTP application content and Host routing, certificate chain, expiry monitoring, renewal, and IPv6/load-balanced origins.

  • A Cloudflare Origin CA certificate is trusted by Cloudflare, not ordinary browsers; direct public origin access should be blocked or use a publicly trusted certificate.

  • Keep origin diagnostics and addresses out of public logs and documentation.

Centralize HTTPS redirects

  • Enable Always Use HTTPS or an explicit redirect rule only after HTTPS works end to end.

  • Choose one canonical host and route every alternate in a single hop while preserving path and query string.

  • Avoid simultaneous CDN, origin, WordPress, and plugin redirects that form chains or loops.

  • Automatic HTTPS Rewrites can repair some eligible response references, but it cannot fix every JavaScript/CSS/third-party mixed-content URL and should not replace source cleanup.

  • Delay HSTS until certificates, renewal, every required subdomain, redirects, and rollback have been stable; a long max-age or includeSubDomains mistake can make hosts unreachable.

Understand Cloudflare’s default cache behavior

  • Proxying routes traffic through Cloudflare; it does not imply every response is cached.

  • Cloudflare normally caches eligible static file types according to its default behavior and configuration.

  • Origin Cache-Control, cookies, status, method, authorization, URL/query, rules, cache key, plan, and transformations affect results.

  • HTML is commonly dynamic unless APO or a cache rule makes it eligible.

  • Browser cache TTL and edge cache TTL solve different hops; an excessive browser TTL is difficult to revoke for visitors.

  • Custom cache keys can complicate single-file purges when required headers/cookies are absent from the purge request.

Inspect HIT, MISS, BYPASS, and DYNAMIC responses

External shell with an anonymous requestbash
curl -sS -o /dev/null -D - https://www.example.com/wp-content/uploads/logo.webp
curl -sS -o /dev/null -D - https://www.example.com/wp-content/uploads/logo.webp
HTTP/2 200
cache-control: public, max-age=31536000, immutable
cf-cache-status: MISS
age: 0
...
HTTP/2 200
cf-cache-status: HIT
age: 12

A second request can demonstrate reuse

  • A first MISS followed by HIT is a common sign the edge stored and reused an eligible response.

  • The Age header can indicate time in cache, but interpret all headers using current Cloudflare documentation.

  • Test the same POP is not guaranteed globally; cf-ray suffixes can help identify edge locations.

  • Query strings, cookies, request headers, cache rules, purge, revalidation, tiered cache, and origin headers can change outcomes.

  • Verify response bytes/content type and not merely cache status—cached wrong content is still wrong.

A safe WordPress caching model

  • Cache versioned static assets aggressively when filenames change with content.

  • Bypass wp-admin, login, previews, password-protected content, REST/API endpoints that are user-specific, carts, checkout, account pages, and sensitive query/action routes.

  • Bypass when authentication, cart, comment-author, password, membership, personalization, locale, or application cookies affect the response.

  • Never cache responses with personal data, CSRF nonces, session-specific markup, or Set-Cookie without a proven design.

  • Respect application purge/invalidation on publish, update, delete, menu/widget/theme changes, and scheduled content.

  • Test anonymous, logged-in, administrator, customer/cart, commenter, and incognito sessions for cross-user leakage.

Example cache-rule intent for private paths

cloudflare-cache-rule-expression.txttext
(http.request.uri.path starts_with "/wp-admin/") or
(http.request.uri.path eq "/wp-login.php") or
(http.request.uri.path starts_with "/cart/") or
(http.request.uri.path starts_with "/checkout/") or
(http.request.uri.path starts_with "/my-account/")

Make matching reflect the actual application

  • Configure matching requests as Bypass cache, then place/order rules according to Cloudflare’s current rules execution model.

  • Store paths can differ by language, plugin, permalink, or customization; inventory routes rather than copying the example.

  • Cookies and query parameters may create private state outside these paths.

  • Rules do not replace correct origin Cache-Control: private/no-store on sensitive responses.

  • Use Cloudflare Trace and real anonymous/authenticated tests to prove which rules execute.

APO versus hand-built HTML caching

  • Automatic Platform Optimization (APO) is Cloudflare’s WordPress-aware edge HTML caching product and requires the Cloudflare WordPress plugin according to current documentation.

  • The plugin coordinates invalidation and APO bypasses logged-in/administrator traffic under its documented behavior.

  • APO availability/cost depends on plan; current documentation states it is included on Pro+ and purchasable for Free, so verify live pricing.

  • Cloudflare documents that its APO plugin does not support WordPress multisite.

  • Start APO with other full-page cache plugins disabled, validate, then add layers only when tests prove compatibility.

  • A manual Cache Everything design transfers correctness, purge, cookie, personalization, commerce, preview, and security responsibility to your team.

Compression, HTTP versions, and transport

External shellbash
curl -sS -I --compressed https://www.example.com/assets/app.css
curl -sS -I --http2 https://www.example.com/
HTTP/2 200
content-type: text/css
content-encoding: br
...

Negotiate rather than assume

  • Cloudflare currently supports visitor delivery using Gzip, Brotli, or Zstandard depending on request, plan, rules, content type, status, and size.

  • --compressed advertises supported encodings and asks curl to decode; inspect headers to see what the edge selected.

  • HTTP/2 or HTTP/3 can improve connection behavior but cannot compensate for oversized media or long JavaScript tasks.

  • Transformations may decompress/recompress content and remove Content-Length; Cache-Control: no-transform affects transformations when exact encoding/length matters.

  • Test browsers and field data, not a single curl negotiation.

Treat JavaScript optimizations as experiments

  • Rocket Loader defers JavaScript to improve early rendering, but it changes script timing/markup and can break dependencies.

  • Test navigation, forms, consent, analytics, ads, comments, search, menus, galleries, checkout, login, accessibility, and CSP before enabling broadly.

  • Use documented per-script or configuration exclusions only after diagnosing the incompatible script.

  • Minification can conflict with origin build pipelines, source maps, CSP hashes, licenses, or already-minified code; enable one asset class at a time if available.

  • Early Hints/preload can help critical resources but waste bandwidth or create duplicate work when hints are inaccurate.

  • Measure LCP, INP, CLS, errors, conversion, and real-user results; dashboard “optimization” labels are not proof.

Images: fix the source before buying transformations

  • Resize uploads to displayed dimensions, compress appropriately, choose modern formats with fallbacks as required, and include intrinsic width/height.

  • Use responsive srcset/sizes, meaningful lazy loading, and do not lazy-load the likely LCP image blindly.

  • Cloudflare image optimization products and availability vary by plan; verify current pricing, limits, formats, cache behavior, and URL billing.

  • A CDN shortens delivery distance but does not make a 6 MB hero image sensible.

  • Validate image quality, color/metadata policy, animated assets, cache invalidation, canonical asset URLs, and origin egress.

Protect the origin after proxying

  • Allow web traffic from Cloudflare’s published IP ranges or use stronger authenticated origin mechanisms where appropriate, while preserving management/monitoring access.

  • Update allowlists automatically from authoritative Cloudflare ranges with review and rollback; stale rules can cause outages.

  • Use Authenticated Origin Pulls/mTLS when the threat model and plan/architecture support it.

  • Rotate a previously exposed origin IP if feasible and remove DNS/history/service records that reveal the replacement.

  • Prevent direct origin access from serving the site for arbitrary Host headers.

  • Restore visitor IPs only from Cloudflare-controlled source connections and trusted headers; otherwise attackers can spoof them.

Security controls need staged tuning

  • Start managed WAF/bot/rate-limit rules in log/simulate mode where supported, observe legitimate traffic, then enforce.

  • Protect login, password reset, XML-RPC if enabled, APIs, search, and expensive endpoints without blocking accessibility tools, partners, monitoring, payment webhooks, or administrators.

  • Use precise skip rules and service authentication instead of broad IP bypasses.

  • Review false positives, challenge solve rates, origin load, attack logs, and business conversion.

  • Cloudflare is one layer; keep WordPress/core/plugins/themes patched, remove unused code, enforce MFA/least privilege, back up, monitor, and harden origin/services.

Cache invalidation and deployment design

  • Use content-hashed filenames for immutable CSS/JavaScript/images so releases do not depend on global purges.

  • Purge only affected URLs/tags/prefixes when the plan and cache-key design support reliable targeting.

  • Purge Everything is a blunt incident tool that can spike origin load and erase useful cache.

  • Document cache keys, cookies, query behavior, device/language variation, Workers, and transformations.

  • Coordinate application cache, reverse proxy, object cache, CDN cache, browser cache, and service workers during deploy and rollback.

Measure before and after each change

  • Use identical URLs, content, device/network profiles, geographic test points, warm/cold cache state, and authenticated/anonymous state.

  • Track origin TTFB, edge TTFB, cache-hit ratio, bytes, requests, LCP, INP, CLS, JavaScript long tasks, errors, availability, origin CPU/database load, and conversion.

  • Lab tests diagnose repeatably; field/RUM data shows real populations and requires enough time/traffic.

  • Segment cached versus dynamic templates and countries; averages can hide a broken checkout or distant region.

  • Change one feature/rule group at a time and annotate dashboards so cause and effect remain visible.

Troubleshooting by symptom

  • DNS resolves origin: record is DNS-only, unsupported, pending activation, or queried through stale delegation/cache.

  • 521/522/523: investigate origin availability, route/DNS, firewall/allowlists, connection refusal, and Cloudflare reachability.

  • 525/526: debug origin TLS handshake or Full (strict) certificate validity/hostname/chain.

  • Redirect loop: Flexible mode, proxy scheme detection, or competing edge/origin/WordPress redirects usually disagree.

  • Always DYNAMIC/MISS: check eligibility, method/status, cookies, Set-Cookie, cache-control, rule match/order, query/cache key, purge, and Cloudflare Trace.

  • Someone sees stale/private content: bypass immediately, purge affected keys/host, preserve evidence, assess exposure, notify/respond under policy, and fix cache variation/invalidation.

  • JavaScript breaks: disable Rocket Loader/minification/transforms one at a time, inspect CSP and console/network errors, then scope exclusions.

  • Origin logs show Cloudflare IPs: configure the supported real-IP module with trusted Cloudflare ranges; never trust client-supplied forwarding headers globally.

A safe rollout sequence

  1. Inventory/export DNS and every Cloudflare/origin setting; capture baseline and rollback.

  2. Move authoritative DNS carefully and validate all mail/service/verification records.

  3. Proxy only intended web records and test canonical host, paths, IPv4/IPv6, and origin routing.

  4. Install/validate origin TLS, enable Full (strict), then centralize HTTPS redirects.

  5. Confirm static cache behavior and origin cache headers before customizing rules.

  6. Add WordPress private-path/cookie bypasses; prove isolation with multiple session types.

  7. Evaluate APO or deliberate HTML caching separately with purge and incident tests.

  8. Enable compression/protocol/image/script optimizations one by one against metrics and application tests.

  9. Protect the origin and restore verified visitor IPs without locking out operations.

  10. Tune WAF/rate limiting, establish monitoring, document changes, and review regularly.

Primary references