Cache-related FAQ

What is the cache eviction mechanism?

If a resource cached on a node has low access popularity, meaning it is accessed infrequently on the same node, the resource may be evicted by more popular resources before its cache expires.

What are the default caching rules?

When a node receives a file resource from the origin server, it applies the following caching rules in order of priority (highest to lowest):

• If the origin server responds with a pragma:no-cache header, or a cache-control header with a value of no-cache, no-store, or max-age=0, respects the origin server's policy and does not cache the resource.

• The cache expiration time or status code expiration time configured in the console.

• Other caching rules configured on the origin server are processed in the following order of priority: cache-control > expires > last-modified > ETag.

• If the origin response includes a cache-control header with a max-age or s-maxage value greater than 0, the cache-control header is used to set the cache expiration time. For example: cache-control:max-age=3600. If both max-age and s-maxage are present, s-maxage takes precedence.

• If the origin response does not include a cache-control header but includes an Expires header, the Expires header is used to set the cache expiration time. For example: expires:Tue, 25 Nov 2031 17:25:43 GMT.

• If the origin response does not include a cache-control or Expires header but includes a last-modified header, the cache duration is calculated as (Current Time – last-modified) × 0.1, with the result clamped to a minimum of 10 seconds and a maximum of 3,600 seconds.

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

• If the origin response lacks cache-control, expires, last-modified, or ETag headers, the resource is not cached by default.

In cache policy, what does "origin server" refer to? Does it mean OSS configuration or the HTML <meta> tag?

"Origin server" refers to the HTTP response headers returned by backend storage or application servers such as OSS and ECS, not the <meta> tag in HTML code.

When determining a cache policy, reads only the headers returned by the origin server in the HTTP response, such as Cache-Control and Expires. The http-equiv="Cache-Control" attribute in an HTML <meta> tag affects only browsers and is not parsed by CDN.

If the four cache configuration switches (Prioritize Origin Server Cache Policy, Ignore Origin No-Cache Headers, Client Follows Cache Policy, and Force Content Revalidation) are left in their default Off state, is the behavior the same as the previous configuration where only an expiration time was set?

Yes. When all four toggles are Off, caches content based on the cache expiration time rules configured in the console, matching the legacy behavior. For details about each toggle, see the parameter descriptions in Configure CDN Cache Expiration Time.

When creating a accelerated domain name, does selecting a business type (such as Images & Small Files or Large File Downloads) apply a default cache policy?

The business type (such as Images & Small Files or Large File Downloads) that you select when creating a accelerated domain name has little impact on the default cache policy. does not pre-configure fixed cache durations for specific file extensions or paths.

The actual caching behavior is determined by your configurations in the console. After creating the domain name, go to Configure CDN Cache Expiration Time to configure caching rules based on your resource types and update frequency.

What is the difference between node HTTP response headers and origin HTTP response headers?

In a caching architecture, node HTTP response headers and origin HTTP response headers refer to HTTP header information at different stages of data delivery.

• Node HTTP response header (outbound response header): The HTTP response header sent from a node to a client such as a browser. If the node has cached content, it returns the content directly to the client without requesting it from the origin server.

• Origin HTTP response header (inbound response header): The HTTP response header sent from the origin server to a node. When the cache on a node expires or a cache miss occurs, the node performs an origin fetch to retrieve the latest content. The headers returned with this content from the origin server constitute the origin HTTP response header.

The key difference is their scope: node headers control caching behavior between the client and the CDN, while origin headers control caching behavior between the origin server and CDN. Used together, they enable precise and efficient cache control. For more information about inbound response headers, see Modify Inbound Response Headers.

Does support multi-copy caching? How does it work?

CDN supports multi-copy caching by default. The origin server must include a Vary header to tell CDN nodes which request header value to use for creating separate cached copies.

