All Products
Search

This Product

    CDN:FAQ about caching

    Document Center

    CDN:FAQ about caching

    Last Updated:Apr 12, 2024

    This topic provides answers to some commonly asked questions about caching.

    What is the default TTL value of cached resources?

    If you do not configure cache rules on the origin server or POPs, the default TTL is used for cached resources. By default, cached resources are valid for 3,600 seconds.

    What is the mechanism for clearing the cache?

    If a resource that is cached on a POP is infrequently accessed, the resource may be overwritten by frequently accessed resources on the POP before the resource expires.

    What is the default cache rule?

    After a POP retrieves a static file from an origin server, the POP processes the static file based on the priorities of the following cache rules. A smaller number specifies a higher priority.缓存优先级

    1. If the response carries the pragma:no-cache, cache-control:no-cache, cache-control:no-store, or cache-control:max-age=0 directive, the static file is not cached.

    2. Alibaba Cloud CDN follows the TTL for cached resources, or the TTL for HTTP status codes that are configured in the console.

      Note

      If a request matches multiple cache rules, only one rule takes effect based on the following order of priority: weight > creation time.

      • If you create multiple cache rules, we recommend that you specify a unique weight for each cache rule to define the priorities of the cache rules. A higher weight specifies a higher priority.

      • Cache rules that have the same weight are prioritized based on the creation time, regardless of the rule type. The rule that has the earliest creation time takes precedence.

    3. Alibaba Cloud CDN follows other cache rules set on the origin server. Headers in responses from the origin server are in the following descending order of priority: Cache-Control > Expires > Last-Modified > ETag.

      1. The response carries the Cache-Control header, the directive is max-age or s-maxage, which is set to a value that is greater than 0, such as Cache-Control:max-age=3600. If both the max-age and s-maxage directives exist, the value of the s-maxage directive prevails.

      2. The response carries the Expires header, such as, Expires:Tue, 25 Nov 2031 17:25:43 GMT.

      3. If the response carries the ETag or Last-modified header, the TTL is calculated based on the following rules:

        1. If the response carries the Last-Modified header, TTL = (Current time - Last-Modified) × 0.1. If the result is from 10 seconds to 3,600 seconds, the result applies. If the result is less than 10 seconds, the TTL is 10 seconds. If the result is greater than 3,600 seconds, the TTL is 3,600 seconds.

        2. If the response carries only the ETag header, the TTL is 10 seconds.

    4. If the response does not carry the ETag, Last-Modified, Cache-Control, or Expires header, the static file is not cached on the POP.

    How do I determine whether a resource is cached?

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

    1. X-Cache: specifies whether the request hits the cache. If the value of the X-Cache header is HIT, the request hits the cache. If the value is MISS or the header does not exist, the request does not hit the cache.

    2. Age: specifies the amount of time that a file has been cached on points of presence (POPs). Unit: seconds. An HTTP response includes the Age header only if the file is cached on POPs. If a file is not cached after the file is refreshed or cleared, the HTTP response does not include the Age header. If the value of the Age header is 0, the file is cached on POPs but the cache has expired and cannot be used. Therefore, the request is redirected to the origin server.

    3. X-Swift-CacheTime: specifies the TTL value of a file that is cached on POPs. Remaining TTL before a file is refreshed = X-Swift-CacheTime - Age.

    4. X-Swift-SaveTime: specifies the time when a file was first cached on POPs. The time is in GMT. You can convert the time to UTC+8. For example, if the value of the X-Swift-SaveTime header is 2023-04-17 14:30:49, the time when a file was first cached is 2023-04-17 22:30:49 in UTC+8.

    To view the HTTP response headers and determine whether a file is cached on POPs, you can use one of the following methods:

    Method 1: Use a browser developer tool, such as Chrome DevTools

    image.png

    Method 2: Run the curl command to view the resource caching information

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

    image.png

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

    Enable the parameter filtering feature of Alibaba Cloud CDN to resolve the issue. For more information, see Low cache hit ratio due to variable parameters in URLs.

    How do I configure POPs not to cache resources and to retrieve resources from origin servers?

    Configure a TTL value based on the directory, path, and file type of the resources that you do not want to cache. The following section describes the parameters:

    • Type: Select Directory or File Extension.

    • Object: Enter the directory or filename extension of the resources that you do not want to cache. For example, you can specify dynamic files of the php,jsp,asp types or all files in the admin directory.

    • Expire In: Set this parameter to 0, which specifies that the resources of the types or in the directory are not cached.

    • Weight: Configure the weight of the rule based on your business requirements. A higher weight indicates a higher priority for determining cache hits.

    For more information, see Create a cache rule for resources.

    image.png

    Why are the retrieved resources not up to date even if I set the TTL for resources to 0 in the console?

    If you set the Expire In parameter to 0 for specific resources in the Alibaba Cloud CDN console, the resources are not cached on POPs, and requests for the resources are redirected to the origin server. However, the retrieved resource may not be up to date due to the following reasons:

    1. Browser cache: The browser of the user may have cached the earlier version of the resource. Even if the resource is not cached on POPs or origin servers, the earlier version of the resource may be retrieved before the cached resource in the browser of the user expires. We recommended that you clear the browser cache or use the Incognito mode of the browser.

    2. Delay before cache rules take effect: After you set the Expire In parameter to 0, it may take a period of time for the setting to apply on all POPs. In addition, if POPs have not detected changes in cache rules, the POPs may still return earlier versions of the old cached resources.

    3. Cache not refreshed on origin servers: Origin servers may also have a caching mechanism. If resources that are cached on origin servers are not updated, POPs may retrieve the old version of resources from origin servers.

    4. Delay in clearing cache on POPs: If POPs have cached a resource before you configure a cache rule, it may take a period of time to clear the cached resource from all POPs even if you set the Expire In parameter to 0. You can manually refresh the cache to ensure that the latest version of the resource is retrieved from the origin server. For more information, see Manually refresh resources.

    Do POPs update cached resources in real time after the resources are modified on origin servers?

    POPs do not update cached resources in real time after the resources are modified on origin servers. In most cases, POPs determine when a cached file expires or is refreshed based on the configured cache rules after the file is cached on POPs.

    • POPs update resources based on the Expire In parameter that you configured in the Alibaba Cloud CDN console. If a resource on the origin server is updated, POPs do not update the resource until the cached resource expires. In this case, the resource on the origin server is inconsistent with the one on POPs. For more information, see Create a cache rule for resources.

    • You can manually refresh the cache. This way, you can immediately remove the cache of a specific file or directory from POPs. The next request for the file is redirected to the origin server to retrieve the latest content.

    What are the factors that reduce the cache hit ratio?

    The following section describes the factors that reduce the cache hit ratio. For more information, see Increase the cache hit ratios of Alibaba Cloud CDN.

    1. Cache refresh: Manual or automatic cache refresh operations may reduce the cache hit ratio within a short period of time.

    2. Bandwidth usage spikes: When bandwidth usage spikes occur, a large number of requests are redirected to origin servers. This reduces the cache hit ratio. For more information, see Refresh and prefetch resources.

    3. Requests for new resources: If a large number of requests for new resources are sent to POPs, the requests are redirected to origin servers and the cache hit ratio decreases.

    4. Changes in cache rules: Changes in cache rules may affect the cache hit ratio. For example, a TTL value or cache rule is improperly configured.

    5. Variable parameters in URLs: Requests whose URLs contain variable parameters after the question mark (?) are considered requests for different resources. This reduces the cache hit ratio. For more information, see Ignore parameters.

    6. No proper TTL value: If you do not configure a TTL value for static files that are updated at different frequencies, the cached resources may prematurely expire. This reduces the cache hit ratio. For more information, see Create a cache rule for resources.

    How do I troubleshoot a low cache hit ratio issue?

    A low cache hit ratio may cause slow content loading and increase loads on origin servers. For information about how to troubleshoot low cache hit ratio issues, see Troubleshoot low cache hit ratios.

    How do I apply cache settings to all directories?

    You can specify a TTL value for resources in all directories. When you create a cache rule, set the Type parameter to Directory and the Object parameter to a forward slash (/) to specify all directories. For more information, see Create a cache rule for resources.

    Why does a cache rule not take effect?

    A cache rule that you configured may not take effect due to the following reasons:

    1. Delay before rules take effect: After you create or modify a cache rule, it takes a period of time for the rule to take effect. We recommend that you verify after the new rule takes effect.

    2. Cache update mechanism: After you modify a cache rule for a resource that is already cached on POPs, the rule does not immediately take effect. After the cached resource expires, the latest version of the resource is retrieved from the origin server and cached on POPs based on the rule.

    3. Cache not refreshed: If you do not manually refresh the cache after you modify the cache settings, the cached resource continues to be returned to users until the cached resource expires. If you want a cache rule to take effect immediately, refresh the cache after you modify the cache rule. For more information, see Refresh and prefetch resources.

    4. Improper cache-related response headers: Check whether the Cache-Control and Expires response headers from the origin server are properly configured. For example, if the value of the Cache-Control header is no-cache or no-store, POPs and browsers do not cache resources.

    5. Priority of cache rules: If a request matches multiple rules, only one rule takes effect. Priority: weight > rule creation time.

      • If you create multiple cache rules, we recommend that you specify a unique weight for each cache rule to define the priorities of the cache rules. A higher weight specifies a higher priority.

      • Cache rules that have the same weight are prioritized based on the creation time, regardless of the rule type. The rule that has the earliest creation time takes precedence.

      Configuration example: The following cache rules are configured for the accelerated domain name demo.aliyun.com. POPs retrieve the resource http://demo.aliyun.com/image/example.png from the origin server. The following rules are matched, and the weights of the two rules are the same. Therefore, the system selects the rule to take effect based on the rule creation time. The rule that is created earlier has a higher priority. In this example, the rule for the /image directory is created earlier. Therefore, this rule takes effect.image.png

    How do I configure CORS by using HTTP response headers?

    You can configure HTTP response headers to allow requests from different sources to access resources. For more information, see Configure CORS.

    Why is a CORS issue reported and the Access-Control-Allow-Origin response header not returned even if I have configured the response header?

    You have configured a response header in Alibaba Cloud CDN, such as Access-Control-Allow-Origin, but a CORS issue occurs when the client is accessing resources and the configured response header is not returned in the response. The following section describes the possible causes:

    Possible causes

    1. Pending or invalid configuration: The response header configuration is invalid or does not take effect. In this case, Alibaba Cloud CDN does not return the configured response header.

    2. POP cache: The old response header may be cached on POPs. In this case, the old header is returned even if you modified the configuration.

    3. Origin server issues: If you configure a CORS response header on POPs, a response from the origin server also contains a CORS response header, and the configurations of the response headers conflict, the issue may occur. In this case, you need to use the same configuration for CORS response headers on POPs and on the origin server.

    4. Browser cache: The old response header may be cached in the browser. In this case, the browser does not initiate a new request to obtain the updated response header.

    Solutions

    1. Verify configurations: Make sure that the configurations of Alibaba Cloud CDN, especially configurations of CORS response headers, are valid and in effect.

    2. Clear the Alibaba Cloud CDN cache: You can use the refresh feature of Alibaba Cloud CDN to clear the cached content and then re-access the resource. For more information, see Refresh and prefetch resources.

    3. Check the configurations of the origin server: Make sure that the origin server does not return a CORS response header that conflicts with the response headers that are returned by POPs. We recommend that you configure the same CORS-related response header for the origin server and POPs. Otherwise, conflicts may occur.

    4. Clear the browser cache: Clear the browser cache or use the Incognito mode of the browser to ensure that the browser obtains the latest response headers.

    5. Contact technical support: If you have tried all the preceding solutions and the issue persists, Alibaba Cloud CDN may be faulty. Contact Alibaba Cloud technical support or submit a ticket.

    What are the differences between HTTP response headers from POPs and origin servers?

    HTTP response headers from POPs and origin servers are returned by different components of a caching system.

    • HTTP response headers from POPs are sent by the POPs to the clients, such as a browser. When a POP receives a client request, the POP returns the requested content together with the corresponding HTTP response headers to the client if the content is cached on the POP. The POP does not need to initiate a request to the origin server.

    • HTTP response headers from origin servers are sent by origin servers to POPs. When a request does not hit the cache on a POP or the cache has expired, the POP initiates a request to retrieve the latest content from the origin server. The origin server returns the requested content together with the corresponding HTTP response headers. POPs receive, process, and store the HTTP response headers for subsequent use.

    Therefore, HTTP response headers from POPs and origin servers are used in different scenarios and sent by different components. HTTP response headers from POPs are used to control the caching of clients and POPs. HTTP response headers from origin servers are used to control the caching of origin servers and POPs. In actual scenarios, the HTTP response headers from POPs are used together with the HTTP response headers from origin servers for efficient and accurate caching. For more information, see Configure HTTP response headers.

    What are the cache rules for HTTP status codes?

    • The following figure shows the cache rules for HTTP status codes 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, and 504.状态码缓存过期时间

      • If you enable the range origin fetch feature that is described in Range origin fetch, the following cache rules apply:

        • For HTTP status codes other than 200 and 206, such as 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, and 504, resources are not cached.

          For HTTP status codes 200 and 206, resources are cached based on the cache rules that are described in Default cache rule and priorities of cache rules.

        • An HTTP 5xx status code allows the POPs to remove cached file chunks. If origin fetch times out, the file chunks are not removed.

          Note

          If you enable the range origin fetch feature, origin servers divide a large file into chunks before the file is returned to POPs. For example, a file is divided into 10 chunks, 5 of which are cached on POPs. When a user requests the 6th chunk, the origin server returns an HTTP 5xx status code, and the POPs remove the 5 chunks that are cached.

      • If you disable the range origin fetch feature, the following cache rules apply:

        1. If an origin server returns the Set-Cookie response header, the POPs do not cache the retrieved resource.

        2. If the origin server does not return the Set-Cookie response header, the retrieved resource is cached based on the cache rules that are configured in the Alibaba Cloud CDN console. For more information, see How cache rules are applied.

        3. If the origin server does not return the Set-Cookie response header and no cache rules are configured in the Alibaba Cloud CDN console, the retrieved resource is processed based on the directive of the Pragma, Cache-Control, or Expires response header.

        4. If the origin server does not return the Set-Cookie, Pragma, Cache-Control, or Expires response header and no cache rules are configured in the Alibaba Cloud CDN console, the retrieved resource is cached for 1 second.

    • For HTTP 303, 304, 401, 407, 600, and 601 status codes, resources are not cached.