When a CDN point of presence (POP) doesn't have a requested resource cached, it retrieves the resource from your origin server — this is an origin fetch. An origin fetch also occurs when you run a prefetch task. Alibaba Cloud CDN gives you precise control over how POPs communicate with your origin: which protocol to use, how to rewrite URLs and headers, how long to wait before timing out, and how to route requests across multiple origins.
How it works
A client (such as a browser) sends a request to a CDN POP. The request URL points to the CDN accelerated domain name.
The POP checks its cache. If the resource is cached, the POP returns it directly to the client.
If the resource is not cached, the POP sends an origin request to the origin server based on configured origin policies.
The origin server returns the resource based on the URL and parameters.
The POP caches the resource for subsequent requests.
The POP returns the resource to the client, completing the request.
Origin fetch settings
Private OSS bucket access
If your origin server is Alibaba Cloud Object Storage Service (OSS) and the bucket access control list (ACL) is set to private, CDN POPs cannot fetch resources without explicit access permissions. Grant Alibaba Cloud CDN the required permissions so POPs can retrieve resources from the private bucket.
Grant Alibaba Cloud CDN access permissions on private OSS buckets
Origin protocol
Specifies the protocol POPs use when sending origin requests. Three options are available:
| Option | Behavior |
|---|---|
HTTP | POPs always use HTTP for origin requests |
HTTPS | POPs always use HTTPS for origin requests |
Follow | POPs use the same protocol as the incoming client request |
Use Follow when your origin supports both HTTP and HTTPS and you want to preserve the client's protocol end-to-end. Use HTTPS to enforce encrypted communication between POPs and your origin regardless of client protocol.
Origin host
The origin host header specifies which site on the origin server a POP requests. This matters when multiple websites are hosted on the same origin server — without the correct host header, the origin server cannot route the request to the right site.
Configure a global default origin host, or specify different origin hosts for individual origin servers.
Origin URL rewrite
Use origin URL rewrite when the resource path on your origin server has changed but you need to keep client-facing URLs unchanged. When a POP fetches the resource, it rewrites the requested URL path to the new path based on your configured rules — without the client being aware of the change.
Origin parameters
Configure rules to rewrite query parameters in origin requests. Options include:
Delete all parameters
Keep only specific parameters
Delete specific parameters
Use this feature to strip tracking or analytics parameters before they reach your origin, or to normalize URLs for better cache efficiency.
Origin request headers
Add, modify, or delete HTTP request headers that POPs send to your origin server during origin fetch. Common use cases include:
Identifying CDN traffic: Add a custom header to distinguish CDN origin requests from direct traffic, helping you detect cache bypasses or attribute traffic sources when using multiple CDN providers.
Passing client context: Forward user-related information (such as the client's geographic region) to the origin so your application can personalize responses.
Controlling origin access: Configure your origin to reject requests that lack a specific secret header, preventing direct access that bypasses CDN.
Enabling cross-origin resource sharing (CORS): Add the
Originheader to origin requests when clients that don't support CORS need to access cross-origin resources.
Origin SNI and Common Name whitelist
These settings apply when the origin protocol is HTTPS.
Origin Server Name Indication (SNI) specifies the domain name a POP sends during the TLS handshake. Configure this when multiple HTTPS sites with different certificates share the same origin IP address — without the correct SNI, the origin server returns the wrong certificate and the TLS handshake fails.
Common Name whitelist adds a verification step after the TLS handshake: the POP checks that the Common Name or Subject Alternative Name (SAN) in the origin certificate matches the configured SNI. Enable this to guard against certificate substitution and man-in-the-middle attacks on the POP-to-origin connection.
Origin response headers
Configure rules to add, modify, or delete HTTP response headers that the origin server returns, before the POP forwards the resource to the client. For example, add cross-origin response headers such as Access-Control-Allow-Origin when the origin doesn't include them.
301/302 redirect
By default, when your origin returns a 301 or 302 redirect, the POP passes the redirect response directly to the client. The client then sends a new request to the redirected address, resulting in an additional round trip.
Enable the 301/302 redirect feature to have POPs follow the redirect and fetch the resource from the redirected address on behalf of the client. This eliminates the extra client round trip and reduces total request latency.
Timeout period
Sets the maximum time a POP waits to establish a connection with the origin server and receive a complete response. If the origin does not respond within this period, the POP disconnects and returns a 5xx error to the client.
Set a timeout that matches your origin's typical response time. A shorter timeout fails fast and prevents clients from waiting indefinitely for a slow origin. A longer timeout accommodates origins that generate large or complex responses.
Advanced origin
Route different requests to different origin servers based on conditions such as request parameters or client IP addresses. Use advanced origin when you have multiple origin servers and need fine-grained control over which origin handles which requests — for example, routing API traffic to one server and static assets to another.
Origin fetch over IPv6
If your origin server supports IPv6, enable origin fetch over IPv6 so POPs prioritize the IPv6 protocol when connecting to the origin. Configure automatic fallback to IPv4 to maintain service availability if an IPv6 connection fails.