Origin

The origin is the server or group of servers that holds the authoritative copy of your content. In a CDN, edge servers sit in front of it and cache its responses. So most requests are answered without the origin being touched at all. The origin is not the CDN's cache and not its edge network. It is the source those caches hold copies of. A cache miss is the moment an edge has to go back to it. It is also called the origin server. Some vendors call it the backend instead.

Almost everything else about origins follows from one fact: it is the only copy the CDN cannot reproduce. So the work around an origin has two goals: ask it less often, and stay serviceable when it cannot answer.

How it works

The origin is a defined HTTP role, not a CDN invention. RFC 9110 section 3.6: “The term "origin server" refers to a program that can originate authoritative responses for a given target resource.” What runs there can be an application server, an object-storage bucket, or a CMS. The CDN only needs it reachable over the protocol the CDN expects.

With a CDN in front, a request is handled in this order:

1. The request arrives at a nearby edge server, not at the origin.
2. If that edge holds a fresh stored response matching the request, it serves it. In that case the origin is never contacted. RFC 9111 section 4.2: a fresh response “can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.”
3. If no stored response matches, that is a cache miss. The edge then cannot satisfy the request on its own. RFC 9111 section 4.1: “Typically, the request is forwarded to the origin server, potentially with preconditions added to describe what responses the cache has already stored.”
4. The origin answers. The edge stores a copy if the response is cacheable, and returns it to the client. Later requests reuse the stored copy until it goes stale.

Every reusable response an edge serves from its own cache is traffic the origin never sees. The share of requests answered that way is the cache hit ratio. The traffic kept away from the origin is what “origin offload” means.

Why it matters for a CDN

A CDN exists to keep the origin out of the request path. Instead of one server answering every user, many edge machines answer from copies. The origin is left with only what the cache cannot absorb. Cloudflare's CDN reference architecture states it directly: “The origin server only is contacted when needed (when content is not cached or for dynamic non-cacheable content).”

That has two consequences, and they pull in different directions. First, capacity planning changes shape: the origin still needs headroom for the uncached share. The size of that share is set by your caching rules and your cacheable-content mix, not by your total traffic. There is no universal offload percentage to design against. Measure your own.

Second, the origin remains the one component the CDN cannot stand in for. When it is unreachable, a cache is sharply limited in what it may serve instead. RFC 9111 section 4.2.4: “A cache MUST NOT generate a stale response unless it is disconnected or doing so is explicitly permitted by the client or origin server”. One example is the RFC 5861 stale controls. The stale-if-error directive there says a stale response “MAY be used to satisfy the request” when an error occurs. That means a 500, 502, 503 or 504. Surviving an origin outage is therefore something you arrange beforehand, with those directives and with failover to a second origin. It is not a default the cache supplies for you.

What CDNs do

• AWS CloudFront treats the origin you configure as the store of “the original, definitive version of your objects”. On a miss it “retrieves it from an origin that you've defined — such as an Amazon S3 bucket, a MediaPackage channel, or an HTTP server.” Its optional Origin Shield adds a caching layer through which CloudFront's other caching layers reach the origin. As a result, requests for the same object are consolidated, “resulting in as few as one request going to your origin.” Two qualifications come from the same page. Requests made in the same region as your origin bypass Origin Shield. Also, “you incur additional charges for using Origin Shield.”
• Cloudflare is a reverse proxy: it “receives requests from clients and proxies the requests back to the customer's origin servers,” so “every request traverses through Cloudflare's network before reaching the customer's network.” Edge nodes “cache content from the origin server and are able to respond to requests via a cached copy,” which is why an uncached or non-cacheable request costs a return trip to the origin. Tiered Cache makes some data centres upper tiers for others to “minimize requests to customer origins”. By Cloudflare's own documentation it is “disabled by default,” and the topologies you can pick depend on the plan.
• Fastly calls the origin a host or backend: “A host, also referred to as a backend or origin, is a web server or cloud service that contains the content of your website or application,” and it must be added to the service configuration before Fastly can cache anything. Shielding designates one POP so that “requests to your origin will come from a single POP”. If that shield POP is inaccessible for a request, the request “will go directly from the edge node to your origin server, bypassing the shield.” Health checks gate traffic: “If an origin server is marked unhealthy due to health checks, Fastly will stop attempting to send requests to it,” and once every origin is unhealthy Fastly returns 503 unless configured otherwise. A service can hold up to five origin servers by default. Fastly's documentation says to contact them to enable more, so treat five as a default ceiling rather than a hard limit.

Watch out for

• Many edges can miss the same object at the same time. Each POP is independent, so several can forward the same request at once. Fastly: “any time it doesn't have a cached version of the requested resource, it will make a request directly to your origin, even if another POP may be in the process of making the same request.” That is how an expiring hot object turns into a cache stampede, and it is what a shield or mid-tier layer exists to absorb.
• Origin failover is method-scoped. CloudFront “fails over to the secondary origin only when the HTTP method of the viewer request is GET, HEAD, or OPTIONS,” and does not fail over for POST, PUT and the rest. The same page adds that it will not fail over at all if OPTIONS is not among the cached HTTP methods in your cache behaviour. A failover origin does not make writes highly available.
• Health checks are themselves origin traffic. Fastly runs them “based on the Check frequency setting you select,” with “roughly one health check per Fastly POP per period”. So the load scales with the number of probing locations, not with one prober. Pick an interval on that basis.
• An origin reachable without the CDN is a hole through it. Traffic that reaches the origin directly skips the cache and every protection in front of it. So the origin should accept the CDN's traffic and little else. Cloudflare's Authenticated Origin Pulls is the mTLS form of this: it “helps ensure requests to your origin server come from the Cloudflare network.”
• “Origin” has a second, unrelated meaning. RFC 9110 section 4.3.1: “The "origin" for a given URI is the triple of scheme, host, and port.” That triple is the security identity browsers enforce rules such as CORS against. It is not the source server discussed here, and the two are routinely confused.

Best practice

• Send explicit freshness information so an edge can answer without asking the origin. Per RFC 9111 section 4.2, the primary mechanism is an origin-supplied expiration time, “using either the Expires header field or the max-age response directive”. For shared caches such as a CDN, s-maxage (RFC 9111 section 5.2.2.10) overrides both. See Cache-Control and TTL.
• Track the cache hit ratio. Then go after the specific requests that keep reaching the origin. That remainder is the load the CDN did not remove. It is usually a small number of URL patterns or a Vary or cookie rule, not a mystery.
• Keep edge-to-origin connections persistent. RFC 9112 section 9.3: “HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection,” so a miss can reuse a connection that is already open instead of establishing a new one. See Keep-Alive. The CloudFront origin_keepalive_timeout setting and the nginx upstream keepalive directive in the code examples below are the two concrete forms.
• Put an origin shield or mid-tier cache in front of the origin. This lets concurrent misses from many POPs converge on far fewer origin requests.
• Add origin health checks so a failing origin is detected before users report it. Size their frequency so the monitoring does not become the load you set out to remove.
• Decide the origin-down behaviour in advance: a secondary origin, and where the content tolerates it, explicit permission for the cache to serve stale rather than to fail.