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
- User requests
https://example.com/image.jpg - DNS resolves to the nearest CDN edge server
- Edge server checks if it has a cached copy
- HIT: Serve directly from edge (fast)
- 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)
| Test | Expected |
|---|---|
| Static asset first request | MISS (fetched from origin) |
| Static asset second request | HIT (served from edge) |
| Dynamic API response | MISS or BYPASS (not cached by CDN) |
| After CDN cache purge | MISS on first request |
Multi-Region Latency
Test from different geographic locations to verify acceptable response times:
| Tool | Description |
|---|---|
| WebPageTest | Run tests from 30+ global locations |
| Pingdom | Multi-location uptime and speed monitoring |
| KeyCDN Tools | Global latency and header checker |
curl --resolve | Test 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:
| Resource | First Request | Second Request | Cache-Control | Age |
|---|---|---|---|---|
| CSS | ||||
| JS | ||||
| Image | ||||
| HTML | ||||
| API |
Step 2: Multi-Location Testing
Use WebPageTest (webpagetest.org) to run tests from 3+ locations:
| Location | TTFB | FCP | LCP | Full Load |
|---|---|---|---|---|
| US East | ||||
| Europe | ||||
| Asia |
Step 3: Cache Purge Testing
- Note the current content of a cached resource
- Update the resource at origin
- Purge CDN cache (via provider dashboard or API)
- Request the resource — verify updated content is served
- 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