For example, when a client sends a request with Accept-Encoding: gzip, the origin server returns gzip-compressed content. If another client sends Accept-Encoding: br, the origin server returns Brotli-compressed content. To cache these different versions separately, the origin server must include the Vary header to specify which request header distinguishes the copies. In this case, the origin server should set Vary: Accept-Encoding, which instructs CDN to store and serve distinct cached copies based on the Accept-Encoding request header value.

How do I apply a caching rule globally?

You can apply a caching rule globally by configuring a cache expiration time. Set Type to Directory and enter a forward slash (/) in the Object field to match all directories. For details, see Configure CDN Cache Expiration Time.

The following three FAQs address related scenarios for disabling or limiting CDN caching. Choose the one that matches your use case:

• Full-site no-cache — Disable caching for all resources on a domain.

• Static-only caching — Cache static files while forwarding dynamic requests to the origin.

• Path-specific passthrough — Disable caching for specific directories, APIs, or dynamic resource paths.

How do I disable caching for an entire domain?

To disable caching for an entire domain name on Alibaba Cloud CDN, set the cache expiration time for all paths to 0 and ensure this rule has the highest weight. Follow these steps:

• On the Cache Expiration tab, click Create Rule.

• Type: Select Directory.

• Object: Enter / to match all paths.

• Expire In: Enter 0s.

• Keep the default settings for other parameters.

• Click OK to complete the configuration.

If a request to Alibaba Cloud matches multiple caching rules, only the rule with the highest priority takes effect. Priority is determined in the following order: weight > rule creation time.

If you have multiple rules on the Cache Expiration page, ensure that the domain-wide no-cache rule has the highest Weight (which gives it the highest priority).

How do I configure CDN to cache only static files (such as images, CSS, and JS) while letting dynamic pages pass through to the origin server?

Use a weighted "allowlist/blocklist" approach:

• Create a high-priority static caching rule: Add one or more rules with Type set to "File Extension" and Object set to static file extensions such as jpg,png,css,js. Set a long cache duration (for example, 1 month) and a high Weight (for example, 90–99).

• Create a low-priority dynamic no-cache rule: Add a rule with Type set to "Directory" and Object set to / (the root directory). Set Expire In to 0 seconds (no cache) and assign a low Weight (for example, 1–10).

• Optimize for specific dynamic paths: If certain dynamic paths such as /api/ or /wp-admin/ must never be cached, add a separate directory rule for each path, set the cache duration to 0 seconds, and assign the highest Weight (for example, 99) to ensure it is matched first.

How do I configure passthrough (no caching) for dynamic resources, APIs, or specific directories?

For different dynamic content scenarios, you can set the cache expiration time to 0 seconds to ensure requests pass through to the origin server:

• Disable caching for dynamic pages and APIs: For dynamic content such as PHP pages, ASP.NET pages, API endpoints, real-time communications (long-lived connections), and backend upload APIs, add a File Extension rule. Enter the relevant extensions (for example, php,aspx,jsp) and set Expire In to 0 seconds. This ensures every request goes to the origin server, preventing issues such as invalid CAPTCHAs, unexpected login states, or failed image uploads caused by cached dynamic content.

• Disable caching for a specific directory: To achieve an effect similar to "disabling acceleration" for specific directories such as /api/ or /wp-admin/, add a Directory rule. Enter the target directory path and set the expiration time to 0 seconds. CDN does not support directly disabling acceleration for a directory, but this configuration forces requests to pass through to the origin server.

• Priority for root and subdirectories: To cache only a specific subdirectory (for example, /static/) while not caching other resources under the root directory /, configure two separate rules. Assign a high Weight (for example, 99) to the rule for /static/. Then, create a rule for the root directory / with a cache expiration time of 0 seconds and a low weight (for example, 1). If full-site caching causes issues for dynamic APIs, delete the full-site caching rule and instead configure caching by file extension or specific static directories.

• Caching issues for SPAs and HTML pages: If a single-page application (SPA) returns 404 errors or has unexpected login redirects, check whether caching is configured for .html or index.html. Disable the cache for HTML files (set the expiration time to 0 seconds) or remove the Cache-Control header from the origin response, and then perform a cache purge.

