Cloud & Infrastructure / Networking & DNS / Security

Configure Cloudflare DNS, proxying, TLS, caching, and origin protection

Migrate a production zone safely, enforce Full (strict), protect the origin with mTLS and network controls, cache only proven public content, stage WAF and rate limiting by plan, enable DNSSEC, and rehearse recovery.

300 min16 stepsChanges system stateRevision 1

Save or explore

#cloudflare #dns #dnssec #tls #cdn #cache #waf #rate-limiting #origin-protection #aop

0 of 16 steps completed

Goal

Operate Cloudflare as a trustworthy DNS and HTTP security boundary without breaking non-web services, weakening origin TLS, exposing the origin, leaking personalized content through cache, or assuming unavailable plan features.

Supported environments

Cloudflare DNS primary zone Current 2026 product
Cloudflare SSL/TLS Full (strict)
Cloudflare Cache Rules and WAF Plan-dependent current features
HTTPS origin TLS 1.2 or newer

Prerequisites

Registrar control MFA-protected access can change and restore authoritative nameservers and coordinate DS records.dig NS {{zoneName}} +short; dig DS {{zoneName}} +short
Complete DNS inventory All records, TTLs, owners, protocols, DNSSEC state, wildcards, and child delegations are exported and independently reviewed.
Origin recovery Console or private access, origin logs, firewall rollback, capacity, and a certificate trusted by the intended recovery client exist.
Application cache map Owners classify every public, dynamic, authenticated, personalized, mutation, API, webhook, cart, checkout, and administrative path.
Plan entitlement review Current Cloudflare plan and contract limits for Cache Rules, WAF, rate limiting, logs, analytics, Trace, and advanced settings are recorded.
Scoped secrets Zone IDs and least-privilege API tokens are supplied through protected systems; Global API Key and command-line token literals are prohibited.
Change window DNS, application, origin, mail, security, and registrar owners monitor a staged window with stop conditions and prior delegation available.

Operating boundary

OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.

Full guide

What you will build

System

A Cloudflare primary DNS zone with an independently checked record inventory, staged delegation, proxied web hostnames, DNS-only mail and validation records, and a validated DNSSEC chain of trust.
End-to-end HTTPS using Full (strict), a hostname-valid origin certificate, explicit Origin CA limitations, Authenticated Origin Pulls or an equivalent account-specific origin-authentication control, Cloudflare-only network ingress, and a tested emergency origin path.
A safe ruleset that bypasses authenticated and personalized traffic, caches only reviewed public assets, supports precise purging, introduces WAF and rate limiting according to plan availability, and exposes enough headers, Ray IDs, events, logs, synthetic checks, and recovery evidence to operate the service.

Observable outcome

Public DNS validates from authoritative and recursive resolvers, web records return Cloudflare anycast addresses, non-web services remain DNS only, and DNSSEC proves a correct parent-to-zone chain.
Clients receive a valid edge certificate, Cloudflare validates the origin under Full (strict), direct origin requests are denied, AOP guarantees are documented accurately, and a Cloudflare or certificate incident has a rehearsed recovery path.
Public immutable assets demonstrate MISS then HIT, account and API paths never become shared cache entries, WAF and rate limiting are observable and reversible, and post-cutover monitoring distinguishes edge, rule, network, TLS, cache, and origin failures.

Architecture

How the parts fit together

The registrar delegates the zone to Cloudflare authoritative nameservers. DNSSEC extends trust from a DS record at the parent to Cloudflare's DNSKEY and signed answers. A, AAAA, and CNAME records serving HTTP are proxied, so visitors resolve Cloudflare anycast addresses and traverse the edge TLS, DDoS, WAF, Rules, and Cache layers. Mail, ownership validation, and non-HTTP services remain DNS only. Cloudflare terminates the visitor TLS connection, then opens a separate HTTPS connection to the origin. Full (strict) requires an unexpired hostname-matching certificate issued by a public CA or Cloudflare Origin CA. Origin CA is trusted by Cloudflare, not ordinary browsers, so pausing or gray-clouding such a hostname breaks direct trust. AOP adds client-certificate authentication; the global certificate proves Cloudflare network origin but is shared across accounts, so stronger deployments use zone/per-hostname AOP where supported or combine it with Cloudflare IP allowlisting, strict SNI and Host routing, private connectivity, and application authentication. Cache bypass rules precede narrow public-asset eligibility. Security rules begin in observable modes, with plan-dependent features verified before design.

Registrar and parent zonePublish Cloudflare nameserver delegation and the DNSSEC DS record. A wrong DS can make an otherwise correct zone fail for validating resolvers.

Cloudflare authoritative DNSServes imported and reviewed records, signs answers when DNSSEC is active, and controls whether eligible address records are proxied or DNS only.

Cloudflare edgeTerminates visitor TLS, evaluates security and cache rules, emits Ray IDs and response headers, serves cache hits, and establishes a separate origin connection.

Origin TLS endpointPresents a hostname-valid certificate for Full (strict), validates AOP client identity where configured, accepts approved Cloudflare network paths, and serves health and application traffic.

Cache and Rules engineBypasses sensitive requests first, makes selected public assets eligible, respects or deliberately overrides origin directives, and defines purge semantics.

WAF and rate limitingEvaluate proxied HTTP requests with plan-dependent rules, fields, counts, periods, actions, and event visibility. They complement rather than replace origin security.

Monitoring and recoveryCorrelate DNS, DNSSEC, certificates, Ray IDs, cache status, rules, security events, origin logs, synthetic checks, API audit, and rehearsed rollback.

Inventory DNS, certificates, origin paths, application behavior, authenticated routes, cache directives, traffic rates, Cloudflare plan entitlements, and recovery access before creating a zone.
Create least-privilege API tokens, add the zone, reproduce records, keep web records DNS only initially, and verify authoritative answers without changing registrar delegation.
Prepare origin TLS and Full (strict), then stage AOP and network restrictions through a canary that preserves console and health access.
Change registrar nameservers only after Cloudflare answers the complete inventory, wait for the zone to become Active, and proxy one low-risk hostname before the primary service.
Introduce bypass-first Cache Rules, validate MISS/HIT and cross-user isolation, then add conservative WAF and rate limiting supported by the contracted plan.
Enable DNSSEC with correct registrar DS coordination and verify validating answers before treating the cutover as complete.
Monitor edge and origin signals, preserve a publicly trusted or otherwise viable emergency path, rehearse rollback, and review plan features and certificate expiry every 90 days.

Assumptions

The domain owner controls both registrar delegation and the Cloudflare zone, and can restore prior nameservers during their cached lifetime if the initial cutover fails.
The guide uses Cloudflare primary (full) zone setup. Partial CNAME, secondary DNS, subdomain, and multi-signer topologies have different plan and DNSSEC requirements and require their own design.
The origin is an HTTPS-capable reverse proxy or load balancer with console or provider-native recovery access that does not depend on public DNS.
Mail, SSH, FTP, database, validation, and other non-HTTP services use distinct DNS-only names and firewall policy; they are not sent through the ordinary HTTP reverse proxy.
The Cloudflare plan and contract are reviewed before creating WAF, rate-limiting, custom cache-key, log, account-level, timeout, or advanced features. The guide does not imply identical fields, limits, rules, or retention on every plan.
A publicly trusted certificate is preferred when operators require safe direct-browser emergency access. An Origin CA certificate is acceptable only when the hostname remains behind Cloudflare or another trust path is explicitly prepared.
Application owners identify authenticated, personalized, administrative, mutation, preview, checkout, API, webhook, and sensitive paths before any caching rule is enabled.
OneLiners displays this procedure and never executes Cloudflare API calls, DNS changes, certificate operations, firewall rules, or origin commands. The operator runs reviewed actions in their own authorized environment.

Key concepts

Proxied record: An eligible A, AAAA, or CNAME whose HTTP/S traffic resolves to Cloudflare anycast addresses and traverses Cloudflare products. Proxied records use an automatic DNS TTL, currently 300 seconds.
DNS-only record: A record for which Cloudflare serves the configured DNS answer but does not proxy traffic. It exposes the target address for A/AAAA and receives no HTTP-layer Cloudflare protection.
Full (strict): The recommended origin encryption mode that encrypts both legs and validates origin certificate validity, issuer, and hostname. Failure commonly appears as Cloudflare error 526.
Origin CA certificate: A certificate trusted by Cloudflare for origin connections and compatible with Full (strict), but not normally trusted by browsers. Cloudflare currently does not send Origin CA expiration notifications.
Authenticated Origin Pulls: mTLS on Cloudflare-to-origin connections. Global AOP proves the client came from Cloudflare's network but uses a shared certificate; zone or per-hostname certificates can provide stricter identity.
Cache eligibility: A Cache Rule decision that makes a matching request bypass cache or eligible for caching. Eligibility does not guarantee a HIT because method, status, headers, cookies, and other behavior still matter.
Edge TTL: How long Cloudflare may consider an edge cache entry fresh. It differs from authoritative DNS TTL and from Browser TTL retained by user agents.
Ray ID: Cloudflare's request identifier exposed to clients and logs. Together with UTC time and hostname it helps correlate an edge request with security events and origin logs.
DNSSEC chain of trust: The parent DS record identifies the zone KSK, which validates DNSKEY and signed record sets. A stale or mismatched DS can cause SERVFAIL for validating resolvers.
Cloudflare Trace: A beta simulation tool available on all plans for understanding which Rules configurations would apply. It is not historical evidence; actual incidents require events, logs, analytics, and origin correlation.

Before you copy

Values used in this guide

{{zoneName}}

Apex domain being delegated and protected.

Example: example.com

{{zoneId}}

Cloudflare zone identifier used by scoped API requests.

Example: 023e105f4ecef8ad9ca31a8372d0c353

{{apiToken}}secret

Short-lived or protected Cloudflare API token scoped to this zone and only the permissions required by the current stage. Supply through a secret manager, never the command line.

Example: stored-in-secret-manager

{{originHost}}

Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.

Example: www.example.com

{{originIp}}

Origin address retained in protected inventory and never published through a DNS-only web record.

