Cloudflare, SSL, CDN, and DNS troubleshooting without guesswork

Cloudflare problems are easier to solve when DNS, proxying, TLS, application redirects, and caching are treated as separate layers. Changing several settings together can hide the actual cause and make rollback difficult.

Start with DNS authority

Confirm the active nameservers, requested record type, resolved address, proxy status, and propagation from more than one resolver. Remove conflicting records only after the intended origin and mail requirements are understood.

Query the authoritative chain

Start at the registrar delegation, then inspect the authoritative Cloudflare zone and finally query public recursive resolvers. Check A, AAAA and CNAME records as well as mail-related MX, SPF, DKIM and DMARC records before changing the zone. A correct record in an inactive DNS provider has no effect.

Time to live influences how long a previous answer may remain cached, but changing the TTL after a bad record is already cached does not recall that answer. Record the previous value, apply one change, and allow for negative caching when a name previously did not exist.

Understand the orange-cloud boundary

A proxied record returns Cloudflare addresses and sends supported traffic through the edge. A DNS-only record exposes the configured origin directly. Confirm that the hostname and port are eligible for proxying and that firewall rules allow Cloudflare to reach the origin. Do not disable the proxy permanently just to hide an origin configuration problem.

Direct-origin testing should use an authorized method that sends the real hostname and validates the intended certificate. Publishing a private origin address or broadly bypassing access controls creates a security issue. After testing, confirm the origin cannot be reached in an unintended way.

Verify origin TLS before tightening edge mode

Test the certificate presented by the origin, its hostname coverage and chain, and whether the web server selects the correct virtual host. Full strict mode requires a valid origin certificate; flexible TLS commonly creates redirect loops in applications that force HTTPS.

Trace redirects one hop at a time

Inspect each status and Location header from HTTP to the final canonical URL. The application must understand the original scheme through a trusted proxy signal, while ignoring spoofed forwarding headers from arbitrary clients. Configure one layer as the canonical redirect owner where possible so Cloudflare, Apache and PHP do not send competing rules.

Common loops include Flexible mode with an origin that forces HTTPS, a hostname toggle between www and apex, and an application that does not trust the proxy's HTTPS indication. Fix the scheme and host understanding instead of adding another redirect exception.

Separate cache behavior from application behavior

Inspect response headers, bypass rules, cookies, and cache keys. Purge only what changed. Dynamic account and admin routes should not be cached by a broad rule, while versioned static assets benefit from long-lived immutable caching.

Read cache evidence in the response

Compare the Cloudflare cache status, age, cache-control, vary and set-cookie headers on repeated requests. Test anonymous and authenticated states. A cache hit is useful only when the object is safe to share for that cache key. HTML containing a CSRF token, private message or user identity must not become a public edge response.

For assets with a content version in the filename or query, use a long immutable browser cache and publish a new URL when content changes. For database-driven pages, use revalidation or a short deliberate policy so newly published articles and projects appear. Purging the entire zone after every update is a sign that invalidation boundaries need improvement.

Cookies, rules and application routes

List cache, redirect, transform, WAF and origin rules in evaluation order. A broad wildcard can override a careful route-level policy. Test the admin path, logged-in routes, APIs, file downloads, contact submission and service worker separately. Methods other than safe reads should never be turned into cached content by a generic rule.

When debugging, capture a request identifier such as the Cloudflare Ray ID and the matching origin access entry. It helps distinguish an edge rejection from an origin-generated response. Do not disable the WAF globally; create the narrowest temporary diagnostic and remove it after the cause is understood.

Preserve observability and rollback

Configure trusted proxy headers so rate limiting and audit logs use the correct client IP. Record the previous DNS and SSL state, apply one bounded change at a time, and test both proxied and direct-origin behavior through an authorized diagnostic path.

Trust client IP headers only from the proxy

An origin that accepts a client-IP header from anyone lets attackers choose the address used by logs and rate limits. Restrict direct origin access where possible and configure Apache or the application to trust documented proxy networks. Preserve both the effective client and immediate peer in protected logs for investigation.

A layer-by-layer incident runbook

1. Write the affected hostname, path, client location, time and exact error.
2. Confirm registrar delegation and authoritative DNS answers.
3. Check proxy state and whether the edge can reach the intended origin.
4. Validate the edge certificate and the separate origin certificate.
5. Follow redirects and forwarded scheme/host handling.
6. Inspect WAF or rate-limit events and the matching origin log.
7. Compare cached and bypassed responses without exposing the origin publicly.
8. Apply one reversible change, verify it, and record the final state.

Post-change verification

• HTTP reaches one HTTPS canonical URL without a loop.
• The certificate is valid for every supported hostname.
• Static assets cache, while authenticated HTML, admin and write routes do not.
• Real client IPs appear correctly and cannot be spoofed directly.
• Mail and unrelated DNS records remain unchanged.
• IPv4 and IPv6 behavior match the actual origin configuration.
• The previous configuration and rollback decision are documented.

Cloudflare troubleshooting becomes predictable when each observation belongs to a layer. DNS selects the destination, the proxy accepts and filters traffic, TLS authenticates each connection, the origin generates the response, and caching decides whether that response is reused. Solve the first layer that is wrong and leave evidence for the next incident.