CDN:FAQ about cache

• What is the CDN/DCDN cache purge mechanism?

• What is the default CDN/DCDN cache rule?

• How do I determine whether a resource is cached on a CDN/DCDN POP?

• How do I resolve a low CDN/DCDN cache hit ratio caused by variable parameters in URLs?

• How do I configure files to be fetched directly from the origin server instead of being cached?

• Why is the content not up-to-date even though the cache TTL is set to 0 in the CDN/DCDN console?

• Are caches on CDN/DCDN POPs updated automatically and in real time after a file is updated on the origin server?

• What factors can lower the CDN/DCDN cache hit ratio?

• How do I troubleshoot a low cache hit ratio?

• How do I improve the CDN cache hit ratio?

• How do I configure global cache settings?

• Set the Nginx HTTP cache policy

• Set the Apache cache policy

• Set the IIS cache policy

• How do I set the server-side cache TTL when using CDN to accelerate static resources?

• Why is the content served by CDN different from the content on the origin server?

• Why did my cache configuration not take effect?

• Configure cross-origin resource sharing (CORS) for CDN

• Why do I still receive a cross-origin error and the configured response header is missing after I configure the Access-Control-Allow-Origin response header?

• What are the cache rules for abnormal status codes?

• What is the difference between outgoing and incoming response headers?

• How do I configure an entire domain name to not be cached?

• Does CDN support multi-replica caching?

What is the cache clearing 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 based on the following priority. A lower number indicates a higher priority.

1. If the origin server responds with pragma:no-cache, cache-control:no-cache (or no-store, or max-age=0), CDN follows the origin server's policy and does not cache the resource.

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

   Note

   If a request matches multiple rules, only one rule takes effect. Priority is determined first by weight and then by creation time.

   • If you have multiple cache rules, set a different weight for each rule to control their execution priority. A higher weight indicates a higher priority.

   • For rules with the same weight, the one created earlier has a higher priority, regardless of the rule type.

3. Other cache rules configured on the origin server. The priority from high to low is: cache-control > expires > last-modified > ETag.

   1. If the origin response contains the cache-control header, its value includes max-age or s-maxage, and the value of max-age or s-maxage is greater than 0, the cache-control header determines the cache expiration time. For example: cache-control: max-age=3600. If both max-age and s-maxage are present, s-maxage takes precedence.

   2. If the origin response does not include cache-control but includes the Expires header, the cache TTL is determined by the Expires header. For example, expires:Tue, 25 Nov 2031 17:25:43 GMT.

   3. If the origin response does not include cache-control or Expires but includes last-modified, the cache duration is calculated using the formula: (current time - last-modified) × 0.1. The duration is 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.

   4. If the origin response does not include cache-control, Expires, or last-modified but includes ETag, the resource is cached for 10 seconds.

4. If the response from the origin server does not include any of these cache-related headers (cache-control, expires, last-modified, or ETag), the resource is not cached by default.

How do I know whether a resource is cached?

You can check the HTTP response headers to determine whether CDN caches files.

1. X-Cache: Indicates whether the request hit the CDN cache. A value of HIT indicates a cache hit. A value of MISS or a missing header indicates a cache miss.

2. Age: The time in seconds that the file has been cached on the CDN POP. This header is not present for purged files or first-time requests. An Age value of 0 indicates that the cache has expired and requires revalidation with the origin server.

3. X-Swift-CacheTime: The configured cache duration on the CDN POP. You can calculate the remaining cache time using the formula: X-Swift-CacheTime – Age.

4. X-Swift-SaveTime: The time in GMT when the resource was first cached on the CDN POP. To convert to UTC+8, add 8 hours.

To view these HTTP response headers, you can use one of the following methods to check whether your content is cached on CDN:

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

How do I resolve a low cache hit ratio issue due to variable parameters in URLs?

This may be because the Ignore Parameters feature is not enabled. For more information, see Low cache hit ratio due to variable parameters in URLs.

How do I configure files to be fetched directly from the origin server instead of being cached?

To prevent specific resources from being cached, you can set their cache TTL to 0 based on the directory, file path, or file type.

• Type: Select Directory or File Extension.