Example: 203.0.113.20

{{cloudflareNameserver}}

One assigned Cloudflare authoritative nameserver.

Example: ada.ns.cloudflare.com

{{staticPath}}

Immutable public asset used for cache MISS/HIT tests.

Example: /assets/app.9f82c1.js

{{privatePath}}

Authenticated or personalized path that must always bypass shared cache.

Example: /account/profile

{{healthPath}}

Non-sensitive origin health path with strict access and no shared user data.

Example: /healthz

{{purgeUrl}}

Public URL used to test precise cache purge behavior.

Example: https://www.example.com/assets/app.9f82c1.js

{{originCertPath}}

Protected filesystem path to the origin certificate chain.

Example: /etc/nginx/certs/origin-fullchain.pem

{{originKeyPath}}secret

Protected filesystem path to the origin private key.

Example: /etc/nginx/private/origin-key.pem

{{originTrustBundlePath}}

CA bundle used by direct origin checks: the ordinary system trust bundle for a publicly trusted certificate, or the official Cloudflare Origin CA root bundle for an Origin CA certificate.

Example: /etc/ssl/certs/cloudflare-origin-ca-root.pem

{{aopCaPath}}

Origin trust path containing the exact official Cloudflare or account-specific AOP client CA certificate.

Example: /etc/nginx/certs/cloudflare-aop-ca.pem

{{previousNameserverOne}}

First prior authoritative nameserver retained for cutover rollback.

Example: ns1.previous-dns.example

{{previousNameserverTwo}}

Second prior authoritative nameserver retained for cutover rollback.

Example: ns2.previous-dns.example

Security and production boundaries

Use scoped API tokens, not the Global API Key. Separate DNS, zone settings, cache purge, and security-rule automation when different operators own them; revoke bootstrap tokens after cutover.
Full (strict) authenticates the origin certificate but does not by itself stop direct requests to a known origin IP. Enforce AOP or equivalent account-specific origin identity plus network restrictions and strict SNI/Host routing.
The global AOP certificate is shared across Cloudflare accounts. It proves Cloudflare network origin, not your zone. Document this boundary and use zone/per-hostname AOP or additional origin controls when tenant identity matters.
Origin CA private keys and account-specific AOP private keys are secrets. Generate and transfer them through protected systems, restrict permissions, rotate on suspected exposure, and never place them in repository, shell history, screenshots, or tickets.
Cache only data proven public and cross-user safe. A cache leak can expose another user's content even when application authentication is correct at the origin.
Cloudflare WAF and rate limiting reduce edge abuse but do not authorize application actions, secure an exposed origin, validate business identity, or replace origin logging and resource limits.
Restrict origin ingress from official Cloudflare IP ranges through an automated reviewed update process, or use private connectivity where available. Preserve separate console and monitoring recovery access.
DNSSEC protects authenticity, not confidentiality or availability. A wrong DS is an outage; coordinate registrar and nameserver changes, honor TTLs, and verify from validating resolvers.

Stop before continuing if

Stop if the DNS inventory omits mail, DNSSEC, CAA, validation, SRV, DKIM, SPF, DMARC, wildcard, or delegated-subdomain records.
Stop if the zone is Pending, registrar ownership is unavailable, prior nameservers cannot be restored, or existing DNSSEC cannot be migrated safely.
Stop if origin TLS fails SNI, SAN, issuer, validity, chain, or health checks; never compensate by choosing Flexible mode.
Stop if direct origin access remains possible outside approved Cloudflare, recovery, and monitoring paths.
Stop if AOP mode and origin trust do not match, or the team describes global AOP as account-exclusive.
Stop if authenticated, personalized, administrative, mutation, preview, API, webhook, cart, checkout, or secret-bearing responses can enter shared cache.
Stop if WAF or rate-limiting features, limits, fields, actions, logs, or retention are assumed without checking the current plan and contract.
Stop DNSSEC changes after any SERVFAIL or DS mismatch and restore a valid chain before continuing.
Stop if monitoring cannot correlate hostname, UTC timestamp, Ray ID, cache status, security event, origin log, and deployment.
Stop if rollback would simply gray-cloud an Origin CA hostname, expose the origin broadly, or remove the DS record without respecting cached DNSSEC state.

decision

Inventory DNS, origin, application, plan, and recovery

read-only

Export every DNS record and TTL, map each hostname to protocol and owner, inventory certificates and origin listeners, identify sensitive paths and cache directives, record traffic baselines, and verify current Cloudflare plan entitlements before changing delegation.

Why this step matters

Cloudflare's automatic scan is a convenience, not a complete migration source. DNS records control mail, certificates, verification, federation, and delegated zones as well as web traffic. Application and plan inventory prevents later caching or WAF rules from assuming features and paths that do not exist.

What to understand

Export through the existing provider API when AXFR is denied, then compare apex, wildcard, A/AAAA/CNAME, MX, TXT, CAA, SRV, DKIM, SPF, DMARC, DNSKEY/DS, and child NS records.

Classify each web route as public immutable, public dynamic, authenticated, personalized, administrative, mutation, API, webhook, preview, cart, or checkout. Record Cache-Control, cookies, Authorization, methods, and purge expectations.

Document prior nameservers, registrar access, origin console access, publicly trusted recovery certificate, firewall rollback, and service owners before the window.

System changes

Reads DNS and local inventory only; OneLiners does not execute any command.

Syntax explained

dig AXFR: Attempts a zone transfer only where the current provider permits it; failure is expected on many services.
dig DS: Captures the existing parent chain-of-trust state before delegation changes.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Apex domain being delegated and protected.Previous Nameserver One{{previousNameserverOne}}First prior authoritative nameserver retained for cutover rollback.

dig AXFR {{zoneName}} @{{previousNameserverOne}} || true; dig NS {{zoneName}} +short; dig DS {{zoneName}} +short

Example output / evidence

; Transfer failed.
ns1.previous-dns.example.
ns2.previous-dns.example.
2371 13 2 8A1E...F09C

Checkpoint: The migration has a complete signed inventory

dig NS {{zoneName}} +short; dig DS {{zoneName}} +short

Continue whenRecords, owners, protocols, sensitive paths, plan limits, certificates, origin controls, TTLs, DNSSEC, and rollback access are reviewed.

Stop whenAny service record, owner, secret path, plan boundary, prior nameserver, or recovery route is unknown.

If this step fails

The zone remains Pending and Cloudflare protections do not apply.

Likely causeThe registrar still delegates to old nameservers, copied nameserver values are incomplete, DNSSEC has a stale DS record, or the ownership check has not completed. A pending zone is not a production proxy.

Safe checks

dig NS {{zoneName}} +short
dig +trace NS {{zoneName}}
Query the zone status with a Zone Read API token.

ResolutionCompare registrar delegation with the exact assigned Cloudflare nameservers, correct only the registrar settings, and wait for delegation caches. If DNSSEC was already active, follow Cloudflare's documented migration or multi-signer process rather than leaving an incompatible DS record.

A hostname resolves to the wrong origin or disappears after import.

Likely causeAutomatic scanning missed a record, flattened a dependency differently, copied a stale value, or did not preserve a required DNS-only service record.

Safe checks

dig A {{zoneName}} @{{cloudflareNameserver}} +noall +answer
dig CNAME www.{{zoneName}} @{{cloudflareNameserver}} +noall +answer
Compare the signed pre-cutover DNS inventory.

ResolutionKeep delegation unchanged or roll it back while correcting Cloudflare records. Reconcile A, AAAA, CNAME, MX, TXT, CAA, SRV, DKIM, SPF, DMARC, validation, and subdomain delegation records explicitly; never trust an automatic scan as the complete source of truth.

Mail, SSH, FTP, or another non-HTTP service stops working.

Likely causeA hostname used by a non-proxyable protocol was orange-clouded, an MX target points at a proxied name, or the origin firewall was restricted without a separate DNS-only service address.

Safe checks

dig MX {{zoneName}} +short
dig A mail.{{zoneName}} +short
Inspect proxy status for every A, AAAA, and CNAME record.

ResolutionSet the service hostname and every MX target to DNS only, restore the approved origin access for that protocol, and verify it independently. Use distinct web and infrastructure hostnames so proxy and firewall policy do not conflict.

Security notes

Store exports as sensitive operational data; they reveal origin and service topology.

Alternatives

Migrate a delegated low-risk subdomain first when the apex inventory cannot yet be proven.

Stop conditions

Do not add the production zone from an incomplete scanner result.

instruction

Create scoped tokens and add the zone without delegation

read-only

Create separate zone-scoped API tokens for read, DNS changes, settings, cache purge, and security automation as ownership requires. Add the primary zone, record its assigned nameservers and zone ID, and keep registrar delegation unchanged.

Why this step matters

A zone can be built and checked while traffic remains on the prior authority. Scoped tokens reduce blast radius and make automation ownership auditable. Pending is expected before delegation, but paid production features must not be treated as active until Cloudflare confirms ownership.

What to understand

Prefer Account API tokens for service automation where endpoint compatibility permits; use user tokens only with lifecycle ownership. Never use the Global API Key.

Limit resource scope to the one zone and permissions to the current job. Store tokens in a secret manager and inject them into environment memory, not shell history or repository.

Record nameservers exactly. Similar-looking names from another zone or account will not activate this zone.

System changes

Creates Cloudflare zone metadata and scoped credentials but does not change public delegation.

Syntax explained

Authorization: Bearer: Uses a scoped API token supplied through the protected environment.
status: Shows Pending until delegation ownership is verified and Active afterward.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Id{{zoneId}}Cloudflare zone identifier used by scoped API requests.

curl -sS https://api.cloudflare.com/client/v4/zones/{{zoneId}} -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq '{success,result:{id:.result.id,name:.result.name,status:.result.status,name_servers:.result.name_servers}}'

Example output / evidence

{"success":true,"result":{"id":"023e105f4ecef8ad9ca31a8372d0c353","name":"example.com","status":"pending","name_servers":["ada.ns.cloudflare.com","bob.ns.cloudflare.com"]}}

Checkpoint: The zone exists with least privilege and no traffic impact