Does setting a .aspx file extension caching rule to 0 seconds disable caching for the entire site?

If all pages on your site end with the .aspx extension, setting the cache expiration time for .aspx to 0 effectively disables caching for the entire site.

Avoid using a broad file extension for a site-wide rule. Instead, configure caching rules for specific file paths or directories. For example, set a long cache duration for the /static/ directory and create a separate rule to disable caching (0 seconds) for dynamic API endpoints such as /api.aspx.

How do I configure cache duration for robots.txt and sitemap.xml?

These files directly affect how search engines crawl your site, so you should configure a separate cache duration for them based on their update frequency. This prevents a default rule from caching them for too long, which can delay the discovery of your site updates.

If your sitemap is updated frequently, set the cache duration to no more than 1 hour. If the rules in your robots.txt file are stable, you can set a longer cache duration.

Should I enable or disable the "Client Follows CDN Cache Policy" toggle?

This toggle controls whether passes its own caching policy (for example, max-age=3600) to client browsers through the response headers:

• Off (default): nodes still cache resources based on their configured rules but do not include this policy in the response header sent to the browser. In this case, the browser's caching behavior is determined solely by the headers you configure in the Modify Outbound Response Header feature.

• On: sends headers such as Cache-Control to the browser, so the browser and the node use the same caching policy.

If you have already configured the desired client-facing headers in the Modify Outbound Response Header feature and the behavior is as expected, keep this toggle in its default Off state. Enable it if you want browsers to reuse the policy to reduce redundant requests.

How does cache large files?

supports caching for large file download scenarios. You can configure cache expiration rules to store these files on nodes for an extended period, which improves the cache hit ratio and reduces origin fetch costs.

Configuration recommendations:

• Cache duration: For large files that are infrequently updated, set a cache expiration time of one month or longer.

• Origin server no-cache directives: Ensure that the origin server does not return directives such as Cache-Control: no-cache, no-store, or max-age=0. If you cannot control the origin server, select the Ignore Origin No-Cache Headers option in the caching rule.

• Large file prefetch: The initial request for a large file may have high latency. Before distribution, submit a prefetch task to push the file to nodes in advance.

How do I configure Cross-Origin Resource Sharing (CORS) through HTTP response headers?

Set the appropriate HTTP response headers to allow resources to be accessed by requests from different origins. For more information, see Configure Cross-Origin Resource Sharing.

How do I check whether has cached a resource?

You can check the following HTTP response headers to determine whether Alibaba Cloud has cached a resource:

• X-Cache: Indicates whether the request hit the cache. A value of HIT indicates a cache hit. A value of MISS, or the absence of this header, indicates a cache miss.

• Age: Indicates how long (in seconds) the file has been cached on a node. This header is absent for purged objects or first-time requests. An Age value of 0 indicates the cache has expired and requires an origin fetch for revalidation.

• X-Swift-CacheTime: Indicates the maximum cache time allowed for the file on a node. You can calculate the remaining cache time: X-Swift-CacheTime – Age.

• X-Swift-SaveTime: Indicates the time (in GMT) when the resource was first cached on a node. To convert to China Standard Time (UTC+8), add 8 hours.

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

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

In the Network panel, inspect the Response Headers. Focus on the CDN cache-related headers: Age, X-Cache, X-Swift-Cachetime, and X-Swift-Savetime.

