CDN:FAQ

What is the cache eviction mechanism?

If a resource cached on a CDN POP is unpopular (meaning it is infrequently accessed by clients on the same CDN POP), it is likely to be overwritten by more popular resources on the CDN POP before its cache expires.

What is the default cache rule?

When a CDN POP receives a file from an origin server, it applies caching rules in the following priority order. A lower number indicates higher priority.

1. If the origin responds with Pragma: no-cache, Cache-Control: no-cache (or no-store, or max-age=0), CDN follows the origin's directive and does not cache the resource.

2. The cache TTL or status code TTL configured in the CDN console.

   When a request matches multiple rules, only one rule takes effect. Priority is determined first by weight, then by creation time. A higher weight indicates higher priority. For rules with the same weight, the rule created earlier takes effect.

3. Cache headers from the origin server, evaluated in this order: Cache-Control > Expires > Last-Modified > ETag.

   • If the origin response includes Cache-Control with max-age or s-maxage greater than 0, that value determines the cache expiration time. If both are present, s-maxage takes precedence. Example: Cache-Control: max-age=3600.

   • If the origin response has no Cache-Control but includes Expires, the Expires header determines the TTL. Example: Expires: Tue, 25 Nov 2031 17:25:43 GMT.

   • If the origin response has neither Cache-Control nor Expires but includes Last-Modified, CDN calculates the cache duration as (current time - Last-Modified) x 0.1, capped between 10 seconds and 3,600 seconds. If the calculated value is less than 10 seconds, the cache duration is 10 seconds. If the value is greater than 3,600 seconds, the cache duration is 3,600 seconds.

   • If Cache-Control, Expires, and Last-Modified are all absent but ETag is present, the resource is cached for 10 seconds.

4. If the origin response includes none of these headers, the resource is not cached.

Tip: Use Cache-Control: max-age rather than Expires to control cache duration. max-age is evaluated with higher priority and avoids clock-skew issues caused by absolute expiry timestamps.

How do I check whether a resource is cached?

Check the following HTTP response headers:

To view these headers, use one of the following methods.

Method 1: Use browser developer tools (such as Chrome DevTools)

Method 2: Use the curl command

curl "http://example.com/path/to/response.html" -v

How do I fix a low cache hit ratio caused by variable URL parameters?

The most common cause is that the Ignore Parameters feature is not enabled. When URLs contain variable query parameters after ?, each unique URL is treated as a separate resource — even if the content is identical — which multiplies origin fetches and lowers the cache hit ratio.

Enable the Ignore Parameters feature to treat URLs with different parameter values as the same cacheable resource. For details, see Low cache hit ratio due to variable parameters in URLs.

How do I prevent specific files from being cached?

Set the cache TTL to 0 for the target directory, file path, or file type. In the CDN console, configure the following fields:

For details, see Configure CDN cache expiration time.

Why is content stale even though cache TTL is set to 0?

Setting the cache TTL to 0 instructs every request to fetch the latest content from the origin. If you still see stale content, check these causes in order:

1. Browser cache: The browser may have cached an older response. Test in a private browsing window or clear the browser cache.

2. Configuration propagation delay: The TTL=0 setting takes time to propagate to all CDN POPs. POPs that have not received the update continue serving cached content in the meantime.

3. Origin server cache: The origin may have its own caching layer. If the origin cache is not refreshed, CDN POPs pull stale content during an origin fetch.

4. POP cache purge delay: Resources cached before the configuration change are not immediately cleared. Manually purge the cache to force POPs to fetch the latest content. See Refresh and prefetch resources.

Do CDN POPs update automatically when a file changes on the origin?

No. CDN POPs do not update cache automatically or in real time after a file changes on the origin server. Cache updates are governed by the configured cache TTL — until the TTL expires, POPs continue serving the previously cached version.

To serve updated content immediately, purge the cache manually:

• Console: See Refresh and prefetch resources.

• API: See RefreshObjectCaches.

To reduce how often this happens, set a cache TTL appropriate for how frequently your content changes. See Configure CDN cache expiration time.

What factors lower the cache hit ratio?

For a comprehensive guide, see Improve the CDN cache hit ratio.

How do I troubleshoot a low cache hit ratio?

A low cache hit ratio slows content delivery and increases load on your origin server. For a structured troubleshooting walkthrough, see Troubleshoot a low CDN cache hit ratio.

How do I configure global cache settings?

To apply a cache TTL across all paths, set Type to Directory and enter / in the Object field. This matches every path on the domain. For details, see Configure CDN cache expiration time.

Why did my cache configuration not take effect?

The most common reasons are propagation delay and rule priority conflicts:

1. Propagation delay: A new or modified rule takes time to reach all CDN POPs. Wait for propagation to complete before verifying.

2. Existing cache not yet expired: New rules apply only to content fetched after the rule takes effect. Already-cached content continues to be served until it expires or is manually purged. See Refresh and prefetch resources.

3. Origin response headers overriding the rule: Check whether Cache-Control or Expires headers from the origin are taking precedence over your CDN console configuration.

