A global CDN with 200+ edge locations sounds great until an uncached product page drops and 40 different PoPs slam your backend simultaneously. I learned this during a launch when our database connection pool ran out in seconds—not from real user volume, but because every edge server independently asked for the exact same payload at the same time.
Here’s how to configure an origin shield (tiered caching) architecture to collapse those edge queries into a single regional caching layer before they ever reach your origin server.
The Architecture: Standard Edge vs Origin Shield
With standard CDN caching, every regional edge PoP talks straight to your backend whenever an asset expires or gets purged. If you’ve got 50 active PoPs globally, a single cache purge triggers 50 duplicate backend hits.
Tiered caching inserts an intermediate caching proxy between edge nodes and your origin server. The edge PoP queries the shield PoP first; if the shield has it, your origin server never sees the request.
- Standard CDN: Edge PoP (Tokyo) → Origin Server (Frankfurt)
- Tiered CDN: Edge PoP (Tokyo) → Shield PoP (Frankfurt) → Origin Server (Frankfurt)
This cuts your origin traffic down to a single high-bandwidth pipe and dramatically improves global cache hit ratios.
Step 1: Audit Origin Load and Baseline Metrics
Before tweaking CDN routing rules, check your access logs to see how bad redundant queries actually are.
Run this on your Nginx or Apache server to count unique CDN edge IPs hitting your origin right now:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 15If you see dozens of different CDN subnet IPs hitting the exact same URI within milliseconds, you’re eating pointless cache-fill overhead. To verify what your origin currently emits, check the response headers with curl:
curl -I https://example.com/api/products/featuredWatch for Cache-Control and Surrogate-Control. You need public caching headers that downstream shields can understand and store.
Step 2: Pick the Right Shield Location
Your origin shield PoP needs to be geographically right next to your origin server—ideally in the same metro area or cloud region. If your backend is in Frankfurt and you drop your shield in North America, you’ve just added a cross-Atlantic round trip to every single edge miss.
- Identify your origin’s primary region (e.g.,
eu-central-1/ Frankfurt). - Set the CDN edge PoP in that exact metro hub as your Shield/Upper-Tier node.
- Make sure CDN-to-origin keepalive connections are enabled so you aren’t paying the TLS handshake penalty on every query.
If you run a dynamic CMS, check our guide on how to configure CDN edge cache rules for WordPress cookies so dynamic user sessions bypass the shield cleanly without polluting the shared cache.
Step 3: Configure Tiered Caching in CDN Settings
Most commercial CDNs have a toggle for this. In Cloudflare, Fastly, or StackPath, look under Caching for Tiered Caching or Origin Shielding.
If you run your own intermediate Nginx reverse proxy layer as a shield, configure a dedicated cache zone in /etc/nginx/conf.d/shield.conf:
# Intermediate Shield Cache Configuration
proxy_cache_path /var/cache/nginx/shield_zone levels=1:2 keys_zone=shield_cache:50m max_size=10g inactive=24h use_temp_path=off; server { listen 443 ssl http2; server_name shield.example.com; ssl_certificate /etc/letsencrypt/live/shield.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/shield.example.com/privkey.pem; location / { proxy_pass https://backend_upstream; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Enable shield caching and collapsing proxy_cache shield_cache; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_lock on; proxy_cache_lock_timeout 5s; add_header X-Shield-Status $upstream_cache_status; }
}The proxy_cache_lock on; directive is here. It forces Nginx to hold duplicate requests and send only one upstream hit, implementing request collapsing to prevent cache stampedes.
Step 4: Update Origin Nginx Cache-Control Directives
Your origin backend needs to send explicit headers so intermediate tiers know how long they can hold the data. In your origin config (e.g., /etc/nginx/sites-available/example.com.conf), tune your headers:
server { listen 80; server_name example.com; # Static assets with long TTL location ~* .(css|js|jpg|jpeg|png|gif|ico|webp|woff2)$ { expires 30d; add_header Cache-Control "public, max-age=2592000, stale-while-revalidate=86400"; access_log off; } # Edge-cached dynamic fragments location /api/cacheable-feed { proxy_pass http://127.0.0.1:3000; # CDN/Shield caches for 5 mins, browser for 0 add_header Cache-Control "public, max-age=0, s-maxage=300"; }
}The s-maxage=300 directive tells both edge PoPs and the origin shield to cache the response for 300 seconds, while telling the client browser not to hold a local copy. For static assets, see how to configure immutable Cache-Control headers in Nginx to get maximum efficiency out of your shield.
Step 5: Lock Down the Origin to Shield IP Addresses
Once your shield sits between the edge and your origin, block everything else. You don’t want bots, scrapers, or direct scanner traffic bypassing the shield entirely.
Grab your provider’s IP ranges (cross-check against the MDN HTTP Cache-Control specifications and provider docs), then lock down Nginx:
# /etc/nginx/conf.d/origin-firewall.conf
# Allow only CDN Shield subnets
allow 198.51.100.0/24;
allow 203.0.113.0/24; # Deny everything else
deny all;For a complete breakdown of setting up this perimeter, check our guide on how to restrict Nginx access to CDN origin shield IPs.
Step 6: Verify Header Responses and Hit Ratios
Fire a couple of curl requests against a test endpoint to inspect the cache chain:
curl -svo /dev/null https://example.com/assets/app.js 2>&1 | grep -iE '(x-cache|x-shield|cf-cache-status)'On your first cold request, you’ll see a miss on both edge and shield:
< X-Cache: MISS
< X-Shield-Status: MISSOn a second request from a different edge location, the edge might miss locally, but the shield header should report a hit:
< X-Cache: HIT
< X-Shield-Status: HITGotcha: Cache Invalidation Latency
When you update a backend resource and purge it at the edge, verify whether your CDN’s API also purges the shield tier. I got bitten by this once: we purged the edge, but the shield tier kept serving stale assets back to the edge PoPs on their next fill request.
Always make sure your invalidation calls purge all tiers or explicit surrogate keys across your stack.
Frequently Asked Questions
What’s the difference between an origin shield and edge caching?
Edge caching puts assets as close to the user as possible across hundreds of PoPs. An origin shield is a consolidated, secondary caching layer sitting directly in front of your origin to prevent edge misses from overwhelming your backend.
Does tiered caching add latency to edge requests?
For an edge hit, latency is unchanged. For an edge miss, routing through the shield adds roughly 5ms to 15ms—which is far faster than making your backend render an un-cached database query.
Can I use origin shielding with authenticated or dynamic content?
No. Responses with Set-Cookie or Cache-Control: private, no-store pass straight through both the edge and the shield to your origin, exactly as they should.
How do I test if request collapsing works on the shield?
Hit an uncached endpoint with wrk or k6 sending 100 concurrent requests. Watch your origin logs—you should see exactly 1 request arrive while the other 99 wait for the shield lock to populate.
Next Steps
Now that your CDN origin shield and tiered caching layer are in place, make sure your SSL headers aren’t causing routing loops. Follow our walkthrough on how to fix SSL ERR_TOO_MANY_REDIRECTS on Nginx behind a CDN to keep your proxy headers cleanly aligned across every tier.