Response Headers
Access-Control-Allow-Origin:    *
Age:    860
Ali-Swift-Global-Savetime:    1704259214
Cache-Control:    max-age=28800,s-maxage=3600
Content-Encoding:    gzip
Content-Length:    2618
Content-Md5:    /h0oxujZUUo1P8gMA893oQ==
Content-Type:    text/html
Date:    Wed, 03 Jan 2024 05:20:14 GMT
Eagleid:    db9062a517042600741495981e
Server:    Tengine
Timing-Allow-Origin:    *
Vary:    Accept-Encoding
Via:    cache49.l2cn3032[0,0,200-0,H], cache8.l2cn3032[3,0], cache8.l2cn3032[3,0], ens-cache16.cn3573[0,0,200-0,H], ens-cache17.cn3573[43,0]
X-Cache:    HIT TCP_MEM_HIT dirn:10:498457979
X-Oss-Hash-Crc64ecma:    1068125902847643907
X-Oss-Object-Type:    Normal
X-Oss-Request-Id:    6594EE8E1FC2C239355F41E1
X-Oss-Server-Time:    3
X-Oss-Storage-Class:    Standard
X-Source-Scheme:    https
X-Swift-Cachetime:    3600
X-Swift-Savetime:    Wed, 03 Jan 2024 05:20:14 GMT

Method 2: Use the curl command

Run the following command to check the CDN response headers for a resource:

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

The following is an example of the curl output:

F:\test>curl http://cdn.xxx.top/pic_03.jpg -v
* Host cdn.xxx.top:80 was resolved.
* IPv6: (none)
* IPv4: 1xxx
*   Trying 1xxx:80...
* Connected to cdn.xxx.top (xxx) part 80
> GET /pic_03.jpg HTTP/1.1
> Host: cdn.xxx.top
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: image/jpeg
< Content-Length: 8775526
< Connection: keep-alive
< Date: Mon, 26 May 2025 02:21:59 GMT
< x-oss-request-id: 68xxx9A
< x-oss-cdn-auth: success
< Accept-Ranges: bytes
< ETag: "Bxxx2"
< Last-Modified: Tue, 03 Sep 2024 06:20:19 GMT
< x-oss-object-type: Normal
< x-oss-storage-class: Standard
< Via: cache20.l2cn3032[0,0,200-0,H], cache10.cn3573[0,0,200-0,H], cache10.cn3573[1,0]
< Age: 424
< X-Cache: HIT TCP_HIT dirn:0:698837654
< X-Swift-CacheTime: 2592000
< Timing-Allow-Origin: *
< EagleId: 08xxx51
<
* Connection #0 to host cdn.xxx.top left intact
< x-oss-hash-crc64ecma: 12xxx58
< x-oss-storage-class: Standard
< x-oss-server-time: 228
< Via: ens-cache3.12cn7857[1863,1862,206-0,M], ens-cache38.12cn7857[1863,0], ens-cache20.cn6692[0,0,200-0,H], ens-cache4.cn6692[14,0]
< Age: 424
< Ali-Swift-Global-Savetime: 1748226119
< X-Cache: HIT TCP_HIT dirn:7:286737139 mlen:0
< X-Swift-SaveTime: Mon, 26 May 2025 02:21:59 GMT
< X-Swift-CacheTime: 2592000
< Timing-Allow-Origin: *
< EagleId: 7xxx220e

In this response, X-Cache: HIT TCP_HIT indicates a CDN cache hit. Age: 424 indicates that the resource has been stored in the cache for 424 seconds. X-Swift-CacheTime: 2592000 indicates that the cache expiration time is 2,592,000 seconds (30 days).

After configuring a caching rule, why do test requests still miss the cache or go to the origin server?

Follow these steps to troubleshoot:

• Check the configuration status: Confirm that the cache configuration status in the console shows "Success."

• Verify rule priority: If multiple rules exist, ensure that the rule matching the target path has the highest weight. For example, a rule for a specific directory such as /static/ should have a higher weight than the default rule for the root directory (/).

• Check origin response headers: If the origin server returns Cache-Control: no-cache/no-store/max-age=0 or Pragma: no-cache, and the Ignore Origin No-Cache Headers option is not enabled, CDN follows the origin's directives and does not cache the resource. Enable this option or adjust your origin server's configuration.

• Confirm the request method: Use a GET request (for example, curl -voa) for testing, not a HEAD request (for example, curl -I). A HEAD request might not trigger the L1 node's caching logic for the resource body, which can produce a false MISS result.

