All Products
Search

This Product

    CDN:Purge and prefetch FAQ

    Document Center

    CDN:Purge and prefetch FAQ

    Last Updated:Jun 25, 2026

    This topic answers frequently asked questions (FAQ) about purge and prefetch operations in Alibaba Cloud CDN. It covers the differences between purge and prefetch, the recommended order of operations, quotas, troubleshooting, browser cache conflicts, same-name updates, and M3U8 prefetching.

    Purge vs. prefetch

    Purge and prefetch are two distinct operations:

    • Purge: Instructs edge nodes to mark cached resources as expired. When a user requests the resource again, the edge node performs an origin fetch to retrieve the latest version, delivers it to the user, and re-caches it. A purge operation temporarily lowers the cache hit ratio.

    • Prefetch: Proactively loads resources from your origin server to edge nodes. When a user first requests the resource, a nearby edge node serves it directly, eliminating the need for an origin fetch. A prefetch operation increases the cache hit ratio.

    Purge and prefetch order

    Purge and prefetch are independent operations with no strict order. However, when updating a resource on your origin server, we recommend following this logical sequence:

    • Purge first: Purge the old content from the CDN cache to ensure subsequent requests retrieve the latest version from the origin server.

    • Then prefetch: After the purge task is complete, prefetch the updated content to the edge nodes. This ensures users can access the new content with minimum latency.

    • First-time CDN integration: If content is not yet cached on the edge nodes, you can directly prefetch resources to warm up the cache.

    Origin URL vs. accelerated domain URL

    Always use the URL that contains the accelerated domain, not the URL of your origin server. The Alibaba Cloud CDN system identifies and manages cached resources by their accelerated domain. Submitting a purge or prefetch request for a URL under an accelerated domain ensures that the content cached on edge nodes is correctly updated or preloaded.

    Purging wildcard domains

    Alibaba Cloud CDN does not support purging all cached content under a wildcard domain in a single operation. You must submit separate purge requests for specific subdomains, directories, or URL paths. You cannot use patterns like https://*.example.com/file01.html or https://*.example.com/file02/. If you need to purge multiple URLs, enter one URL per line.

    Purge and prefetch effective time

    • Purge task: A purge task typically propagates across the entire network in about 5 to 6 minutes. If a resource's configured TTL is shorter than this, a manual purge is not necessary.

    • Prefetch task: The time required depends on the size and number of files, but it typically takes 5 to 30 minutes to complete.

    Applying CDN configuration changes

    Changes to CDN configurations, such as the origin Host, caching rules, or response headers, typically apply only to new requests. If an edge node has already cached old response headers or content, the edge node will not apply the new configuration to that cached content. To make your changes take effect immediately, you must manually purge the cache for the corresponding URLs or directories. This forces the edge nodes to perform an origin fetch and retrieve the resource with the new configuration.

    For example, after you modify a response header or TTL, go to the Cache Refresh page in the CDN console. Enter the URLs or directory paths that you want to purge and submit the request. If a configuration change causes a Content-Type mismatch, first correct the metadata on your origin server, and then purge the affected URLs.

    Custom headers in prefetch requests

    By default, prefetch requests include the Accept-Encoding: gzip header. To include other headers in a prefetch request or to perform a multi-replica prefetch, you can use the OpenAPI.

    Same-name file updates

    Follow these best practices when updating files accelerated by CDN:

    • For general file updates, we recommend adding a version number to the resource URL, such as ?v=1.0. This avoids caching issues related to same-name updates.

    • If you must perform a same-name update, submit a purge request from the console or by using the OpenAPI. For console operations, see Purge and prefetch resources. For OpenAPI operations, see Purge and prefetch.

    JS/CSS update issues

    Browsers and the CDN cache specific JS and CSS file URLs. If you update the content of a file but not its name, or if you change the filename but do not update the reference in your HTML, purging only the home page may not be enough. The user's browser or the CDN may still serve the old version of the sub-resources from cache.

    Recommendations:

    • Purge the specific URLs of the JS/CSS files, not just the home page.

    • As a best practice, add version parameters to resource URLs, such as ?v=1.0, to avoid caching issues caused by same-name updates.

    • If a same-name update occurs on the origin server, manually purge the cache for the corresponding URL in the CDN console. Wait a few minutes after the purge task is complete, and then test again in an incognito window.

    Troubleshooting content updates

    Possible causes: This can happen for several reasons:

    • Although the purge task cleared the CDN cache, your browser is still serving an old version of the resource from the local browser cache.

    • The resource on the origin server has not been updated.

    • The purge or prefetch task has not completed yet.

    • When you perform a directory purge, CDN marks the objects as expired by default. During the next origin fetch, CDN includes an If-Modified-Since or If-None-Match header in the request. If the Last-Modified or ETag of the same-name file on the origin server has not changed, the origin server returns a 304 Not Modified status code, and CDN continues to serve the old content.

    Solutions: Try the following solutions based on the cause:

    • Clear your browser cache and refresh the page to see if the resource is updated. You can also test by using an incognito window or a different browser.

    • Point your domain directly to the origin server by modifying your local hosts file. Then, access the origin server directly to check if the resource is updated. If not, update the resource on your origin server before accelerating it with CDN.

    • Check the task status on the Purge and prefetch resources page.

    • Perform a URL purge (File type) to delete the cache for a specific file. Alternatively, call the RefreshObjectCaches API and set the Force parameter to true. This performs a forced purge, which immediately deletes the content from edge nodes instead of just marking it as expired.

    On the Cache Refresh page, click the Operation Records tab. Verify that the task Status is Succeeded and the Progress is 100% to confirm completion.

    Prefetch download speed issues

    A prefetch task triggers simultaneous downloads from your origin server to multiple edge nodes. The download speed from a single node may be fast initially, but as more nodes start to download, the overall speed becomes limited by the bandwidth of your origin server. For origin servers with low bandwidth, prefetch tasks will take longer. Evaluate your origin bandwidth and increase it if necessary, or split large prefetch jobs into smaller batches.

    Effect of 30X redirects on prefetch

    If your origin server returns a 307 or other redirect-related status code during a prefetch, the prefetch task will not follow the redirect, and the task will fail. If the origin server returns a 301 or 302 status code and you have enabled 301/302 redirect following in CDN, the CDN will follow the redirect, allowing the prefetch task to complete successfully.

    Stale content or 404 errors

    CDN edge nodes may have an old version of a resource cached. Even if the file on the origin server has been deleted or updated, the cached version may still be served. To resolve this:

    1. Perform a purge operation for the specific URL in the CDN console or by using the API.

    2. If the issue is caused by a directory-level caching policy, purge the entire directory. To ensure the content is completely removed, call the RefreshObjectCaches API and set the Force parameter to true to perform a forced purge.

    3. Confirm that the file has actually been updated or deleted on the origin server.

    Troubleshooting prefetch failures

    If a prefetch task fails, check the following items:

    1. Check URL accessibility: Confirm that the URL you want to prefetch is accessible in a browser and returns a 200 status code. If it returns a 308 or other redirect status code, prefetch the correct URL that ends with a forward slash (/).

    2. Ensure you are not prefetching a directory: Prefetching is supported only for specific file URLs, not for directory paths that end with a /.

    3. Check for conflicts with OSS dynamic acceleration: If your origin is an OSS bucket and you have enabled dynamic acceleration, static files may bypass the cache path. Disable dynamic acceleration or specify the static file types to be cached.

    4. Check the URL format: URLs must start with a full protocol header (http:// or https://) and must not contain illegal characters, such as full-width characters or extra spaces. Separate multiple URLs with line breaks, not commas.

    5. Check if the resource is cacheable: Ensure that the resource you want to prefetch does not have headers like Cache-Control: no-cache/no-store/private, which prevent caching.

    HTTP and HTTPS task handling

    No. Alibaba Cloud CDN treats HTTP and HTTPS versions of a URL as the same resource for caching. A purge or prefetch request for one protocol applies to both. For example, if you need to prefetch the file aaa.mp4, you only need to prefetch https://example.com/aaa.mp4. You do not need to also prefetch http://example.com/aaa.mp4.