What Is a CDN? How Content Delivery Networks Affect Website Availability

How a CDN Works — Edge Caching, PoPs, and Origin Pull

A CDN is a globally distributed network of proxy servers (Points of Presence, or PoPs) that sit between end users and your origin server, caching static content and proxying dynamic requests. When a user in Tokyo requests your site hosted in Virginia, their browser connects to the nearest CDN PoP (probably in Tokyo or Osaka) rather than routing 11,000 km across the Pacific to your origin. The CDN PoP either serves the request from its local cache (cache hit) or forwards it to your origin server and caches the response for subsequent requests (cache miss with origin pull).

CDNs operate in two distinct modes that have very different failure implications. In DNS-only mode (Cloudflare’s grey-cloud, also called DNS proxy disabled), the CDN acts only as a DNS nameserver and returns the origin’s real IP. User traffic goes directly to the origin without passing through the CDN. In this mode, a CDN outage does not affect user-facing availability. In full proxy mode (Cloudflare orange-cloud, Fastly, Akamai, CloudFront all operate this way by default), every HTTP/HTTPS request from every user passes through the CDN. The CDN’s network is in the critical path for 100% of traffic — making it a mandatory dependency for availability.

The CDN caches responses based on HTTP cache headers: Cache-Control: max-age=86400 instructs the CDN to serve the cached response for 24 hours without re-fetching from the origin. For dynamic content (API responses, user-specific pages), the origin typically sets Cache-Control: no-cache, private to prevent CDN caching — every such request must transit the CDN and reach the origin, so the CDN provides network optimization (TLS termination near the user, HTTP/3 support, TCP optimization) but not caching benefits for those requests.

How CDN Failures Cause Complete Website Outages (Even When Origin Is Up)

A CDN failure in full-proxy mode is functionally equivalent to your origin going down, from every user’s perspective — even if your origin server is fully operational and returning HTTP 200 to internal monitoring. The failure is in the network path that every user must traverse before their request reaches your origin. CDN failures produce distinct error signatures that differ from origin failures, and identifying the failure type determines where the fix lives.

CDN vs Origin: How to Distinguish a CDN Failure from an Origin Failure

The first diagnostic step for any 5xx error on a CDN-proxied site is determining whether the failure is in the CDN layer or the origin layer, because they require completely different fixes. A CDN failure requires action at the CDN (configuration rollback, waiting for provider recovery, activating a backup CDN). An origin failure requires action on your server (restarting processes, scaling resources, rolling back deployments). Confusing the two wastes critical time during an active incident.

The Major CDNs and Their Market Share (Cloudflare, Fastly, Akamai, AWS CloudFront)

CDN market share concentration directly determines the blast radius of a CDN outage — the more websites on a single CDN, the more users are affected when that CDN fails. The CDN market has consolidated significantly: four providers now account for the majority of CDN-proxied traffic on the internet. Understanding each provider’s architecture, PoP count, and historical incident record is essential for evaluating concentration risk when choosing infrastructure.

The practical risk calculation: if you use only one CDN, your site’s availability ceiling is bounded by that CDN’s availability. Cloudflare has historically achieved 99.99%+ availability for its network layer, but individual incidents demonstrate that even the best CDN can fail completely. For sites where downtime cost justifies the engineering investment, multi-CDN routing (using a DNS-based traffic manager to split traffic across two CDN providers) eliminates CDN provider as a single point of failure.

BGP Routing and CDN Anycast — Why CDN Outages Are Instant and Global

CDNs use anycast routing — a network topology where the same IP address is announced from hundreds of locations simultaneously via BGP, so each client’s request is automatically routed to the topologically nearest server. When you type 104.16.132.229 (a Cloudflare IP), your ISP’s router forwards your packet toward whichever Cloudflare PoP has the shortest BGP path from your location. You connect to the Singapore PoP if you are in Southeast Asia, the Frankfurt PoP if you are in Europe, and the Ashburn PoP if you are on the US East Coast — all using the same destination IP address.

The power of anycast is also its failure risk: when a BGP misconfiguration causes a CDN to withdraw its route announcements globally, every anycast PoP simultaneously becomes unreachable from every network path. The failure is not gradual — it happens in seconds as BGP route withdrawal propagates through the global routing table. There is no fallback because the failure is at the routing layer, below DNS. Users cannot reach the CDN’s IP addresses from anywhere in the world until the correct BGP routes are re-announced and propagated.

This is fundamentally different from a unicast (traditional) server failure, where only clients routing through that specific server are affected. Anycast scales performance globally but also scales failures globally — the same property that makes a CDN fast makes its failures instant and universal. The Cloudflare June 2022 incident affected users in every country simultaneously within seconds of the misconfiguration because BGP withdrawal propagated globally faster than the engineering team could detect and roll back the change.

How to Bypass a CDN to Test Origin Directly

Bypassing the CDN to query your origin server directly is the definitive test to determine whether a 5xx error is a CDN failure or an origin failure. If the origin returns HTTP 200 when queried directly but users see errors through the CDN, the CDN is the failure. If the origin also returns an error when queried directly, the origin is the problem regardless of what the CDN is doing.

To bypass the CDN, you need your origin server’s real IP address. Find it by: checking your hosting dashboard, running dig +short origin.yourdomain.com if you have a separate origin hostname, or looking in your CDN provider’s dashboard where your origin IP is configured. Once you have the origin IP:

When running the direct origin test, pay attention to the TLS certificate: if your origin uses a Cloudflare Origin Certificate (valid only for Cloudflare-to-origin connections), querying the origin directly will produce a TLS certificate error from your browser or curl. Use curl -k (insecure) to bypass the certificate check when testing origin connectivity directly, and understand that the certificate error does not indicate an application failure.

How DownCheck Distinguishes CDN-Layer from Origin-Layer Failures

DownCheck’s two-probe HTTP architecture is specifically designed to distinguish CDN-layer failures from origin-layer failures — a distinction that single-probe monitoring tools cannot make. The Railway HTTP probe sends requests from infrastructure that does not route through Cloudflare. The Cloudflare Edge probe sends a fetch() from a Cloudflare Worker, which routes through Cloudflare’s own edge network. Comparing the two probe results reveals exactly which layer is failing.

This 5-scenario matrix covers every meaningful failure state for a CDN-proxied website. No single-probe monitoring tool can distinguish row 2 (CDN-to-origin failure) from row 3 (CDN network failure) from row 4 (origin down) — all three look identical to a single external HTTP probe: the site returns errors. DownCheck’s multi-probe architecture surfaces the failure layer explicitly, reducing the time spent diagnosing the wrong system during an active incident.