curl -sS https://api.cloudflare.com/client/v4/zones/{{zoneId}} -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq -e '.success and .result.name == "{{zoneName}}"'

Continue whenThe exact zone, account, assigned nameservers, token owner, permissions, expiry, and revocation procedure are recorded.

Stop whenThe token is global or cross-account, zone identity is wrong, or nameserver values are not preserved.

If this step fails

The zone remains Pending and Cloudflare protections do not apply.

Safe checks

dig NS {{zoneName}} +short
dig +trace NS {{zoneName}}
Query the zone status with a Zone Read API token.

Security notes

Revoke bootstrap write tokens after migration or rotate them into narrowly owned automation identities.

Alternatives

Use the dashboard for a one-time zone addition while retaining role separation and audit evidence.

Stop conditions

Do not change registrar delegation while the zone inventory is incomplete.

config

Recreate records with web hostnames DNS only initially

read-only

Create and compare all records. Keep web A, AAAA, and CNAME records DNS only during origin validation; keep MX targets, mail, verification, and non-HTTP service names DNS only permanently.

Why this step matters

Authoritative comparison before delegation catches omissions without affecting normal resolver traffic. The assigned Cloudflare nameservers are publicly queryable even before parent delegation, so DNS-only staging is not secret: it merely prevents ordinary resolution from discovering the draft zone. After cutover, web names are proxied to stop publishing the origin through normal DNS and to activate edge products.

What to understand

Compare normalized answers and TTL intent, not export-file formatting. Preserve TXT quoting, MX priority, CAA, SRV weight/port, wildcard scope, and delegated child NS sets.

Do not proxy an MX target or protocol that Cloudflare's ordinary HTTP proxy does not serve. Give mail and administration separate names and controls.

Avoid publishing a new DNS-only recovery hostname pointing to the origin; use console, VPN, private DNS, or protected hosts-file procedures.

System changes

Writes Cloudflare DNS records while public authority remains at the prior provider.

Syntax explained

@{{cloudflareNameserver}}: Queries Cloudflare authoritatively before registrar cutover.
DNS only: Returns configured origin data without applying Cloudflare HTTP products.

Configuration

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.Cloudflare Nameserver{{cloudflareNameserver}}One assigned Cloudflare authoritative nameserver.Zone Name{{zoneName}}Apex domain being delegated and protected.

dig A {{originHost}} @{{cloudflareNameserver}} +noall +answer; dig MX {{zoneName}} @{{cloudflareNameserver}} +noall +answer; dig TXT _dmarc.{{zoneName}} @{{cloudflareNameserver}} +noall +answer

Example output / evidence

www.example.com. 300 IN A 203.0.113.20
example.com. 300 IN MX 10 mail.example.com.
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Checkpoint: Cloudflare answers the complete approved zone

dig A {{originHost}} @{{cloudflareNameserver}} +noall +answer; dig MX {{zoneName}} @{{cloudflareNameserver}} +noall +answer

Continue whenEvery record matches the signed inventory and each proxy status matches its protocol and security role.

Stop whenAny answer, priority, TXT value, delegation, wildcard, or proxy classification differs.

If this step fails

A hostname resolves to the wrong origin or disappears after import.

Likely causeAutomatic scanning missed a record, flattened a dependency differently, copied a stale value, or did not preserve a required DNS-only service record.

Safe checks

dig A {{zoneName}} @{{cloudflareNameserver}} +noall +answer
dig CNAME www.{{zoneName}} @{{cloudflareNameserver}} +noall +answer
Compare the signed pre-cutover DNS inventory.

Mail, SSH, FTP, or another non-HTTP service stops working.

Safe checks

dig MX {{zoneName}} +short
dig A mail.{{zoneName}} +short
Inspect proxy status for every A, AAAA, and CNAME record.

Security notes

Do not leave the web origin gray-clouded after production activation.

Alternatives

Use Cloudflare's import as a draft, then reconcile every record manually.

Stop conditions

Do not delegate while mail or certificate validation records are unverified.

config

Install and verify the origin certificate

read-only

Install a publicly trusted certificate or Cloudflare Origin CA certificate with the exact hostname SAN, protected private key, complete chain, independent expiry alert, and safe reload. Prefer public trust when direct emergency browser access is required.

Why this step matters

Full (strict) depends on origin identity, not only encryption. Origin CA is valid to Cloudflare but not ordinary browsers, and Cloudflare currently sends no Origin CA expiry notification. The recovery design therefore determines certificate choice and monitoring.

What to understand

Generate and transfer private material through protected systems, set restrictive file ownership, validate config, and reload rather than restart when supported.

Confirm SAN, validity, issuer, chain, SNI virtual host, and health response directly before edge activation. Record the expected fingerprint without exposing the key.

Use the system CA bundle for a publicly trusted origin certificate. For Origin CA, download and pin the official Cloudflare Origin CA root bundle through a protected process; a default browser or curl trust store will correctly reject Origin CA.

Create expiry alerts against the origin endpoint separately from public edge certificate monitoring.

System changes

Writes origin certificate and key files and reloads the origin only through the operator's reviewed system.

Syntax explained

-servername {{originHost}}: Sends SNI so the origin presents the production virtual-host certificate.
-ext subjectAltName: Shows hostnames Full (strict) must match.

Configuration

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Origin Ip{{originIp}}Origin address retained in protected inventory and never published through a DNS-only web record.Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.Origin Trust Bundle Path{{originTrustBundlePath}}CA bundle used by direct origin checks: the ordinary system trust bundle for a publicly trusted certificate, or the official Cloudflare Origin CA root bundle for an Origin CA certificate.

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -CAfile {{originTrustBundlePath}} -verify_return_error -verify_hostname {{originHost}} </dev/null 2>&1 | grep -E 'Verification|Verify return code|verify error' && openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Example output / evidence

subject=CN=www.example.com
issuer=O=Cloudflare, Inc., OU=Cloudflare Origin SSL Certificate Authority
notBefore=Jul 28 00:00:00 2026 GMT
notAfter=Jul 25 23:59:59 2036 GMT
X509v3 Subject Alternative Name: DNS:www.example.com
sha256 Fingerprint=7A:31:8C:09:...:D2

Checkpoint: Origin TLS is valid before strict edge use

curl --cacert {{originTrustBundlePath}} --resolve {{originHost}}:443:{{originIp}} -sSvo /dev/null https://{{originHost}}{{healthPath}}

Continue whenTLS validates under the chosen trust path, Host/SNI select the right service, health is 200, and expiry monitoring is active.

Stop whenCertificate is invalid, key permissions are broad, the hostname mismatches, or emergency trust is unplanned.

If this step fails

Visitors receive Cloudflare error 526.

Likely causeFull (strict) cannot validate the origin certificate because it is expired, not yet valid, signed by an unsupported authority, missing the requested hostname, or presented with an incomplete or wrong chain.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -showcerts </dev/null
curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Inspect the certificate SAN, validity, issuer, and served chain.

ResolutionInstall a valid publicly trusted certificate or Cloudflare Origin CA certificate with the exact origin hostname, correct the chain and virtual-host selection, and verify direct TLS before retaining Full (strict). Do not weaken the zone to Flexible.

Visitors receive Cloudflare error 525 or TLS handshake failure.

Likely causeThe origin does not support TLS on the selected port, SNI selects no certificate, protocols or ciphers have no overlap, AOP expects a client certificate before Cloudflare sends one, or a firewall terminates the handshake.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null
Inspect origin TLS and reverse-proxy logs.
Temporarily test from an approved Cloudflare path without weakening public access.

ResolutionRepair origin listener, SNI, certificate chain, supported TLS, AOP ordering, and firewall path. Validate Full (strict) end to end in a canary hostname before production proxying.

An Origin CA certificate expires without warning.

Likely causeCloudflare Origin CA does not currently send expiration notifications, and monitoring watched only the public edge certificate rather than the certificate served by the origin.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null 2>/dev/null | openssl x509 -noout -dates -fingerprint -sha256
Review origin certificate inventory and alert ownership.
Test renewal and reload in a canary.

ResolutionMonitor origin certificate expiry independently, renew and deploy through the protected secret path, validate SAN and fingerprint, reload safely, and retain the prior key only for a bounded rollback. Consider a publicly trusted automated certificate when direct recovery access is required.

Security notes

An Origin CA certificate is not a public browser certificate and must not be presented as one.

Alternatives

Use automated ACME public certificates for portable direct trust.

Stop conditions

Never lower to Flexible to compensate for a broken origin certificate.

config

Set Full (strict) and validate a canary

read-only

Set the zone encryption mode to strict through a reviewed API or dashboard change, then test a canary proxied hostname before the primary host. Confirm visitor TLS, origin TLS, redirects, canonical URL, and mixed-content behavior.

Why this step matters

Strict mode rejects expired, mismatched, or untrusted origin certificates and prevents silent interception on the origin leg. A canary exposes handshake and application proxy-awareness problems without moving the primary hostname.

What to understand

Verify the edge certificate is active for the canary and the origin serves the correct SNI certificate.

Inspect redirect chains and forwarded-scheme trust. Trust Cloudflare headers only on network paths that actually come from Cloudflare.

Search rendered HTML and APIs for insecure absolute URLs before promoting the primary record.

System changes

Changes the Cloudflare zone SSL/TLS mode; OneLiners does not perform the API call.

Syntax explained

"value":"strict": Cloudflare API value for Full (strict).
PATCH: Updates one zone setting and requires the corresponding scoped permission.

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Id{{zoneId}}Cloudflare zone identifier used by scoped API requests.

curl -sS -X PATCH https://api.cloudflare.com/client/v4/zones/{{zoneId}}/settings/ssl -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -H "Content-Type: application/json" --data '{"value":"strict"}' | jq '{success,result:{id:.result.id,value:.result.value}}'

Example output / evidence

{"success":true,"result":{"id":"ssl","value":"strict"}}

Checkpoint: Both TLS legs and application redirects are correct

curl -sSIL https://{{originHost}}/

Continue whenEdge certificate is valid, Full (strict) reaches the correct origin certificate, redirects terminate, and no mixed content appears.

