Unlike a scrubbing center, which traffic is diverted to only once an attack is detected, a CDN (content delivery network) sits in the path continuously and absorbs load by serving content from cache close to the user. That always-on absorption is one of the protections a thorough DDoS test is built to exercise. A CDN fronts the origin with caches at many points of presence, so a request for cacheable content is answered at the edge and never reaches the origin at all.
How a CDN absorbs load
The absorption comes from two properties working together. The first is distribution: anycast routing steers each client to a nearby point of presence, so a flood that would saturate one origin link is instead spread across dozens of edge locations, each eating a fraction of it. The second is caching: content that can be served from the edge is served from the edge, which means the origin's compute and its uplink only ever see the traffic the cache could not answer.
That is why the cache-hit ratio is the number that decides how much a CDN actually protects. A site that is mostly static images and pages served from cache pushes almost nothing back to the origin under load. A site that is mostly dynamic pushes almost everything back, and the edge fleet becomes a pass-through rather than a shield.
Larger CDNs add a tier between the edge and the origin, sometimes called an origin shield: a nominated cache that collects the misses from every point of presence so the origin sees one fetch instead of one per location. It raises the effective hit ratio and shrinks the origin-facing traffic, but it is a mitigation of the same weakness rather than a cure, because a request engineered to miss still misses at the shield and still reaches the origin.
Where the protection leaks
A CDN only protects what routes through it, and only absorbs what it can cache. Both halves of that sentence are attack surfaces. Cache-busting is the direct assault on the second half: an attacker appends a unique query string to every request, so each one is a cache miss the edge is obliged to forward, and the flood lands on origin compute despite a perfect edge configuration. Genuinely uncacheable paths do the same thing for free, because login, search, cart, and API endpoints are dynamic by nature and pass straight through to the backend.
The first half fails when traffic skips the edge entirely. If the origin's real address is discoverable, an attacker aims a flood straight at it and the whole edge is irrelevant, the origin IP exposure problem that no amount of caching addresses.
There is also a layer the CDN never sees at all. A CDN fronts HTTP, but the domain still has to resolve first, and unless the same provider runs the authoritative DNS, that lookup is a separate surface. An attacker who floods the authoritative nameservers can take the site dark without ever sending a request the cache could answer, because clients cannot reach the edge if they cannot resolve its address.
What a DDoS test measures
A test treats the CDN as two questions. First, does absorption hold when the attacker refuses to let it cache? It drives a flood of cache-busting query strings and dynamic requests and watches whether the cache-hit ratio collapses and the origin starts feeling the load, measuring where the pass-through ceiling actually sits rather than the ratio the CDN reports on friendly traffic.
Second, is the edge the only way in? A test attempts to reach the origin directly, off the edge, to confirm the origin refuses traffic that did not arrive from the CDN's published ranges. It also checks the controls most CDNs bundle into the same layer, the rate limiting and the WAF, because a CDN is usually the enforcement point for those too. Where a CDN sits among the other ways an edge absorbs and sheds volumetric load is laid out in how a CDN absorbs DDoS load at the cache.