4. Rule priority conflict: When a CDN request matches multiple rules, priority is determined first by weight, then by creation time (earlier = higher priority for the same weight). Assign a distinct weight to each rule so the intended rule wins.

Example: The domain demo.aliyun.com has two rules with the same weight, both matching http://demo.aliyun.com/image/example.png. Because the /image directory rule was created earlier, it takes effect.

Configure CDN cross-origin resource sharing (CORS) using HTTP response headers

Set appropriate HTTP response headers to allow requests from different origins to access your resources. For details, see Configure cross-origin resource sharing.

Why do I still get a cross-origin error after configuring the Access-Control-Allow-Origin header?

If you configured the Access-Control-Allow-Origin response header in Alibaba Cloud CDN but the client still encounters a cross-origin error and the header is missing, the cause may be one of the following:

1. Incorrect or ineffective configuration: The configuration is not set correctly or has not yet taken effect.

2. CDN cache: Legacy response headers were cached on CDN POPs. Purge the CDN cache and access the resource again. See Refresh and prefetch resources.

3. Origin server issues: The origin server may be returning an Access-Control-Allow-Origin header that conflicts with the CDN configuration. Use consistent CORS header settings on both the origin and CDN.

4. Browser cache: Clear the browser cache or test in a private browsing window.

If the issue persists, contact Alibaba Cloud CDN technical support.

What are the cache rules for abnormal status codes?

Status codes 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, and 504:

1. If the origin returns a Set-Cookie header, CDN does not cache the response.

2. If the origin does not return Set-Cookie and a status code expiration time is configured in the CDN console, the response is cached according to that configuration. For how multiple rules interact, see the priority rules described earlier.

3. If the origin does not return Set-Cookie and no console expiration is configured, the response is cached based on Pragma, Cache-Control, or Expires from the origin.

4. If none of Set-Cookie, Pragma, Cache-Control, or Expires are present and no console expiration is configured, the response is cached for 1 second by default.

Status codes 302, 307, and 403:

1. If the origin returns a Set-Cookie header, CDN does not cache the response.

2. If the origin does not return Set-Cookie and a status code expiration time is configured in the CDN console, the response is cached according to that configuration.

3. If the origin does not return Set-Cookie and no console expiration is configured, the response is cached based on Pragma, Cache-Control, or Expires from the origin.

4. If none of Set-Cookie, Pragma, Cache-Control, or Expires are present and no console expiration is configured, the response is not cached.

Status code 304: CDN does not cache the response. Cache duration cannot be configured for status code 304.

What is the difference between outgoing and incoming response headers?

Outgoing and incoming response headers represent HTTP header information at different stages of the caching flow:

• Outgoing response headers: Sent from a CDN POP to the client (for example, a browser). If the POP has the content cached, it returns it directly without contacting the origin.

• Incoming response headers: Sent from the origin server to a CDN POP. When the POP cache expires or a cache miss occurs, the POP fetches the latest content from the origin, and the origin's HTTP response — including its headers — is the incoming response.

Outgoing response headers control caching between clients and CDN POPs. Incoming response headers control caching between the origin server and CDN POPs. Both are often configured together for precise cache control. For details on modifying incoming response headers, see Modify incoming response headers.

How do I prevent an entire domain from being cached?

Set the cache TTL to 0 for all paths on the domain:

1. Log on to the CDN console.

2. In the left navigation pane, click Domain Names.

3. Find the target domain name and click Manage in the Actions column.

4. In the domain's navigation pane, click Cache.

5. On the Cache Expiration tab, click Create Rule and configure the following:

   • Type: Directory

   • Object: / (matches all paths)

   • Expire In: 0 seconds

   • Keep default settings for other parameters.

6. Click OK.

If multiple rules exist on the Cache Expiration tab, assign the highest Weight to this rule to ensure it takes priority over all others.

Does CDN support multi-replica caching?

Yes. CDN supports multi-replica caching by default. The origin server must include a Vary header to tell CDN POPs which request header to use when differentiating cached replicas.

For example, if clients send requests with Accept-Encoding: gzip or Accept-Encoding: br, the origin returns different compressed versions. To cache both versions separately, add Vary: Accept-Encoding to the origin response. CDN POPs then store and serve distinct replicas based on the Accept-Encoding value in each request.

Configure CDN to serve a subdirectory homepage

A common pattern is to return a default homepage when a user accesses a subdirectory URL. Configure this in CDN to avoid changes to your origin server.

For example, if the homepage file is https://www.example.com/cdn/index.html, accessing https://www.example.com/cdn or https://www.example.com/cdn/ also returns the homepage.

Configure a subdirectory URL rewrite

1. Log on to the CDN console.

2. In the left navigation pane, click Domain Names.

3. Find the target domain name and click Manage in the Actions column.

4. In the domain's navigation pane, click Cache.

5. Click the Access URL Rewrite tab.

6. Click Create and configure two rules to handle both trailing-slash and no-trailing-slash patterns:

   • Rule 1: Path to Rewrite = ^/(.+)/$, Target Path = /$1/index.html, Action = Break

   • Rule 2: Path to Rewrite = ^/([^.?#]+)$, Target Path = /$1/index.html, Action = Break