All Products
Search
Document Center

CDN:Origin fetch FAQ

Last Updated:Aug 26, 2026

This topic answers consultation-type questions about the origin fetch feature. For troubleshooting questions, see the Origin fetch troubleshooting guide.

How do I verify that response headers such as Access-Control-Allow-Origin are correctly configured on my origin server?

The verification method depends on the type of your origin server:

  • Alibaba Cloud ECS as the origin server: Check whether CORS response headers such as Access-Control-Allow-Origin are correctly configured in the web server configuration files. For Apache, check the Header set Access-Control-Allow-Origin directive in .htaccess or httpd.conf. For Nginx, check the add_header Access-Control-Allow-Origin directive in the server block. After you modify the configuration, restart the web server for the changes to take effect.

  • Alibaba Cloud OSS as the origin server: Log on to the OSS console, click the target bucket in the bucket list, and then choose Data Security > Cross-Origin Resource Sharing (CORS) in the left-side navigation pane. Check whether Sources in a CORS rule includes the domain name that initiates the cross-origin request (this field determines the value of the Access-Control-Allow-Origin response header), and verify that the allowed request methods and other settings are correct. For more information about OSS CORS configuration, see CORS.

After the configuration is complete, access the resource and use the Network panel of your browser's developer tools to check whether the response headers contain Access-Control-Allow-Origin. Alternatively, use the curl -I command to view the response headers directly.

If I globally force Content-Type to be video/mp4, will other resources be affected? How do I configure it precisely?

If you globally set Content-Type to video/mp4 for an entire domain name, all resource types under the domain name are affected, including images, CSS, and JS files. To avoid affecting other files, use the following methods for precise configuration:

  1. Match by path: When you add a rule on the Modify incoming response headers page, associate the Rule Condition with a rule that matches the video paths (for example, /vod-cd20e3/ or the .mp4 suffix), so that the configuration takes effect only for video paths. To add and manage rule conditions, see Rules engine.

  2. Use conditional matching: The CDN console allows you to configure response headers based on request suffix or header conditions. You can limit the configuration so that Content-Type: video/mp4 is returned only for .mp4 files.

By using the preceding methods, you can modify Content-Type only for video files without interfering with other resource types such as images.

Does the Modify incoming response headers feature support settings for JS files only? Does the setting affect other file types?

Yes. You can use Modify incoming response headers to set Content-Type to application/javascript for JS files only, without affecting other file types.

Method: When you configure the rule, use a rule condition to match the .js suffix so that the response header modification rule takes effect only for JS files. This ensures that the MIME type of JS files is correct without interfering with other resource types such as CSS and images.

Can the Modify incoming response headers configuration be used to check for missing files or synchronization status in CDN?

No. Modify incoming response headers is used to correct or force the MIME type of specific file types, in order to resolve caching issues caused by the origin server initially returning an incorrect type. This feature does not detect whether files are missing in CDN, nor does it determine file synchronization status.

To check whether a file exists in CDN or whether its synchronization status is abnormal, use the following methods:

  • Use the Refresh and Prefetch feature in the CDN console to refresh (URL refresh) the target file, which forces the CDN node to fetch the file from the origin again. Then access the file again and determine whether the file exists on the origin based on the returned status code. For example, a 404 response indicates that the file does not exist on the origin.

  • Check whether the file on the origin side is accessible normally.

  • Check CDN logs to verify that the origin fetch status codes are normal.