• Object: Enter the path of the directory or the file extension that you do not want to cache, such as dynamic files with .php, .jsp, or .asp extensions, or all files in the /admin directory.

• Expire In: Set the value to 0. This specifies that resources of this type are not cached.

• Weight: Adjust the weight value as needed. A higher weight indicates a higher priority.

For more information, see Configure CDN cache expiration time.

Why is the content not up-to-date even though the cache TTL is set to 0 in the CDN console?

Setting the cache TTL to 0 in the CDN console ensures that every request is redirected to the origin server to retrieve the latest content. However, if you find that the accessed resource is still not the latest version, the cause may be one of the following:

1. Browser cache: The browser may have cached the old content. You can clear the browser cache or use a private browsing window to test.

2. Configuration propagation delay: After you set the cache TTL to 0, it may take some time for the setting to propagate to all CDN POPs. If a CDN POP has not received the updated configuration, it may continue to serve the stale content.

3. Origin server cache: The origin server may have its own caching mechanism. If the cache on the origin server is not updated, CDN POPs may retrieve stale content during an origin fetch.

4. POP cache purge delay: Resources cached before the configuration change may take time to be purged. You can manually purge the cache to immediately retrieve the latest content. For more information, see User Guide.

Are caches on POPs updated automatically and in real time after a file is changed on the origin server?

After a file is updated on the origin server, the cache on CDN POPs is not updated automatically or in real time. Cache updates are determined by the configured cache policy.

• CDN POPs update the cache based on the configured cache TTL. If the cache has not expired, changes to the file on the origin server are not immediately reflected in the CDN cache. For more information, see Configure CDN cache expiration time.

• You can manually purge the cache so that the next request retrieves the latest content from the origin server.

  • To purge from the console, see User Guide.

  • To purge by calling an API operation, see Refresh Cache.

What factors can lower the cache hit ratio?

The following factors can lower the cache hit ratio for Alibaba Cloud CDN:

1. Cache purges: Manual or automatic cache purges can cause a temporary drop in the cache hit ratio.

2. Bandwidth spikes: A sharp increase in bandwidth over a short period can lead to more origin requests from CDNDCDN POPs, which lowers the cache hit ratio.

3. Requests for new content: If CDNDCDN POPs frequently receive first-time requests for new content, more origin fetches are required. This results in a lower cache hit ratio.

4. Cache rule changes: Modifying the cache policy can affect the cache hit ratio. Examples include an improperly configured cache TTL or cache policy.

5. Variable parameters in URLs: If a URL contains variable parameters after the question mark (?), each unique URL is treated as a different resource, even if the content is the same. This increases the number of origin fetches and lowers the cache hit ratio.

6. Improperly configured cache TTL: If you do not set an appropriate cache TTL for static files based on their update frequency, cached resources may expire too early. This increases origin fetches and lowers the cache hit ratio.

For more information about factors that affect the cache hit ratio, see Improve the CDN cache hit ratio. For more information, see Refresh and prefetch resources, Ignore parameters, and Configure CDN cache expiration time.

How do I troubleshoot a low cache hit ratio?

A low cache hit ratio can slow down content loading and increase the load on your origin server. For more information, see Troubleshoot a low CDN cache hit ratio.

How do I configure global cache settings?

To configure global cache settings with a cache Time to Live (TTL), set Type to Directory and enter a forward slash (/) in the Content field to match all directories. For more information, see Configure CDN cache expiration time.

Why did my cache configuration not take effect?

If you configured a cache rule that did not take effect, the cause may be one of the following:

1. Propagation delay: A new or modified cache rule may take some time to propagate. You can verify the rule after the propagation is complete.

2. Cache update mechanism: A new rule is not immediately applied to content that is already cached. The new rule takes effect only after the existing cache expires.

3. Cache not purged: After you change a cache setting, existing cached content will continue to be served to users until it expires or is manually purged. For more information, see Refresh and prefetch resources.

4. Improper cache response headers: Check whether the Cache-Control and Expires headers in the HTTP response from the origin server are set correctly.