• Check URL parameters: If the URL contains query parameters, check whether the Ignore URL Parameters feature is enabled. If disabled, URLs with different parameters are treated as different resources. If enabled, they are treated as the same resource.

After I modify a caching rule, the status shows "Configuring." Is this normal? Does it affect my services?

• Configuration status: After you add or modify a caching rule, it is normal for the rule's Status to show "Configuring." This indicates the configuration is propagating to CDN nodes across the network. The status typically changes to "Success" within a few minutes. If it remains unchanged for an extended period, refresh the page to check the latest status.

• Service impact: Modifying caching rules does not affect the availability of your existing services. The new rule applies only to new requests. Content already cached on CDN nodes continues to be served based on the previous policy until the cache expires. If you need the new rule to take effect immediately for all requests, perform a cache purge to clear the outdated cache.

Does the cache on nodes update automatically after a file on the origin server is changed?

No. Modifying a file on the origin server does not automatically update the cache on nodes in real time. Cache updates depend on the configured caching policy.

• nodes update their cache based on the configured cache expiration time. If the cache for a resource has not expired, changes on the origin server are not immediately reflected in the cache. For more information, see Configure CDN Cache Expiration Time.

• You can manually purge the cache to force the next request to be redirected to the origin server for the latest content.

• In the console: Refresh and Prefetch Resources

• By calling an API: RefreshCache

After setting Cache-Control: no-cache, can users access the latest files without clearing the browser cache?

Not guaranteed. Cache-Control: no-cache only instructs the client to send a conditional cache request to for each request. If the node still has a cached copy of the file that has not expired, may return the cached content directly or perform an origin fetch for validation. If the file on the origin server has been updated but the cache has not been refreshed, users may still see the old file.

After you update a file on the origin server, perform a purge or prefetch operation in the console (see Refresh and Prefetch Resources). This forces nodes to retrieve the latest resource from the origin server, ensuring users access the most up-to-date file.

How do I achieve minute-level or near real-time cache updates?

Follow these steps to achieve minute-level updates:

• In the console, set a short cache expiration time for the target file (for example, 60 seconds).

• Enable the Force Content Revalidation toggle.

• Disable the Prioritize Origin Server Cache Policy toggle.

If you previously configured a longer cache duration, you must purge the old cache by using the Refresh and Prefetch Resources feature for the new configuration to take effect immediately.

If you require millisecond-level real-time updates, use versioned filenames on the origin server, such as style-a1b2c3d.css, instead of adjusting cache policies. For more information, see Configure CDN Cache Expiration Time.

Do I need to change the expiration time when the cache does not update?

You do not need to change the expiration time. Follow these two steps to make a one-time update take effect immediately:

• Enable the Force Content Revalidation toggle and disable the Prioritize Origin Server Cache Policy toggle.

• Submit a purge task for the corresponding file on the Refresh and Prefetch Resources page.

This operation only clears the outdated cached content. The next request performs an origin fetch to retrieve the latest resource, and subsequent requests continue to hit the cache as normal.

I set the cache expiration time to 0 in the console, but the content is still stale. Why?

Setting the cache expiration time to 0 in the console is intended to make every request fetch the latest content from the origin server. If you are still receiving stale content, the cause might be one of the following:

• Browser cache: The browser may have cached the old content. Clear your browser cache or test in incognito mode.

• Configuration propagation delay: After you set the cache duration to 0, the new setting may take some time to propagate to all nodes. If a node has not yet received the change, it may still serve stale cached content.

• Origin server cache: The origin server may have its own caching mechanism. If the origin server's cache is not updated promptly, nodes may fetch stale content during an origin fetch.

• Node cache eviction delay: Resources that were cached before you changed the configuration may take time to be cleared. You can manually purge the cache to immediately retrieve the latest content. For more information, see Refresh and Prefetch Resources.

Why are my caching rules not taking effect?

If you configured a caching rule but it does not seem to be working, the issue may be caused by one of the following reasons:

• Propagation delay: Changes to caching rules can take some time to propagate across the network. Wait for the rule to become fully active before verifying.