Stop whenAny 525/526, loop, wrong certificate, insecure URL, or unexpected origin host appears.

If this step fails

Visitors receive Cloudflare error 526.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -showcerts </dev/null
curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Inspect the certificate SAN, validity, issuer, and served chain.

Visitors receive Cloudflare error 525 or TLS handshake failure.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null
Inspect origin TLS and reverse-proxy logs.
Temporarily test from an approved Cloudflare path without weakening public access.

ResolutionRepair origin listener, SNI, certificate chain, supported TLS, AOP ordering, and firewall path. Validate Full (strict) end to end in a canary hostname before production proxying.

The site enters an HTTP redirect loop or reports mixed content.

Likely causeThe origin does not trust Cloudflare's forwarded scheme, rewrites HTTPS to HTTP, an application base URL remains HTTP, or Flexible mode was used against an HTTPS redirect. Mixed absolute asset URLs can survive a successful TLS cutover.

Safe checks

curl -sSIL https://{{originHost}}/
Inspect the Location chain and origin request headers.
Check application canonical URL and proxy-trust configuration.

ResolutionKeep Full (strict), configure the origin and application to trust only the expected proxy headers from Cloudflare, remove contradictory redirects, and replace insecure absolute content URLs. Never solve the loop by disabling origin encryption.

Security notes

Do not use Off, Flexible, or non-validating Full as a permanent workaround.

Alternatives

Use a configuration rule for a scoped application only when current plan and rule behavior are reviewed.

Stop conditions

Do not proxy the production hostname until the canary passes from multiple clients.

config

Enforce authenticated and network-restricted origin access

read-only

Install the official or account-specific AOP trust at the origin, test client-certificate handling, enable the matching Cloudflare AOP mode, then restrict ingress to current official Cloudflare ranges plus explicit private recovery and monitoring paths.

Why this step matters

Full (strict) authenticates the origin to Cloudflare but does not authenticate Cloudflare to the origin. AOP supplies mTLS; network allowlisting and strict routing reduce bypass. The global certificate's shared-account boundary must remain explicit.

What to understand

Stage trust before enforcement and preserve console access. Global, zone-level, and per-hostname AOP are independent settings; configure the one the origin expects.

Automate official Cloudflare IP range updates through review, or use private connectivity. Do not hardcode an abandoned list indefinitely.

Keep health probes, ACME validation, administration, and emergency recovery on deliberate paths; never open the whole origin when one probe fails.

System changes

Changes origin mTLS and firewall enforcement and Cloudflare AOP settings through the operator's systems.

Syntax explained

ssl_verify_client on: Requires a trusted client certificate at the NGINX origin listener.
global AOP: Proves Cloudflare network origin, but not an account-exclusive client identity.

File /etc/nginx/conf.d/origin-mtls.conf

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Aop Ca Path{{aopCaPath}}Origin trust path containing the exact official Cloudflare or account-specific AOP client CA certificate.

ssl_client_certificate {{aopCaPath}};
ssl_verify_client on;

# Also enforce strict server_name routing and a reviewed network allowlist.
# The global Cloudflare AOP certificate is shared across accounts.

Example output / evidence

Cloudflare proxied request: HTTP/2 200
Direct request without client certificate: TLS alert certificate required
Origin firewall: arbitrary internet source denied

Checkpoint: Cloudflare succeeds while direct origin bypass fails

curl --resolve {{originHost}}:443:{{originIp}} -sS https://{{originHost}}{{healthPath}} || echo 'direct origin denied as expected'

Continue whenProxied health is 200; external direct requests without approved identity fail; console and monitoring recovery remain available.

Stop whenAll traffic fails, direct access succeeds, global AOP is misrepresented, or firewall recovery is unavailable.

If this step fails

The origin still responds when addressed directly from the internet.

Likely causeThe firewall permits arbitrary source IPs, AOP is not enforced, a second listener bypasses mTLS, a DNS-only hostname exposes the origin, or a load balancer security group remains broad.

Safe checks

curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Test without the approved AOP client certificate from an external host.
Inventory historical and current DNS records for the origin IP.

ResolutionEnforce AOP at the TLS listener or an equivalent account-specific origin authentication, restrict network ingress to current Cloudflare IP ranges and approved health or administration paths, close alternate listeners, and retest both Cloudflare success and direct denial.

After enabling Authenticated Origin Pulls, every request fails.

Likely causeThe origin trust store has the wrong Cloudflare AOP certificate, client verification is enforced on a listener needed before Cloudflare is configured, zone and global AOP modes are confused, or an intermediate proxy strips client-certificate authentication.

Safe checks

Inspect origin TLS client-verification logs.
Confirm the configured AOP mode in Cloudflare.
Verify the installed client CA fingerprint from the official Cloudflare source.

ResolutionUse a staged canary: install and test client-certificate validation first, enable the matching Cloudflare AOP mode, then enforce it. Retain console access and a time-bounded rollback that does not expose the origin broadly.

Global AOP is enabled but the team assumes only its zone can reach the origin.

Likely causeCloudflare's global AOP client certificate is shared across accounts. It proves a request came from Cloudflare's network, not from one particular customer zone.

Safe checks

Review whether global, zone-level, or per-hostname AOP is configured.
Inspect the origin client-certificate trust and network policy.
Test Host and SNI restrictions at the origin.

ResolutionUse zone-level or per-hostname AOP with an account-controlled certificate where supported and required, or combine global AOP with Cloudflare IP allowlisting, strict Host/SNI routing, private origin connectivity, and application authentication. Document the exact guarantee.

Cloudflare returns 522 or 523 and cannot reach the origin.

Likely causeThe origin address is wrong, routing or firewall rules exclude current Cloudflare IP ranges, the listener is down, an upstream blocks Cloudflare, or origin capacity is exhausted.

Safe checks

Verify the DNS record content in Cloudflare.
Check origin listener, routing, firewall, and load-balancer health.
Correlate Cloudflare Ray ID, timestamp, and origin logs.

ResolutionRestore the correct origin route and listener, update restrictions from official Cloudflare IP ranges through a reviewed process, and recover capacity. Do not expose the origin to the whole internet as a diagnostic shortcut.

Security notes

Zone/per-hostname AOP or private connectivity provides stricter origin identity than shared global AOP.

Alternatives

Use Cloudflare Tunnel after separately validating identity, redundancy, egress, observability, and rollback.

Stop conditions

Do not advertise origin protection until direct external denial is proven.

command

Change nameservers and wait for Active status

caution

At the registrar, replace only the authoritative nameservers with the exact Cloudflare pair. Preserve prior delegation and timestamps, monitor old and new authorities during TTL propagation, and wait for Cloudflare zone status Active.

Why this step matters

Registrar delegation is the public cutover and is cached according to parent and resolver behavior. Cloudflare protections do not reliably apply while the zone remains Pending. Keeping both authorities consistent during propagation limits split answers.

What to understand

Do not add unrelated glue, DS, or registrar changes in the same action unless the reviewed DNSSEC migration explicitly requires them.

Query parent, old authority, new authority, and multiple recursive resolvers. Expected disagreement during TTL propagation must not include missing records.

Rollback means restoring both prior nameservers while they still serve the current complete zone, then waiting for caches.

System changes

Changes registrar delegation and begins public DNS migration.

Syntax explained

+trace: Walks the delegation path from root to authoritative nameservers.
active: Cloudflare has verified ownership and activated the zone.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Apex domain being delegated and protected.Zone Id{{zoneId}}Cloudflare zone identifier used by scoped API requests.

dig NS {{zoneName}} +trace; curl -sS https://api.cloudflare.com/client/v4/zones/{{zoneId}} -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq -r '.result.status'

Example output / evidence

example.com. 86400 IN NS ada.ns.cloudflare.com.
example.com. 86400 IN NS bob.ns.cloudflare.com.
active

Checkpoint: Public resolvers reach an Active complete zone

dig NS {{zoneName}} +short; dig A {{originHost}} +short

Continue whenDelegation converges on assigned Cloudflare nameservers, zone is Active, and all service answers match inventory.

Stop whenZone remains Pending, records split incorrectly, mail fails, or prior delegation cannot be restored.

If this step fails

The zone remains Pending and Cloudflare protections do not apply.

Safe checks

dig NS {{zoneName}} +short
dig +trace NS {{zoneName}}
Query the zone status with a Zone Read API token.

A hostname resolves to the wrong origin or disappears after import.

Likely causeAutomatic scanning missed a record, flattened a dependency differently, copied a stale value, or did not preserve a required DNS-only service record.

Safe checks

dig A {{zoneName}} @{{cloudflareNameserver}} +noall +answer
dig CNAME www.{{zoneName}} @{{cloudflareNameserver}} +noall +answer
Compare the signed pre-cutover DNS inventory.

Mail, SSH, FTP, or another non-HTTP service stops working.

Safe checks

dig MX {{zoneName}} +short
dig A mail.{{zoneName}} +short
Inspect proxy status for every A, AAAA, and CNAME record.

Security notes

Keep registrar MFA, recovery codes, and registry-lock procedures protected.

Alternatives

Use Cloudflare's documented multi-provider design only after a separate compatibility and DNSSEC review.

Stop conditions

Do not continue to proxy and rules rollout on a Pending production zone.

command

Proxy web records in staged order

caution

Orange-cloud a low-risk web canary, verify edge addresses, headers, TLS, origin logs, and direct denial, then proxy the primary A, AAAA, or CNAME web record. Leave non-web records DNS only.

Why this step matters

Proxying changes both DNS answers and the HTTP path. A canary reveals origin routing, AOP, firewall, TLS, and application header behavior before the primary host. Proxied Auto TTL currently uses 300 seconds and is distinct from content caching.

What to understand

Confirm DNS returns Cloudflare anycast addresses rather than the origin. Preserve origin IP only in protected inventory.

Correlate Ray ID and UTC time with origin logs, confirm the expected Host, client IP restoration method, and scheme.

Verify mail and infrastructure hostnames still return their real DNS-only targets and are not pulled into a mixed proxied address set.

System changes

Changes selected web DNS records from DNS only to Proxied.

