How a CDN works: request path, cache hits and origin misses

Receive: the client never aims at origin

Anycast and GeoDNS send the HTTPS request to a nearby point of presence and match it to a distribution. TLS 1.3, HTTP/3 or HTTP/2 and the certificate all terminate at the edge, not on the application VM.

That is why hiding the origin IP matters. If clients can still reach the origin directly, the CDN is optional and so is its protection.

The delivery model

Evaluate: cache policy decides the rest

The edge applies cache keys, TTLs, query-string behaviour, access policies and token authentication. A hit returns immediately. A miss may go through Origin Shield so duplicate fetches are collapsed.

Serve-stale can return an eligible expired object if the origin is down. That is a delivery decision, not an application retry loop.

Deliver: hits, misses and large files

Cached HTML, assets, images, video segments, and installers can be served from an edge when their cache and access policies allow reuse.

The origin still handles uncacheable traffic, new objects, revalidations, and misses. Measure that workload directly; no single hit-ratio target suits every application.

Change: purge, prefetch and deploys

A global cache is only useful if you can invalidate it. Purge by URL, file or directory when HTML, media or manifests change. Prefetch heroes or depots before a launch so the first users do not all miss together.

Hashed filenames skip purge. index.html and latest pointers do not. Put purge in CI.

Validate before production

Request one public URL twice from the same region and compare documented cache status with origin access logs. Then change a cache-key parameter deliberately: the result should match the policy you configured.

• Record the configuration and expected result before changing traffic.
• Keep evidence of the test and a working rollback for the previous behavior.