5. Cache rule priority: If a CDN request matches multiple rules, priority is determined first by weight and then by creation time.

   • If you have multiple cache rules, you can set a different weight for each rule to control their execution priority. A higher weight indicates a higher priority.

   • For rules with the same weight, the one created earlier has a higher priority, regardless of the rule type.

   Configuration example: The following cache policies are configured for the accelerated domain name demo.aliyun.com. A CDN POP fetches the resource http://demo.aliyun.com/image/example.png from the origin server. Although the request matches both rules and their weights are the same, the rule with the earlier creation time has a higher priority. In this case, the rule for the /image directory was created earlier and therefore takes effect.

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

You can set the appropriate HTTP response headers to allow requests from different origins to access your resources. For more information, see Configure CORS.

Why do I still get a cross-origin error and the configured response header is missing, even after I configured the Access-Control-Allow-Origin response header?

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

What are the cache rules for abnormal status codes?

• For status codes 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, and 504, the cache rules are as follows:

  

  1. If the origin server returns a set-cookie response header, CDN does not cache the response.

  2. If the origin server does not return a Set-Cookie response header, the response is cached based on the expiration time of the status code that you configure in the CDN console. For information about how multiple rules take effect, see the Priority of multiple rules section.

  3. If the origin server does not return a Set-Cookie response header and you do not configure an expiration time for the status code in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header from the origin server.

  4. If the origin server does not return a Set-Cookie, Pragma, Cache-Control, or Expires response header and you do not configure an expiration time for the status code in the CDN console, the response is cached for 1 second by default.

• For status codes 302, 307, and 403, the cache rules are as follows:

  

  1. If the origin server returns a set-cookie response header, CDN does not cache the response.

  2. If the origin server does not return a Set-Cookie response header, the response is cached based on the expiration time of the status code that you configure in the CDN console. For information about how multiple rules take effect, see the Priority of multiple rules section.

  3. If the origin server does not return a Set-Cookie response header and you do not configure an expiration time for the status code in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header from the origin server.

  4. If the origin server does not return a Set-Cookie, Pragma, Cache-Control, or Expires response header and you do not configure an expiration time for the status code in the CDN console, the response is not cached.

• For the 304 status code, CDN does not cache the response. You cannot set a cache duration for this status code.

What is the difference between outgoing and incoming response headers?

outgoing response headers and incoming response headers represent HTTP header information at different stages in the cache architecture.

• Outgoing response headers: These headers are sent from a CDN POP to a client, such as a browser. If the CDN POP has the requested content in its cache, it returns the content directly to the client without contacting the origin server.

• Incoming response headers: These headers are sent from the origin server to a CDN POP. When the cache on a CDN POP expires or a request results in a cache miss, the CDN POP requests the latest content from the origin server. The response from the origin server, including its HTTP headers, is the incoming response.

The difference between outgoing and incoming response headers lies in their application scenarios and the interactions they control. outgoing response headers control the caching behavior between clients and CDNDCDN POPs. incoming response headers control the caching behavior between the origin server and CDNDCDN POPs. They are often used together to achieve efficient and precise cache control. For more information about incoming response headers, see Modify incoming response headers.

How do I configure an entire domain name to not be cached?

To prevent an entire domain name on Alibaba Cloud CDN from being cached, you can set the cache TTL for all paths to 0. You can follow these steps:

1. Log on to the CDN console.

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

3. On the Domain Names page, 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.

   • Type: Select Directory.

   • Object: Enter /. This represents all paths.

   • Expire In: Enter 0 seconds.

   • Keep the default settings for other parameters.

6. Click OK to complete the configuration.

Does CDN support multi-replica caching?

Yes. CDN supports multi-replica caching by default. The origin server must include the Vary header to instruct CDNDCDN POPs to create different replicas based on a specific request header.

For example, to support different compression types, a client may send a request with Accept-Encoding: gzip, and the origin server returns gzip-compressed content. If the client sends Accept-Encoding: br, the origin server returns Brotli-compressed content. To cache these different versions of the response, the origin server must add a Vary header to its response. This header tells the caching system which request header to use to differentiate the replicas. In this example, the origin server must set Vary: Accept-Encoding. This indicates that different cached replicas are stored and served based on the value of the Accept-Encoding header.