How CDNs Work

A Content Delivery Network (CDN) is a distributed network of servers that caches and delivers content from locations (edge servers or PoPs — Points of Presence) close to end users. Popular CDN providers include Cloudflare, AWS CloudFront, Fastly, and Akamai.

When a user in Tokyo requests a file from a website hosted in New York, without a CDN the request travels across the Pacific Ocean (~150ms round-trip). With a CDN, the file is served from a Tokyo edge server (~5ms).

CDN Request Flow

  1. User requests https://example.com/image.jpg
  2. DNS resolves to the nearest CDN edge server
  3. Edge server checks if it has a cached copy
  4. HIT: Serve directly from edge (fast)
  5. MISS: Fetch from origin, cache, then serve (first request is slower)

What QA Should Test

CDN Cache Behavior

Verify cache headers in responses:

# Check CDN cache status
curl -I https://example.com/style.css

# Look for these headers:
# CF-Cache-Status: HIT (Cloudflare)
# X-Cache: Hit from cloudfront (AWS)
# X-Cache-Status: HIT (Fastly/Nginx)
# Age: 3600 (seconds since cached)
TestExpected
Static asset first requestMISS (fetched from origin)
Static asset second requestHIT (served from edge)
Dynamic API responseMISS or BYPASS (not cached by CDN)
After CDN cache purgeMISS on first request

Multi-Region Latency

Test from different geographic locations to verify acceptable response times:

ToolDescription
WebPageTestRun tests from 30+ global locations
PingdomMulti-location uptime and speed monitoring
KeyCDN ToolsGlobal latency and header checker
curl --resolveTest specific edge server IPs

Geo-Restricted Content

If your application restricts content by region (video licensing, regulatory compliance):

  • Users in allowed regions can access content
  • Users in restricted regions see appropriate message (not an error)
  • VPN users are handled correctly (block or allow based on policy)
  • Geo-detection uses the correct IP (not internal proxy IPs)

Geo-Based Routing

Applications that route users to regional servers:

  • US users go to us.api.example.com
  • EU users go to eu.api.example.com
  • Data sovereignty: EU user data stays in EU data centers
  • Failover: if EU region goes down, traffic routes to US (or shows maintenance)

CDN Failover

Test what happens when the CDN is unavailable:

  • Does the site fall back to origin server?
  • Is the fallback transparent to users?
  • Are error pages served correctly when both CDN and origin are down?

Exercise: CDN and Geo-Distribution Audit

Step 1: CDN Cache Verification

Use curl or browser DevTools to check CDN behavior:

# First request (should be MISS)
curl -I https://your-site.com/assets/main.css

# Second request (should be HIT)
curl -I https://your-site.com/assets/main.css

# Check Age header (seconds since cached)
curl -I https://your-site.com/assets/main.css | grep -i age

Document:

ResourceFirst RequestSecond RequestCache-ControlAge
CSS
JS
Image
HTML
API

Step 2: Multi-Location Testing

Use WebPageTest (webpagetest.org) to run tests from 3+ locations:

LocationTTFBFCPLCPFull Load
US East
Europe
Asia

Step 3: Cache Purge Testing

  1. Note the current content of a cached resource
  2. Update the resource at origin
  3. Purge CDN cache (via provider dashboard or API)
  4. Request the resource — verify updated content is served
  5. Request from a different region — verify updated content globally
Solution: Common CDN Testing Issues

Issue 1: CDN caching user-specific content API response with user data was cached by CDN and served to other users. Fix: Add Cache-Control: private or CDN-Cache-Control: no-store to authenticated responses.

Issue 2: Cache purge not propagating globally After purging CDN cache, updated content was available in US but still stale in Asia (different edge PoP). Fix: Verify purge propagation across all regions, not just the nearest one.

Issue 3: Geo-restriction bypass with cached content Restricted video was cached at an edge server in an allowed region. Users in restricted regions connecting to that edge server could access the content. Fix: Implement geo-checking at the edge, not just at origin.

Issue 4: Mixed HTTP/HTTPS on CDN Origin served HTTPS but CDN was configured to also serve HTTP, causing mixed content warnings. Fix: Configure CDN to redirect all HTTP to HTTPS.

Issue 5: Stale cache after deployment New version deployed to origin but CDN continued serving old files for hours. Fix: Implement automatic cache purge as part of deployment pipeline.

Key Takeaways

  • CDN testing requires verifying cache behavior (HIT/MISS), multi-region latency, and content consistency
  • Always check CDN-specific response headers (CF-Cache-Status, X-Cache, Age) to understand caching behavior
  • Test from multiple geographic locations — a site may work perfectly locally but fail in other regions
  • Authenticated and user-specific responses must not be cached by CDN
  • Include CDN cache purge in your deployment pipeline to prevent stale content
  • Geo-restricted content must be enforced at the edge, not just at the origin server