• Cache update mechanism: New rules do not apply immediately to already-cached content. They take effect only after the existing cached content expires.

• Cache purge not performed: After changing cache settings, if you do not manually purge the cache, users continue to receive the old cached content until it expires naturally. For more information, see Refresh and Prefetch Resources.

• Improper cache response headers: Check the HTTP response headers from your origin server to ensure the Cache-Control and Expires headers are set correctly.

• Caching rule priority: If a request matches multiple rules, priority is determined by: weight > rule creation time.

• When multiple caching rules exist, assign a different weight to each rule to control execution priority. A higher weight indicates a higher priority.

• For rules with the same weight, the rule created earlier takes precedence, regardless of the rule type.

Configuration example: The following caching rules are configured for the accelerated domain name demo.aliyun.com. When a node fetches the resource http://demo.aliyun.com/image/example.png from the origin server, both of the following rules are matched. Because both rules have the same weight, the rule that was created earlier takes precedence. The rule for the /image directory was created earlier, so the system applies the directory-type rule. The caching rule configuration list shows two rules:

• Content: jpg,png, Type: File Extension, Expiration Time: 1 month, Weight: 10, Status: Succeeded.

• Content: /image, Type: Directory, Expiration Time: 1 day, Weight: 10, Status: Configuring. For both rules, Prioritize Origin Server Cache Policy, Ignore Origin No-Cache Headers, Client Follows CDN Cache Policy, and Force Content Revalidation are disabled. Each rule supports Modify and Delete operations.

I configured the Access-Control-Allow-Origin response header, but I still have CORS issues. Why?

If you configured origin response headers such as Access-Control-Allow-Origin in Alibaba Cloud CDN, but clients still encounter cross-origin issues and the configured headers are missing from the response, the issue may be caused by one of the following:

Possible causes

• Incorrect or ineffective configuration: The configuration may be incorrect or may not have fully propagated.

• CDN cache: A CDN node may be serving an old response with outdated headers.

• Origin server issue: The cross-origin response headers from the origin server conflict with the CDN configuration.

• Browser cache: The browser has cached an old response.

Solutions

• Verify the configuration: Confirm that the CDN configuration is set correctly and has taken effect.

• Purge the CDN cache: Use the CDN refresh feature to purge the cache, and then access the resource again. For more information, see Refresh and Prefetch Resources.

• Check origin server settings: Make sure that the origin server does not return cross-origin response headers that conflict with your CDN configuration. Use consistent CORS header settings on both your origin server and CDN.

• Clear browser cache: Clear your browser's cache, or test in incognito mode.

How do I troubleshoot ERR_CONTENT_LENGTH_MISMATCH errors during video playback?

• Cause: This error usually occurs because the file cached on a CDN node has a different length than the actual content on the origin server, or the origin server returns an abnormal Content-Length response header. This is common when a video file is updated on the origin server, but CDN still serves an old, cached version.

• Solution:

• On the Refresh and Prefetch page in the CDN console, submit a purge request for the video URL to clear the outdated cache from CDN nodes.

• If your origin server is OSS, you can enable automatic CDN cache refresh. This feature automatically triggers a CDN cache purge after a file on the origin server is updated.

• Check the stability and response consistency of your origin server to ensure it does not intermittently return an abnormal Content-Length.

• About status code 206: Video players typically use Range requests to load video content in segments. It is normal for CDN to return a 206 Partial Content status code, even if the request hits the CDN cache.

Static files hit the cache, but the homepage still loads slowly. Why?

Static resources (images, CSS, JS, etc.) are hitting the cache and being accelerated as expected, but the homepage (root path /) still takes several seconds to load. This usually happens because no caching rule is configured for the homepage request, which forces every visit to fetch data from the origin server. The loading speed then depends on the origin server's processing time.

Solution: Add a cache expiration time rule for the root directory of your accelerated domain name. This allows nodes to cache the homepage content and reduces the number of origin fetches.

