HowToCodePage

Choosing a CDN and connecting an origin

Comparing providers on the things that matter, DNS integration, origin configuration and host headers, TLS at the edge, staging domains, and validating the first deployment.

What to compare

DimensionWhy it decides the choiceHow to check
PoP coverageLatency for your actual audienceLook for a PoP in or near each user region
Cache controlWhether you can express the rules you needRead the cache-key and rule documentation
Request costThe line that grows fastestPrice per million requests, and what counts as one
Egress costDominates media-heavy sitesPrice per GB out, including from the CDN itself
Origin shieldReduces origin load and costIs it built in, and is it chargeable
Custom logicEdge rules versus full functionsRuntime limits and language support
Configuration as codeWhether you can review changesProvider API and a Terraform provider
Purge speed and granularityHow fast a mistake can be undoneURL, tag and everything - and propagation time
  • The cheapest per-GB rate is irrelevant if the provider has no cache-control features and you end up serving everything from origin.
  • Check what a request is. Some providers count each range request separately, which changes the cost of video completely.
  • Check the free tier limits before designing around them. A plan that has to change mid-quarter is a migration.

Connecting the origin

Setup order that avoids the classic mistakes

  1. add the zone or the hostname and let the provider verify ownership
  2. point the hostname at the origin and let the CDN issue a certificate
  3. test with a staging hostname first, e.g. cdn-stage.example.com
  4. only then move production DNS
  5. keep the previous DNS answer written down as the rollback

  Origin configuration that matters
    origin protocol        HTTPS, with a certificate the CDN will accept
    Host header            the origin's own hostname, or the CDN hostname,
                           whichever the origin's virtual host expects
    connect timeout        5-10 s, not the default 30
    read timeout           longer than the slowest legitimate response
# verify the CDN is in front and the origin is not exposed
curl -sI https://cdn-stage.example.com/ | grep -iE "server|via|x-cache|cf-cache-status|age"

# verify the origin responds correctly when addressed directly
curl -sI https://origin.example.com/ -H "Host: cdn-stage.example.com" | head -5

# confirm which certificate the edge presents
echo | openssl s_client -connect cdn-stage.example.com:443 -servername cdn-stage.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

The Host header is where most first deployments fail. The CDN forwards a Host value, the origin's virtual host does not match it, and the origin returns its default site or a 404 - with the CDN reporting a perfectly healthy fetch.

Validating the first deployment

  1. Confirm a cache hit on a static asset: request it twice and check that the second response is served from the edge with an Age header.
  2. Confirm HTML is not cached for long by accident. A stale homepage cached for a day is the most common launch incident.
  3. Confirm the origin is not reachable publicly. An exposed origin lets anyone bypass the CDN, the WAF and the cache.
  4. Confirm errors pass through correctly: a 404 from the origin must be a 404 at the edge, not a cached 200.
  5. Confirm TLS is valid for every hostname, including the staging one, and that the redirect from http to https works.
  6. Confirm logging is on and includes cache status, so you can answer questions later.
# first request (miss) and second request (hit) on the same asset
curl -sI https://cdn-stage.example.com/static/app.js | grep -iE "age|cache-control|x-cache"
curl -sI https://cdn-stage.example.com/static/app.js | grep -iE "age|cache-control|x-cache"

# a 404 must not be cached as a success
curl -sI https://cdn-stage.example.com/does-not-exist | head -3
⚠️
An origin that is still reachable from the public internet makes the CDN optional for anyone who knows the address. Restrict the origin to the CDN's published address ranges, or require a shared secret header the CDN adds and the origin enforces.

FAQ

Do I need the CDN's DNS?
Not always. For the apex you usually do, because the CDN needs to serve the root hostname and flattening requires control of the zone. For a subdomain a plain CNAME often suffices.
How do I test a CDN before moving production?
Use a staging hostname pointed at the same origin, validate certificates, caching and errors there, and switch production DNS only when that hostname behaves exactly as intended.

How a CDN serves your content Cache hierarchy: browser, edge and origin caches

Last refreshed 2026-09-18.