Syntax explained

cf-ray: Identifies the edge request for cross-system troubleshooting.
CF-Cache-Status: DYNAMIC: Expected for a dynamic health response and not evidence of cache failure.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

dig A {{originHost}} +short; curl -sSvo /dev/null https://{{originHost}}{{healthPath}} 2>&1 | grep -Ei 'HTTP/|server:|cf-ray:|cf-cache-status:'

Example output / evidence

104.21.64.10
172.67.128.20
< HTTP/2 200
< server: cloudflare
< cf-ray: 9c1a2b3c4d5e1234-WAW
< cf-cache-status: DYNAMIC

Checkpoint: Primary web traffic traverses Cloudflare safely

dig A {{originHost}} +short; curl -sSI https://{{originHost}}{{healthPath}}

Continue whenCloudflare addresses, valid edge TLS, 200 health, Ray ID, correct origin Host/SNI, and direct-origin denial are proven.

Stop whenOrigin IP is returned, non-web service breaks, TLS fails, origin is unreachable, or direct access succeeds.

If this step fails

Cloudflare returns 522 or 523 and cannot reach the origin.

Likely causeThe origin address is wrong, routing or firewall rules exclude current Cloudflare IP ranges, the listener is down, an upstream blocks Cloudflare, or origin capacity is exhausted.

Safe checks

Verify the DNS record content in Cloudflare.
Check origin listener, routing, firewall, and load-balancer health.
Correlate Cloudflare Ray ID, timestamp, and origin logs.

Cloudflare returns 520 or 524 for application requests.

Likely causeThe origin sent an empty, malformed, oversized, or unexpected response, closed the connection, or exceeded Cloudflare's applicable proxy timeout. Long synchronous jobs may not fit the request path.

Safe checks

Correlate Ray ID and timestamp with origin access and error logs.
Test the same Host and SNI from the approved origin path.
Measure upstream processing time and response headers.

ResolutionCorrect origin response handling, capacity, and application timeouts; redesign long jobs as asynchronous workflows. Enterprise-only timeout settings should be considered only when contract availability and application behavior justify them.

Operators expect a custom DNS TTL on an orange-clouded record.

Likely causeProxied records use Cloudflare's predefined Auto TTL, currently 300 seconds, and the value cannot be edited like a DNS-only record.

Safe checks

dig A {{originHost}} +noall +answer
Inspect the record proxy status.
Review resolver and browser caches separately.

ResolutionPlan cutover around proxied-record behavior and distinguish DNS TTL, edge cache TTL, browser TTL, and application caching. Do not toggle to DNS only merely to control TTL because that exposes the origin and bypasses Cloudflare.

Security notes

Historical DNS may still reveal the origin; rotate origin addresses where threat modeling requires it.

Alternatives

Promote hostnames one at a time with synthetic monitoring and a documented rollback threshold.

Stop conditions

Do not gray-cloud the production hostname as a generic troubleshooting step.

config

Deploy bypass-first cache safety rules

read-only

Create highest-priority bypass rules for authenticated, personalized, administrative, mutation, API, webhook, cart, checkout, preview, and sensitive paths. Respect origin private/no-store controls and test two-user isolation.

Why this step matters

Caching is an authorization boundary when one edge object can be reused across users. Safety bypasses must precede performance rules and be tested with separate identities. Cloudflare may report DYNAMIC when a Cache Rule makes content ineligible.

What to understand

Do not use a broad cache-everything template on dynamic applications. Identify all cookies and headers that signal personalization.

Test GET, HEAD, POST, error, redirect, authenticated, anonymous, and logout behavior. Verify Set-Cookie never becomes shared content.

Keep bypass expressions comprehensible and versioned. Use Trace to simulate evaluation order, then real requests for evidence.

System changes

Deploys cache ineligibility rules for sensitive traffic.

Syntax explained

Bypass cache: Makes matching requests ineligible for edge caching.
rule order: Determines which cache settings apply when expressions overlap.

File Cloudflare Cache Rules

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Private Path{{privatePath}}Authenticated or personalized path that must always bypass shared cache.

Bypass shared cache when:
- URI path starts with {{privatePath}}
- Authorization header is present
- Session or authentication cookie is present
- Method is not GET or HEAD
- Response is private, no-store, or otherwise user-specific

Deploy these rules before public-asset eligibility rules.

Example output / evidence

Unauthenticated profile request: CF-Cache-Status DYNAMIC
Session A response: user A only
Session B response: user B only
Cross-user body comparison: distinct

Checkpoint: Sensitive content cannot cross sessions

curl -sSI https://{{originHost}}{{privatePath}}

Continue whenSensitive paths are never HIT, two isolated sessions never share bodies, and origin private/no-store behavior remains effective.

Stop whenAny authenticated or personalized response is HIT or appears in another session.

If this step fails

Authenticated or personalized content is served from cache.

Likely causeA broad cache-everything rule ignored cookies, Authorization, method, path, or origin `private` and `no-store` controls, causing multiple users to share a cache key.

Safe checks

Test two isolated sessions and one unauthenticated client.
Inspect CF-Cache-Status, Age, Cache-Control, Set-Cookie, and Vary.
Use Cloudflare Trace for account, admin, API, cart, and checkout paths.

ResolutionPurge affected content, disable the broad eligibility rule, place explicit bypasses for authenticated, personalized, mutation, and sensitive paths first, respect origin cache controls, rotate exposed session material where necessary, and test cross-user isolation.

Security notes

Purge and rotate session material immediately if cross-user cache leakage is detected.

Alternatives

Cache only immutable assets and leave all HTML and APIs under default origin controls.

Stop conditions

Do not create public cache eligibility until this negative test passes.

config

Cache only reviewed public immutable assets

read-only

Add a narrow rule for the versioned public asset path, prefer origin Cache-Control, define bounded edge and browser TTL behavior, keep the default cache key unless variation is proven, and document precise purge semantics.

Why this step matters

Versioned assets make long TTLs safe because a deployment changes the URL rather than mutating cached content. Respecting origin directives preserves one source of cache intent. Custom keys add purge and isolation complexity and should not be introduced without a concrete requirement.

What to understand

Use Trace to confirm rule match and order. Cache Rules are available on all plans but rule counts and advanced settings vary.

Test MISS then HIT, content digest equality, compression, ranges where applicable, and that query or language variation does not corrupt content.

Document whether purge by URL works with the key. Header, cookie, or custom-property keys can require API purge with every component or a broader host/prefix/tag purge.

System changes

Makes only reviewed public asset requests eligible for Cloudflare edge caching.

Syntax explained

Eligible for cache: Allows Cloudflare to attempt caching; it does not guarantee a HIT.
Respect origin: Uses application Cache-Control rather than hiding release intent in an edge-only TTL.

File Cloudflare Cache Rules

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.

Eligible for cache when:
- Hostname equals {{originHost}}
- URI path starts with /assets/
- Method is GET or HEAD
- No authentication or session signal exists

Edge TTL: respect origin Cache-Control
Browser TTL: respect origin
Cache key: default unless a reviewed requirement proves otherwise

Example output / evidence

First request:  CF-Cache-Status: MISS
Second request: CF-Cache-Status: HIT
age: 3
cache-control: public, max-age=31536000, immutable

Checkpoint: Public assets cache and sensitive routes do not

curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{privatePath}}

Continue whenThe asset progresses MISS to HIT with correct digest and Age; the private path never returns HIT.

Stop whenContent varies by user, private content caches, rules do not match, or purge method is unknown.

If this step fails

A cacheable asset always returns CF-Cache-Status DYNAMIC.

Likely causeThe record is DNS only, a bypass Cache Rule matches, origin Cache-Control or cookies make the response ineligible, the method or status is not cacheable, or the rule order prevents eligibility.

Safe checks

curl -sSI https://{{originHost}}{{staticPath}}
Use Cloudflare Trace for the exact URL.
Review Cache Rules order and origin response headers.

ResolutionConfirm the hostname is proxied, find the matching rule in Trace, remove unintended cookie or private directives only for public assets, and use a narrow eligible-cache rule after all safety bypasses. A bypass rule may legitimately report DYNAMIC.

A purge does not remove every cached variant.

Likely causeA custom cache key includes headers, cookies, query components, or other request properties that a dashboard single-file purge cannot reproduce.

Safe checks

Review custom cache-key settings.
Repeat requests with each known key variant.
Inspect Cloudflare Cache Rules and purge documentation.

ResolutionPurge with the API while supplying every key component, or use a supported host, prefix, tag, or full-zone purge appropriate to the incident. Simplify high-cardinality cache keys and document the exact purge method before production.

Users receive stale or inconsistent content after deployment.

Likely causeEdge TTL exceeds the release strategy, browsers retain an overridden Browser TTL, cache keys omit version information, or purge completed for only one variant or hostname.

Safe checks

curl -sSI https://{{originHost}}{{purgeUrl}}
Compare Age, ETag, Last-Modified, Cache-Control, and CF-Cache-Status.
Test multiple regions or approved probes.

ResolutionPrefer immutable versioned asset URLs, respect origin directives, use bounded edge and browser TTLs, and purge the documented key scope. Do not use Purge Everything as a routine deployment mechanism.

Security notes

Avoid cache keys containing high-cardinality or secret-bearing headers and cookies.

Alternatives

Use default CDN caching plus origin Cache-Control without any Cache Rule.

Stop conditions

Do not override no-store or private responses to chase cache ratio.

verification

Prove precise purge and deployment behavior

read-only

Purge the test URL using a dedicated scoped token, then verify EXPIRED/MISS followed by HIT and the new immutable content digest. Rehearse host, prefix, tag, or full-zone alternatives only where plan support and incident scope justify them.

Why this step matters

A cache design is incomplete without a proven invalidation method. Single-file purge can miss custom-key variants, while Purge Everything creates avoidable origin load. Immutable URLs should make purge exceptional, but operators still need a precise incident response.

What to understand

Use a separate Cache Purge token scoped to the zone. Record who can purge and alert on broad purges.

Compare content digest and headers before and after purge. A successful API response does not prove every custom-key variant disappeared.

