CDN Troubleshooting: Diagnosing Cache Misses, Errors, and Latency
CDN problems are uniquely frustrating because the symptoms appear on the client side while the causes span multiple systems: CDN configuration, origin server, DNS, SSL certificates, and browser behavior. A cache miss could be caused by a response header from your origin, a CDN rule you forgot about, or a Vary header you did not realize was being set. Systematic diagnosis is the only way to cut through the ambiguity. For a comprehensive overview, see our guide on CDN Monitoring and Observability: Metrics That Matter — FlyFish NWA.
This guide covers the most common CDN issues, their root causes, and the diagnostic steps to resolve them. Each section follows a decision-tree approach: observe the symptom, check the most likely cause first, then work through alternatives until you find the answer.
How Do You Diagnose Persistent Cache MISSes?
A cache MISS on every request means the CDN is fetching from origin every time instead of serving cached content. This is the most common CDN performance problem and usually has a simple cause.
Step 1: Check origin response headers. Run curl -I https://yoursite.com/page and examine the Cache-Control header. If it contains no-store, no-cache, or private, the origin is telling the CDN not to cache. This is the cause in 60% of cache MISS investigations.
Step 2: Check for Set-Cookie. Most CDNs refuse to cache responses that include a Set-Cookie header, because caching would serve one user's cookies to another user. If your origin sets cookies on every response (common with session-based frameworks), the CDN will MISS on every request. The fix: suppress Set-Cookie on cacheable responses or configure the CDN to ignore Set-Cookie for static content.
Step 3: Check the Vary header. A Vary: * header tells the CDN that the response varies by everything, effectively disabling caching. A Vary: Cookie or Vary: Authorization creates a separate cache entry for each unique cookie or auth token value, resulting in effectively zero cache hits. Review Vary headers carefully—they should include only headers that genuinely affect the response content. See Cache Key Design for proper Vary usage.
Step 4: Check cache key collisions. If the cache key includes volatile parameters (random query strings, session tokens in the URL, timestamp parameters), every request generates a unique cache key. Solution: configure the CDN to strip irrelevant query parameters from the cache key.
Step 5: Check CDN configuration. Review your CDN's page rules, cache rules, or behavior settings. A rule that matches too broadly (e.g., "bypass cache for all URLs containing /api/") might be catching URLs you intended to cache. CDN log analysis helps identify which rule caused the bypass.
How Do You Fix 502 and 504 Gateway Errors?
A 502 Bad Gateway means the CDN received an invalid response from origin. A 504 Gateway Timeout means the CDN received no response within the timeout period. Both indicate origin-side problems.
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
502 diagnosis decision tree:
- Is the origin running? SSH to the origin and check the web server process. If it is down, restart it and investigate the cause (OOM kill, crash, deployment issue).
- Can the origin be reached from the CDN? The CDN connects to the origin over the internet. If your origin firewall blocks CDN IP ranges, the connection fails. Add CDN edge IPs to the origin allowlist.
- Is the origin SSL certificate valid? If the CDN connects to origin over HTTPS (Full or Full Strict mode), an expired or self-signed origin certificate causes a 502. Check certificate expiry with:
openssl s_client -connect origin:443. - Is the origin returning a valid HTTP response? Origin errors (500, application crashes) may present as CDN 502s. Check origin access and error logs for the same timestamp.
504 diagnosis:
A 504 means origin response time exceeded the CDN's timeout (typically 30–100 seconds). Common causes: slow database queries, external API calls blocking the response, application deadlocks, or resource exhaustion (CPU/memory). Check origin performance metrics and slow-query logs for the timeframe when 504s occurred.
Intermittent 502/504s. If errors occur sporadically rather than consistently, suspect: origin auto-scaling lag (new instances not ready before CDN timeout), DNS resolution issues (origin hostname resolving to a failed backend), or network path issues between CDN PoP and origin (traceroute from the affected PoP region). Use RUM data to correlate error patterns with geography and time.
What Causes High TTFB and How Do You Reduce It?
High Time to First Byte (TTFB) on a CDN-served response defeats the purpose of the CDN. Diagnosis starts by determining whether the slowness is on the CDN side or the origin side.
Step 1: Check cache status. If the response is a cache MISS, the high TTFB is your origin response time, not a CDN problem. Solve the cache miss first (see above), and TTFB will drop to CDN-edge latency (typically 5–50 ms).
Step 2: Check cache HIT with high TTFB. If the response is a cache HIT but TTFB is still high (over 100 ms), the issue is network latency between the user and the CDN edge, or CDN-side processing overhead. Verify which PoP served the request (look for the CDN's server header or CF-Ray header). If the PoP is geographically distant from the user, there may be a DNS routing issue.
Step 3: DNS diagnosis. Run dig +short yoursite.com to see which CDN edge IP is returned. Then geolocate that IP. If a user in Tokyo is being routed to a US PoP, the DNS is misconfigured. Common causes: EDNS Client Subnet (ECS) not supported by the resolver, or the CDN's DNS load balancing is not properly configured. See CDN DNS Resolution for how DNS routing works.
Step 4: TLS overhead. On the first connection, TLS handshake adds 1–2 round trips of latency. This is normal and unavoidable for the first request. Subsequent requests on the same connection reuse the TLS session. If every request shows TLS overhead, connection keep-alive may be disabled. Verify HTTP/2 is enabled (which multiplexes requests over a single connection).
| Symptom | Likely Cause | Fix |
|---|---|---|
| High TTFB, cache MISS | Origin response time | Fix caching or optimize origin |
| High TTFB, cache HIT | Wrong PoP or edge processing | Check DNS routing, disable unneeded edge transforms |
| High TTFB, first request only | TLS handshake + DNS resolution | Enable 0-RTT, HTTP/2 push, DNS prefetch |
| High TTFB, specific regions | No nearby PoP or DNS routing issue | Verify PoP coverage, check EDNS support |
How Do You Debug CDN Redirect Loops?
Redirect loops manifest as "ERR_TOO_MANY_REDIRECTS" in the browser. They are almost always caused by a conflict between CDN and origin redirect rules.
The classic HTTP-HTTPS loop. The most common redirect loop: CDN is configured to redirect HTTP to HTTPS (good), but the CDN connects to origin over HTTP. The origin also redirects HTTP to HTTPS. The CDN sends an HTTP request to origin, origin responds with a 301 to HTTPS, CDN follows the redirect to itself, which sends another HTTP request to origin, creating an infinite loop.
Fix: Set the CDN-to-origin connection to HTTPS. In Cloudflare, this is the "SSL/TLS encryption mode" setting—change from Flexible (CDN-to-origin over HTTP) to Full or Full Strict (CDN-to-origin over HTTPS). In CloudFront, set the origin protocol policy to "HTTPS Only."
www/non-www redirect loop. CDN redirects example.com to www.example.com, but the www zone has a rule redirecting back to example.com. Or both zones redirect to each other. Fix: ensure only one direction is configured, and the target zone does not redirect back.
Diagnosis tool: Use curl -L -v --max-redirs 10 http://yoursite.com 2>&1 | grep "Location:" to trace the redirect chain and identify where the loop occurs. Each Location header shows the redirect target; the loop becomes visible when targets alternate.
How Do You Resolve Stale Content After a CDN Purge?
You purged the cache, but users still see old content. This is a layered caching problem—the CDN cache is only one of several caches between origin and browser.
Check 1: Did the purge actually complete? Verify via the CDN dashboard or API response. Purges are asynchronous—they can take 2–30 seconds to propagate across all edge PoPs.
Check 2: Browser cache. The user's browser may have cached the old content locally. A CDN purge does not clear browser caches. If Cache-Control: max-age=86400 was set, the browser will serve its local copy for up to 24 hours without contacting the CDN. Test with an incognito window or a different browser.
Check 3: Multiple cache layers. Your stack may have additional caches between the CDN and origin: a reverse proxy (Varnish, Nginx), an application-level cache (Redis, Memcached), or a full-page cache plugin (WordPress caching plugins). Each layer must be purged independently. Use CDN Cache Invalidation techniques for multi-layer purge orchestration.
Check 4: URL accuracy. CDN purges are URL-exact. If you purged https://example.com/page but users are requesting https://example.com/page?ref=email, the cached version with the query string was not purged. Either purge with wildcards (if supported) or strip query strings from the cache key.
Check 5: Edge caching of redirects. If the CDN caches 301 redirects, purging the target URL does not purge the redirect. Users following the cached redirect to an old destination will see stale content even though the target has fresh content.
What Diagnostic Tools Should Every CDN Operator Know?
curl -I (HEAD request). The most essential CDN debugging tool. Shows response headers without downloading the body. Look for: cache status, Cache-Control, Age, Vary, Server, and CDN-specific headers (CF-Ray, X-Amz-Cf-Pop, X-Cache).
curl -v (verbose). Shows the complete request-response exchange including DNS resolution, TCP connect, TLS handshake, and timing. Invaluable for diagnosing connection-level issues.
dig (DNS lookup). Verifies DNS resolution: dig +short yoursite.com shows which CDN IP addresses are returned. Compare from different resolvers: dig @8.8.8.8 yoursite.com vs dig @1.1.1.1 yoursite.com to detect DNS inconsistencies.
traceroute/mtr. Traces the network path from your location to the CDN edge. Identifies network-level issues: packet loss at specific hops, unexpected routing through distant regions, and ISP-level problems. Use mtr -w yoursite.com for a combined traceroute and ping analysis.
WebPageTest. Provides CDN-aware performance analysis from 40+ global locations. The waterfall view shows per-resource timing, and the response headers view shows cache behavior for every request on the page.
Combine these tools with CDN log analysis for server-side visibility, and systematic CDN testing to prevent issues before they reach production.