Glossary

Networking

CDN

A content delivery network, the geographically distributed cache layer that serves most large websites and decides at its edge how to treat your request.

Look up the address of almost any large website and the organisation that comes back is not the site. It is a content delivery network: a fleet of caching servers distributed across hundreds of cities, standing between visitors and the site's real machines. The origin server might live in one place; the CDN answers from wherever is closest to whoever is asking.

The mechanism is a reverse proxy operated at geographic scale. The site's DNS points at the CDN, routing steers each visitor to a nearby node, and that node serves cached copies of whatever it can, consulting the origin only on a miss or for content that cannot be cached. The visitor gets a response from a server a few hundred kilometres away instead of an ocean away, the origin sees a fraction of the traffic, and the physics of latency does the rest of the argument.

Two consequences matter for anyone working through proxies. The first is that WHERE you exit decides WHICH copy of a site you talk to. Requests from a German exit land on a European node, with that node's cache contents and freshness; the same URL fetched from an American exit is answered by different machines holding a possibly different cached state. Content can differ between the two for entirely mundane reasons, one edge holding a stale copy the other has already refreshed, before any deliberate regional variation is involved.

The second is that the CDN node is where a large share of the web's defences actually run. Rate limits, reputation checks, bot classification and challenges execute at the edge, on infrastructure the site rents, before the origin hears anything. When a heavily fronted site refuses you, the refusal usually happened in the CDN layer, which is also why the origin's operators sometimes genuinely cannot see the traffic you are asking them about.

Worth keeping separate: a CDN fronting a website is the site's choice and serves the site. It is unrelated to the proxies you configure for yourself, even though the machinery, caching reverse proxies, is family. You do not choose the CDN; you choose your exit, and the CDN chooses how to treat it.

Frequently asked questions

Why does a website's IP address belong to a CDN and not the site?

Because the site's DNS deliberately points at the network so every visitor lands on a nearby cache node. The origin's own address is not published and is often firewalled against direct traffic entirely. Looking up a fronted site tells you which delivery network it rents, and very little about where the site itself runs.

Does my proxy's location change what a CDN serves me?

It decides which edge node answers, and through that it can change what you receive. Different regions' nodes hold separately cached copies with their own freshness, so the same URL can return different content from different exits before any deliberate geo-targeting is involved. Anyone comparing pages across countries should assume some differences are cache artefacts rather than regional strategy.

Is a CDN the same thing as Cloudflare?

Cloudflare is one prominent operator of the pattern, alongside Akamai, Fastly, CloudFront and others. The pattern itself, distributed caching reverse proxies with security enforced at the edge, is what the term names. Sites frequently use one network for delivery and layer other services on top, so the brand and the mechanism are worth keeping distinct.

Why do CDN edges block scrapers?

Because the edge is where the site's protections are configured to run: reputation lookups, rate counting and bot classification execute on the node that receives you, before the origin is consulted. It is cheap for the site, since refused requests never touch their machines, and it is why a block on a fronted site can be instant, and invisible in the origin's own logs.

Back to the full glossary.

HProxy.

Ready when you are.Your dashboard is ten seconds away.

Get Startedor talk to us at support@hproxy.com
HProxy