Load-test origin capacity for broader purge recovery and stagger deployments to avoid a thundering herd.

System changes

Removes the selected cached object from Cloudflare edge caches; it does not change origin content.

Syntax explained

"files": Requests a URL-scoped purge for the listed absolute URL.
Purge Everything: Broad emergency action that should not be routine deployment behavior.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Id{{zoneId}}Cloudflare zone identifier used by scoped API requests.Purge Url{{purgeUrl}}Public URL used to test precise cache purge behavior.

curl -sS -X POST https://api.cloudflare.com/client/v4/zones/{{zoneId}}/purge_cache -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -H "Content-Type: application/json" --data '{"files":["{{purgeUrl}}"]}' | jq '{success,result}'

Example output / evidence

{"success":true,"result":{"id":"023e105f4ecef8ad9ca31a8372d0c353"}}

Checkpoint: The documented key can be invalidated safely

curl -sSI {{purgeUrl}}; curl -sSI {{purgeUrl}}

Continue whenThe first post-purge request fetches current origin content and the next eligible request can HIT with the same digest.

Stop whenA stale variant remains, origin overloads, token scope is broad, or operators require Purge Everything routinely.

If this step fails

A purge does not remove every cached variant.

Likely causeA custom cache key includes headers, cookies, query components, or other request properties that a dashboard single-file purge cannot reproduce.

Safe checks

Review custom cache-key settings.
Repeat requests with each known key variant.
Inspect Cloudflare Cache Rules and purge documentation.

Users receive stale or inconsistent content after deployment.

Likely causeEdge TTL exceeds the release strategy, browsers retain an overridden Browser TTL, cache keys omit version information, or purge completed for only one variant or hostname.

Safe checks

curl -sSI https://{{originHost}}{{purgeUrl}}
Compare Age, ETag, Last-Modified, Cache-Control, and CF-Cache-Status.
Test multiple regions or approved probes.

Security notes

A purge token is a production availability credential; protect and audit it.

Alternatives

Deploy immutable content-addressed URLs that do not require invalidation.

Stop conditions

Do not broaden purge scope until origin capacity and cache-key behavior are known.

config

Stage WAF and rate limiting from observed traffic

read-only

Confirm current plan limits, enable applicable managed protections conservatively, review Security Events, and derive rate-limit scope and threshold from real traffic. Begin with observation or challenge behavior where available before block.

Why this step matters

WAF and rate limiting vary materially by plan. NAT, retries, bots, APIs, cached assets, and business bursts can make a guessed threshold block customers. Observation and analytics establish scope before enforcement.

What to understand

Check current official availability for rule count, fields, characteristics, periods, mitigation, cached-request behavior, logs, and account-level rules.

Use Trace for what-if evaluation and Security Events or available logs for real matches. Trace is simulation, not incident evidence.

Keep application authentication, authorization, quotas, and origin resource limits. Edge controls are defense in depth.

System changes

Deploys plan-supported WAF and rate-limiting rules through a separately reviewed Cloudflare change.

Syntax explained

counting characteristic: Defines how Cloudflare groups requests; availability is plan-dependent.
Managed Challenge: Can reduce false positives compared with immediate block, subject to plan and workflow suitability.

File Cloudflare Security Rules

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.

Example intent, translated only into plan-supported fields:
- Scope: login endpoint on {{originHost}}
- Exclude: verified health probe and reviewed automation only
- Count: plan-supported characteristic, commonly source IP on lower plans
- Threshold: derived from Security Analytics, not guessed
- Action: observe or Managed Challenge before block where supported
- Rollback: disable the exact rule and preserve event evidence

Example output / evidence

Security Events sample: 127 matches, 0 mitigated during observation
P99 legitimate login burst: 6 requests / 10 seconds
Proposed threshold: 20 requests / 10 seconds
Plan field check: supported

Checkpoint: Security rules reduce abuse without blocking valid users

curl -sSI https://{{originHost}}/login

Continue whenRepresentative users, NAT populations, APIs, health checks, and verified bots behave as approved while controlled abuse triggers the intended event and action.

Stop whenLegitimate traffic is blocked, plan fields are unsupported, event visibility is inadequate, or origin bypass remains possible.

If this step fails

WAF or rate limiting blocks legitimate users, APIs, or verified bots.

Likely causeA rule began in block mode without observation, thresholds ignored NAT or burst traffic, the match scope is broad, plan-specific characteristics are unavailable, or bot exclusions were omitted.

Safe checks

Review Security Events and sampled matches.
Use Cloudflare Trace for representative requests.
Compare request-rate analytics with the configured threshold and counting characteristics.

ResolutionDisable or narrow the offending rule, begin with log or managed-challenge behavior where available, derive thresholds from real traffic, exclude only proven safe automation, and account for NAT, retries, caching, and plan-specific field limitations.

Security notes

Do not whitelist broad ASNs, countries, user agents, or source ranges to solve one false positive.

Alternatives

Keep rules in observation and enforce application-level throttling until traffic evidence is sufficient.

Stop conditions

Do not claim Enterprise fields, logs, or timeouts on an unverified contract.

command

Enable DNSSEC and establish the parent chain of trust

caution

Enable Cloudflare DNSSEC, obtain the exact DS values, publish them through the registrar or allow supported CDS/CDNSKEY automation, wait for parent TTLs, and validate DNSKEY, RRSIG, DS, and answers from multiple validating resolvers.

Why this step matters

DNSSEC becomes effective only when the parent DS matches Cloudflare's signing keys. A dashboard toggle without parent confirmation offers no complete chain, while a wrong DS causes SERVFAIL for validating clients. Registrar automation support and TTLs determine safe sequencing.

What to understand

If the old zone was signed, use Cloudflare's documented migration or multi-signer process; never leave an old DS pointing at a new uncoordinated signer.

Registrars supporting RFC 8078 may consume CDS/CDNSKEY; others require exact manual DS entry. Cloudflare Registrar activation can take one to two days.

Verify authoritative signatures, parent DS, and AD-flag answers from diverse networks. Monitor DNS SERVFAIL and delegation continuously.

System changes

Activates Cloudflare signing and publishes or updates the parent DS chain through the registrar.

Syntax explained

+dnssec: Requests DNSSEC records and validation-related response data.
+trace: Shows delegation and DS data from the parent path.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Apex domain being delegated and protected.Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.

dig {{zoneName}} DNSKEY +dnssec; dig {{zoneName}} DS +trace; dig A {{originHost}} +dnssec @1.1.1.1

Example output / evidence

example.com. 3600 IN DNSKEY 257 3 13 ...
example.com. 3600 IN RRSIG DNSKEY 13 2 ...
example.com. 86400 IN DS 2371 13 2 8A1E...F09C
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

Checkpoint: Validating resolvers trust Cloudflare answers

dig A {{originHost}} +dnssec @1.1.1.1; dig DS {{zoneName}} +trace

Continue whenThe parent DS matches Cloudflare, DNSKEY/RRSIG are present, answers validate with AD, and no resolver reports SERVFAIL.

Stop whenDS mismatches, validation fails, unsigned authority remains delegated, or TTL sequencing is incomplete.

If this step fails

DNSSEC-enabled clients return SERVFAIL after cutover.

Likely causeThe parent publishes a stale or wrong DS record, Cloudflare signs with another key, delegation includes unsigned providers, or a DNSKEY/DS change was made without waiting for TTLs.

Safe checks

dig {{zoneName}} DNSKEY +dnssec
dig {{zoneName}} DS +trace
dig A {{zoneName}} +dnssec @1.1.1.1

ResolutionStop further DNS changes. Restore a valid chain of trust using the registrar and Cloudflare's documented DNSSEC migration or multi-signer sequence. Respect DS and DNSKEY TTLs; do not randomly remove signatures while caches contain the old chain.

The registrar shows DNSSEC enabled but Cloudflare status is not confirmed.

Likely causeThe registrar does not consume CDS/CDNSKEY automatically, manual DS data was copied incorrectly, registry propagation is incomplete, or the zone is not fully delegated.

Safe checks

Compare Cloudflare's DS values with the parent DS response.
dig DS {{zoneName}} +trace
Check DNSSEC status in Cloudflare after the documented wait.

ResolutionEnter the exact Cloudflare DS at registrars without RFC 8078 automation, wait for parent TTLs, and verify from validating resolvers. Cloudflare Registrar automation can take one to two days; do not declare success from a dashboard toggle alone.

Security notes

DNSSEC rollback must preserve a valid cached chain; deleting DS or keys in the wrong order can prolong outage.

Alternatives

Use Cloudflare's documented model 2 multi-signer design when another authority must remain active.

Stop conditions

Freeze all DNSSEC changes on the first validating SERVFAIL.

verification

Monitor DNS, edge, cache, security, TLS, and origin together

read-only

Create synthetic checks and alerts for delegation, DNSSEC, edge and origin certificate expiry, Full (strict), direct-origin denial, cache isolation, WAF events, rate limiting, 5xx, origin latency, and content freshness. Correlate Ray IDs with origin logs.

Why this step matters

Cloudflare adds distinct failure domains: authoritative DNS, DNSSEC, edge TLS, Rules, cache, WAF, edge-to-origin network, origin TLS, and application. One uptime probe cannot localize them. Origin CA expiry especially needs independent monitoring.

What to understand

Log UTC time, hostname, path class, HTTP status, Ray ID, cache status, edge colo where available, and synthetic identity without storing secrets.

Monitor direct-origin denial as a negative control and use private or account-specific probes for origin health.

Check current log and analytics retention for the plan; preserve incident evidence before sampled events expire.

System changes

Reads production signals and configures monitoring through the operator's own reviewed observability system.

Syntax explained

CF-Ray: Correlates edge request with Cloudflare and origin evidence.
CF-Cache-Status: Shows cache handling but must be interpreted with rule and response context.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.Health Path{{healthPath}}Non-sensitive origin health path with strict access and no shared user data.Origin Ip{{originIp}}Origin address retained in protected inventory and never published through a DNS-only web record.