• On the Cache Expiration tab, click Create Rule.

• Type: Select Directory.

• Object: Enter /.

• Expire In: Set a duration based on your homepage's update frequency, such as 30 seconds to several minutes.

• Weight: If other caching rules exist, set a low weight for this rule (such as 1) to prevent it from overriding the caching rules for static resources.

• Click OK to complete the configuration.

After the configuration takes effect, your homepage content is cached by nodes. Subsequent visits are served directly from a node, eliminating the need for an origin fetch on each visit and significantly improving homepage loading speed. For more information about cache expiration time configuration, see Configure CDN Cache Expiration Time.

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

This issue may occur if the Ignore URL Parameters feature is not enabled for your CDN service. For more information, see Low CDN cache hit ratio due to variable parameters in URLs.

What factors can decrease the cache hit ratio?

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

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

• Sudden bandwidth spikes: A sudden bandwidth spike can distribute requests across more CDN nodes, many of which may not have the content cached, leading to more origin fetches and a lower cache hit ratio.

• First-time requests for new content: If CDN nodes frequently receive first-time requests for new content, the number of origin fetches increases, which lowers the cache hit ratio.

• Caching rule adjustments: Modifications to CDN caching policies, such as setting inappropriate cache expiration times or misconfiguring caching rules, can lower the cache hit ratio.

• Variable parameters in URLs: If a URL contains parameters after a question mark (?), any variation in these parameters causes CDN to treat each unique URL as a different resource, lowering the cache hit ratio even if the requests point to the same content.

• Improperly configured cache expiration times: If you do not set appropriate cache expiration times for static files based on their update frequency, cached resources may expire prematurely, which reduces the cache hit ratio.

For more information about factors that affect the cache hit ratio, see Improve the CDN cache hit ratio. For specific configurations, see Refresh and Prefetch Resources, Ignore URL Parameters, and Configure CDN Cache Expiration Time.

How do I troubleshoot a low cache hit ratio, high origin-fetch rate, or saturated origin bandwidth?

• Check origin cache response headers: If the origin server returns Cache-Control: no-cache, Cache-Control: no-store, Cache-Control: max-age=0, or Pragma: no-cache, CDN by default follows the origin's directives and does not cache the resource. This forces an origin fetch for every request and is the most common cause of a low cache hit ratio and saturated origin server bandwidth.

• Enable Ignore Origin No-Cache Header: In the cache expiration time settings of the CDN console, select this option. When enabled, CDN ignores no-cache directives from the origin server, such as Cache-Control: no-cache, no-store, and max-age=0, as well as the Pragma: no-cache header. Instead, it caches content based on the rules configured in the console.

• Review the cache rule configuration: Check whether you have mistakenly set the cache expiration time for the root directory (/) to 0 seconds. If the root directory rule has the highest weight and a 0-second expiration time, all requests trigger an origin fetch.

• Optimize for large files: For large files such as videos, ensure that the Range origin-fetch feature is enabled. This prevents CDN from fetching the entire file from the origin server for every request.

• Differentiate between dynamic and static resources: Set a long cache duration (for example, one month) for static resources such as images, CSS, and JS files. Set the cache expiration time to 0 seconds to disable caching for dynamic content such as PHP or JSP pages.

Why do I see many 206 status codes or multiple origin fetches in the logs for video playback or large file downloads?

This is normal behavior.

• Status code 206: Video players and download tools typically use Range requests to load resources in segments. For each segmented request, the server returns a 206 Partial Content status code. CDN also returns a 206 status code when it serves a segment from its cache.

• Traffic costs: Any data transferred from CDN to a client is billed as outbound traffic, regardless of whether the request hit the cache.

• Optimization recommendations: Ensure that the Range origin-fetch feature is enabled. This allows CDN nodes to pull and cache segments from the origin server on demand, which improves the cache hit ratio for subsequent segment requests. Also, configure appropriate Cache-Control headers on the client or origin server to leverage the browser cache and reduce redundant requests.