curl -sSvo /dev/null https://{{originHost}}{{healthPath}} 2>&1 | grep -Ei 'HTTP/|cf-ray:|cf-cache-status:|server:'; openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null 2>/dev/null | openssl x509 -noout -enddate

Example output / evidence

< HTTP/2 200
< server: cloudflare
< cf-ray: 9c1a2b3c4d5e1234-WAW
< cf-cache-status: DYNAMIC
notAfter=Jul 25 23:59:59 2036 GMT

Checkpoint: Every layer has a positive and negative signal

curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{privatePath}}

Continue whenDNS, DNSSEC, certificates, proxy, origin denial, cache, WAF, rate limits, 5xx, latency, and application health have owners and tested alerts.

Stop whenAn alert cannot identify edge versus origin, Origin CA expiry is unmonitored, or logs expire before response.

If this step fails

Cloudflare returns 522 or 523 and cannot reach the origin.

Likely causeThe origin address is wrong, routing or firewall rules exclude current Cloudflare IP ranges, the listener is down, an upstream blocks Cloudflare, or origin capacity is exhausted.

Safe checks

Verify the DNS record content in Cloudflare.
Check origin listener, routing, firewall, and load-balancer health.
Correlate Cloudflare Ray ID, timestamp, and origin logs.

Cloudflare returns 520 or 524 for application requests.

Safe checks

Correlate Ray ID and timestamp with origin access and error logs.
Test the same Host and SNI from the approved origin path.
Measure upstream processing time and response headers.

An Origin CA certificate expires without warning.

Likely causeCloudflare Origin CA does not currently send expiration notifications, and monitoring watched only the public edge certificate rather than the certificate served by the origin.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null 2>/dev/null | openssl x509 -noout -dates -fingerprint -sha256
Review origin certificate inventory and alert ownership.
Test renewal and reload in a canary.

Security notes

Ray IDs and logs can contain internal route and request metadata; keep them inside the incident boundary.

Alternatives

Use plan-available Cloudflare analytics plus external synthetic checks and origin-native monitoring.

Stop conditions

Do not finish cutover with edge-only uptime monitoring.

warning

Rehearse rollback without exposing an untrusted origin

caution

Rehearse rule disable, precise purge, record de-proxy, nameserver restoration, DNSSEC-safe reversal, origin firewall recovery, and certificate replacement. Use a public origin certificate or private recovery path; do not gray-cloud an Origin CA-only hostname to browsers.

Why this step matters

Rollback spans systems with different caches and trust. Restoring nameservers does not instantly move every resolver, removing DS out of order creates validation failure, and DNS-only recovery exposes the origin while an Origin CA certificate appears untrusted to clients.

What to understand

Prefer the narrowest rollback: disable one bad rule, restore prior origin config, or purge one key before changing delegation.

For Cloudflare-wide bypass, prepare a publicly trusted origin certificate, correct firewall expansion, origin capacity, and monitoring before DNS-only exposure.

Keep old DNS authority complete until parent TTLs expire and coordinate DNSSEC key/DS sequencing from official documentation.

System changes

A rehearsal reads evidence; actual rollback changes Cloudflare, registrar, DNSSEC, cache, or origin only under the approved incident plan.

Syntax explained

rule rollback: Safest first response when one Cache, WAF, or rate rule caused impact.
delegation rollback: Broad last-resort change with parent TTL and DNSSEC consequences.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Apex domain being delegated and protected.Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.Health Path{{healthPath}}Non-sensitive origin health path with strict access and no shared user data.

dig NS {{zoneName}} +short; dig DS {{zoneName}} +trace; curl -sSI https://{{originHost}}{{healthPath}}

Example output / evidence

ada.ns.cloudflare.com.
bob.ns.cloudflare.com.
example.com. 86400 IN DS 2371 13 2 8A1E...F09C
HTTP/2 200

Checkpoint: Recovery preserves trust and origin security

dig NS {{zoneName}} +short; dig A {{originHost}} +dnssec @1.1.1.1

Continue whenOwners can reverse each layer in safe order while preserving valid TLS, DNSSEC, mail, origin restrictions, and observability.

Stop whenRollback requires broad origin exposure, untrusted Origin CA to browsers, stale DS, incomplete old DNS, or unknown cache variants.

If this step fails

Visitors receive Cloudflare error 526.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -showcerts </dev/null
curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Inspect the certificate SAN, validity, issuer, and served chain.

The origin still responds when addressed directly from the internet.

Safe checks

curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Test without the approved AOP client certificate from an external host.
Inventory historical and current DNS records for the origin IP.

A purge does not remove every cached variant.

Likely causeA custom cache key includes headers, cookies, query components, or other request properties that a dashboard single-file purge cannot reproduce.

Safe checks

Review custom cache-key settings.
Repeat requests with each known key variant.
Inspect Cloudflare Cache Rules and purge documentation.

DNSSEC-enabled clients return SERVFAIL after cutover.

Likely causeThe parent publishes a stale or wrong DS record, Cloudflare signs with another key, delegation includes unsigned providers, or a DNSKEY/DS change was made without waiting for TTLs.

Safe checks

dig {{zoneName}} DNSKEY +dnssec
dig {{zoneName}} DS +trace
dig A {{zoneName}} +dnssec @1.1.1.1

Security notes

Recovery credentials and prior origin paths are privileged and must not become permanent bypasses.

Alternatives

Use a second tested application endpoint with public TLS as an emergency service path.

Stop conditions

Never remove DNSSEC keys or DS records without TTL-aware sequencing.

verification

Complete the production acceptance and 90-day review

read-only

Audit records, proxy status, DNSSEC, strict TLS, AOP guarantees, direct denial, cache isolation and purge, security-rule entitlements, monitoring, scoped tokens, origin certificate expiry, and rollback. Record evidence and schedule review every 90 days.

Why this step matters

Cloudflare product limits, certificates, IP ranges, application paths, and traffic patterns evolve. Acceptance consolidates proof across layers; periodic review catches stale tokens, bypasses, cache keys, unsupported plan assumptions, expiring Origin CA, and origin exposure.

What to understand

Revoke bootstrap credentials, keep only owned automation tokens, and test emergency role access without exposing secrets.

Review every Cache, WAF, and rate rule for owner, order, current plan support, event evidence, rollback, and expiry.

Retest DNSSEC, certificate chains, AOP, official IP automation, direct denial, two-user cache isolation, precise purge, and synthetic alerts quarterly.

System changes

Reads acceptance evidence and updates operational records; no Cloudflare or origin setting changes.

Syntax explained

AD: Indicates the selected recursive resolver validated the DNSSEC answer.
90-day review: Bounds drift in plan-dependent security, cache, certificate, and origin controls.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Origin Host{{originHost}}Primary proxied web hostname and certificate SAN used for SNI, Host routing, and checks.Static Path{{staticPath}}Immutable public asset used for cache MISS/HIT tests.Private Path{{privatePath}}Authenticated or personalized path that must always bypass shared cache.

dig A {{originHost}} +dnssec @1.1.1.1; curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{privatePath}}

Example output / evidence

DNSSEC: AD
Public asset: CF-Cache-Status HIT
Private path: CF-Cache-Status DYNAMIC
Edge TLS: valid
Origin Full (strict): healthy
Direct origin: denied
Review due: 2026-10-22

Checkpoint: The zone is secure, observable, cache-safe, and recoverable

dig A {{originHost}} +dnssec @1.1.1.1; curl -sSI https://{{originHost}}{{healthPath}}

Continue whenAll acceptance evidence passes, owners and rollback are current, tokens are least privilege, and the next review is scheduled.

Stop whenAny layer lacks evidence, a direct bypass succeeds, sensitive content caches, or plan assumptions are undocumented.

If this step fails

Global AOP is enabled but the team assumes only its zone can reach the origin.

Likely causeCloudflare's global AOP client certificate is shared across accounts. It proves a request came from Cloudflare's network, not from one particular customer zone.

Safe checks

Review whether global, zone-level, or per-hostname AOP is configured.
Inspect the origin client-certificate trust and network policy.
Test Host and SNI restrictions at the origin.

WAF or rate limiting blocks legitimate users, APIs, or verified bots.

Safe checks

Review Security Events and sampled matches.
Use Cloudflare Trace for representative requests.
Compare request-rate analytics with the configured threshold and counting characteristics.

An Origin CA certificate expires without warning.

Likely causeCloudflare Origin CA does not currently send expiration notifications, and monitoring watched only the public edge certificate rather than the certificate served by the origin.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null 2>/dev/null | openssl x509 -noout -dates -fingerprint -sha256
Review origin certificate inventory and alert ownership.
Test renewal and reload in a canary.

Security notes

Do not attach raw tokens, private keys, full logs, or origin inventory to the public acceptance record.

Alternatives

Keep the zone in limited rollout while unresolved controls remain assigned and monitored.

Stop conditions

Do not declare completion based only on a green Cloudflare dashboard.

Finish line

Verification checklist

DNS and DNSSECdig A {{originHost}} +dnssec @1.1.1.1; dig DS {{zoneName}} +traceCloudflare authoritative answers validate through the parent chain and web names return edge addresses.

Strict TLS and origin denial

curl -sSI https://{{originHost}}{{healthPath}}; curl --resolve {{originHost}}:443:{{originIp}} -sSI https://{{originHost}}{{healthPath}} || true

Proxied request succeeds under Full (strict); unapproved direct request fails.

Cache isolation

curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{staticPath}}; curl -sSI https://{{originHost}}{{privatePath}}

Public immutable asset can HIT; private path never HITs and two sessions remain isolated.

Operational evidencecurl -sSI https://{{originHost}}{{healthPath}}Ray ID, cache status, strict TLS, security events, origin log, certificate expiry, and synthetic monitoring can be correlated.

Recovery guidance

Common problems and safe checks

The zone remains Pending and Cloudflare protections do not apply.

Safe checks

dig NS {{zoneName}} +short
dig +trace NS {{zoneName}}
Query the zone status with a Zone Read API token.

A hostname resolves to the wrong origin or disappears after import.

Likely causeAutomatic scanning missed a record, flattened a dependency differently, copied a stale value, or did not preserve a required DNS-only service record.

Safe checks

dig A {{zoneName}} @{{cloudflareNameserver}} +noall +answer
dig CNAME www.{{zoneName}} @{{cloudflareNameserver}} +noall +answer
Compare the signed pre-cutover DNS inventory.

Mail, SSH, FTP, or another non-HTTP service stops working.

Safe checks

dig MX {{zoneName}} +short
dig A mail.{{zoneName}} +short
Inspect proxy status for every A, AAAA, and CNAME record.

Visitors receive Cloudflare error 526.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} -showcerts </dev/null
curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Inspect the certificate SAN, validity, issuer, and served chain.

Visitors receive Cloudflare error 525 or TLS handshake failure.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null
Inspect origin TLS and reverse-proxy logs.
Temporarily test from an approved Cloudflare path without weakening public access.

ResolutionRepair origin listener, SNI, certificate chain, supported TLS, AOP ordering, and firewall path. Validate Full (strict) end to end in a canary hostname before production proxying.

The site enters an HTTP redirect loop or reports mixed content.

Safe checks

curl -sSIL https://{{originHost}}/
Inspect the Location chain and origin request headers.
Check application canonical URL and proxy-trust configuration.

The origin still responds when addressed directly from the internet.

Safe checks

curl --resolve {{originHost}}:443:{{originIp}} https://{{originHost}}/healthz
Test without the approved AOP client certificate from an external host.
Inventory historical and current DNS records for the origin IP.

After enabling Authenticated Origin Pulls, every request fails.

Safe checks

Inspect origin TLS client-verification logs.
Confirm the configured AOP mode in Cloudflare.
Verify the installed client CA fingerprint from the official Cloudflare source.

Global AOP is enabled but the team assumes only its zone can reach the origin.

Likely causeCloudflare's global AOP client certificate is shared across accounts. It proves a request came from Cloudflare's network, not from one particular customer zone.

Safe checks

Review whether global, zone-level, or per-hostname AOP is configured.
Inspect the origin client-certificate trust and network policy.
Test Host and SNI restrictions at the origin.

A cacheable asset always returns CF-Cache-Status DYNAMIC.

Safe checks

curl -sSI https://{{originHost}}{{staticPath}}
Use Cloudflare Trace for the exact URL.
Review Cache Rules order and origin response headers.

Authenticated or personalized content is served from cache.

Likely causeA broad cache-everything rule ignored cookies, Authorization, method, path, or origin `private` and `no-store` controls, causing multiple users to share a cache key.

Safe checks

Test two isolated sessions and one unauthenticated client.
Inspect CF-Cache-Status, Age, Cache-Control, Set-Cookie, and Vary.
Use Cloudflare Trace for account, admin, API, cart, and checkout paths.

A purge does not remove every cached variant.

Likely causeA custom cache key includes headers, cookies, query components, or other request properties that a dashboard single-file purge cannot reproduce.

Safe checks

Review custom cache-key settings.
Repeat requests with each known key variant.
Inspect Cloudflare Cache Rules and purge documentation.

Users receive stale or inconsistent content after deployment.

Likely causeEdge TTL exceeds the release strategy, browsers retain an overridden Browser TTL, cache keys omit version information, or purge completed for only one variant or hostname.

Safe checks

curl -sSI https://{{originHost}}{{purgeUrl}}
Compare Age, ETag, Last-Modified, Cache-Control, and CF-Cache-Status.
Test multiple regions or approved probes.

WAF or rate limiting blocks legitimate users, APIs, or verified bots.

Safe checks

Review Security Events and sampled matches.
Use Cloudflare Trace for representative requests.
Compare request-rate analytics with the configured threshold and counting characteristics.

DNSSEC-enabled clients return SERVFAIL after cutover.

Likely causeThe parent publishes a stale or wrong DS record, Cloudflare signs with another key, delegation includes unsigned providers, or a DNSKEY/DS change was made without waiting for TTLs.

Safe checks

dig {{zoneName}} DNSKEY +dnssec
dig {{zoneName}} DS +trace
dig A {{zoneName}} +dnssec @1.1.1.1

The registrar shows DNSSEC enabled but Cloudflare status is not confirmed.

Likely causeThe registrar does not consume CDS/CDNSKEY automatically, manual DS data was copied incorrectly, registry propagation is incomplete, or the zone is not fully delegated.

Safe checks

Compare Cloudflare's DS values with the parent DS response.
dig DS {{zoneName}} +trace
Check DNSSEC status in Cloudflare after the documented wait.

Cloudflare returns 522 or 523 and cannot reach the origin.

Likely causeThe origin address is wrong, routing or firewall rules exclude current Cloudflare IP ranges, the listener is down, an upstream blocks Cloudflare, or origin capacity is exhausted.

Safe checks

Verify the DNS record content in Cloudflare.
Check origin listener, routing, firewall, and load-balancer health.
Correlate Cloudflare Ray ID, timestamp, and origin logs.

Cloudflare returns 520 or 524 for application requests.

Safe checks

Correlate Ray ID and timestamp with origin access and error logs.
Test the same Host and SNI from the approved origin path.
Measure upstream processing time and response headers.

An Origin CA certificate expires without warning.

Likely causeCloudflare Origin CA does not currently send expiration notifications, and monitoring watched only the public edge certificate rather than the certificate served by the origin.

Safe checks

openssl s_client -connect {{originIp}}:443 -servername {{originHost}} </dev/null 2>/dev/null | openssl x509 -noout -dates -fingerprint -sha256
Review origin certificate inventory and alert ownership.
Test renewal and reload in a canary.

Operators expect a custom DNS TTL on an orange-clouded record.

Likely causeProxied records use Cloudflare's predefined Auto TTL, currently 300 seconds, and the value cannot be edited like a DNS-only record.

Safe checks

dig A {{originHost}} +noall +answer
Inspect the record proxy status.
Review resolver and browser caches separately.

After the procedure

Alternatives and next steps

Consider these alternatives

Use a publicly trusted automated origin certificate instead of Origin CA when direct browser recovery, non-Cloudflare health probes, or easy provider migration is an explicit requirement.
Use Cloudflare Tunnel or another private origin connectivity product when the application can avoid public origin ingress; validate product availability, identity, egress, HA, and recovery separately.
Use zone-level or per-hostname AOP with an account-controlled certificate where supported when global AOP's shared-certificate boundary is insufficient.
Keep dynamic HTML and APIs controlled by origin Cache-Control while caching only immutable versioned assets. This conservative profile is safer than broad cache-everything rules.
Use a second authoritative provider with Cloudflare's documented multi-signer DNSSEC design only when both providers, registrar, operations team, and plan support the full key and NS coordination.
Keep WAF and rate limiting in observation or challenge-oriented modes until Security Analytics and representative traffic establish safe scope and thresholds.

Operate it safely

Manage Cloudflare settings as reviewed infrastructure as code with scoped tokens, drift detection, protected state, and a break-glass dashboard path.
Add canary hostnames and synthetic probes for DNS, DNSSEC, edge certificate, Full (strict) origin TLS, AOP, direct-origin denial, cache isolation, WAF, rate limiting, and origin health.
Automate official Cloudflare IP-range updates with staged firewall tests, or adopt private origin connectivity after a separate availability and recovery review.
Create certificate inventory and expiry alerts for both edge and origin certificates; Origin CA expiration notifications must not be assumed.
Review Cache Rules and custom keys quarterly, prove precise purging, remove obsolete bypasses, and retest two-user isolation.
Review current plan entitlements before every WAF or rate-limiting change because fields, counts, periods, actions, logging, and account-level features vary.

Reference

Frequently asked questions

Is Full mode enough?

Full encrypts the origin leg but does not perform the same certificate validation as Full (strict). Use Full (strict) with a valid hostname-matching public or Origin CA certificate.

Can browsers connect directly to an Origin CA certificate?

Ordinary browsers do not normally trust Cloudflare Origin CA. Pausing Cloudflare or switching the record to DNS only can expose certificate errors, so prepare a public certificate or another tested recovery path.

Does global AOP prove that a request belongs to my account?

No. Its client certificate is shared across Cloudflare accounts and proves Cloudflare network origin. Use stricter AOP modes where supported or combine it with network, SNI, Host, and application controls.

Why might a bypassed response show DYNAMIC?

Cloudflare documents that a Cache Rule making content ineligible may return CF-Cache-Status DYNAMIC rather than a literal bypass status. Confirm rule evaluation with Trace and content isolation tests.

Are WAF and rate-limiting capabilities the same on all plans?

No. Rule counts, fields, counting characteristics, periods, actions, logs, account-level features, and advanced capabilities vary by plan and contract. Check current official availability before design.

Recovery

Rollback

Rollback the narrowest failing layer first. Disable a bad Cache, WAF, or rate rule; restore prior origin TLS or AOP; purge the exact cache scope; then consider proxy or nameserver reversal. Preserve DNSSEC chain validity and never expose an Origin CA-only origin to ordinary browsers without a prepared trusted certificate.

Freeze Cloudflare, registrar, and origin writes; record UTC time, zone version, Ray IDs, rule IDs, DNS answers, DS/DNSKEY, certificate fingerprints, origin logs, cache status, and current firewall.
Disable or revert the exact offending rule and verify service, cache isolation, and security before changing DNS.
Restore prior origin TLS, AOP trust, or firewall configuration through console/private access; keep direct internet access denied except for a time-bounded approved recovery path.
Purge only affected URLs or the documented key scope; broaden to prefix, host, tag, or full-zone purge only with origin-capacity approval.
If proxy bypass is unavoidable, install a publicly trusted origin certificate and reviewed temporary ingress first; do not gray-cloud an Origin CA-only hostname.
If delegation must return, restore {{previousNameserverOne}} and {{previousNameserverTwo}} while they still serve a complete zone, and coordinate DS/DNSKEY changes using TTL-aware official DNSSEC sequencing.
After recovery, revalidate DNS, DNSSEC, edge and origin TLS, mail, direct denial, cache isolation, security rules, monitoring, and revoke temporary access.

Evidence

Sources and review

Verified 2026-07-24Review due 2026-10-22