Object Storage Service:Accelerate access to OSS with Alibaba Cloud CDN

Step 1: Add a CDN-accelerated domain name and configure the origin server

1. Log on to the CDN console and click Add Domain Name.

2. Set Region and Business Type. Enter the Domain Name to Accelerate. You can use a root domain (such as example.cn), or a custom subdomain (such as oss.example.cn). Using a subdomain simplifies management and expansion.

3. Add the origin server information as shown in the following figure. Set the origin URL to the domain name of the OSS bucket, then click Next to add the domain name.

   

Step 2: Configure a CNAME record

Use a DNS CNAME record to point your accelerated domain name to the CNAME address assigned by Alibaba Cloud CDN. This routes DNS queries for your domain to CDN POPs.

1. On the Recommended Features page, click Open Configuration Guide. Alternatively, return to the Domain Names page, hover over Pending Configuration to the right of the domain name, and click Open Configuration Guide in the tooltip that appears.

   

2. Copy the CNAME record value, such as example.cn.w.kunlunap.com. You will use this address for your DNS configuration.

3. Go to the Alibaba Cloud DNS console. For the target domain name, click Settings in the Actions column.

4. Click Add Record and enter the record information as described below. Keep the default settings for other parameters. If a CNAME record already exists, click Edit in the Actions column and update the value to the CNAME you copied.

   • Record Type: Select CNAME.

   • Hostname: If you are using a root domain like example.cn, enter @. If you are using a subdomain like oss.example.cn, enter the subdomain prefix, which is oss.

   • Record Value: Paste the CNAME record value you copied.

5. Click OK.

   The propagation time for DNS changes depends on the record's Time to Live (TTL) setting. It typically takes a few minutes to a few hours for the changes to fully propagate. The domain may be temporarily inaccessible after configuration. Wait for the changes to propagate, or try clearing your local DNS cache.

Step 3: Configure origin fetch for a private bucket

By default, new buckets are private. To allow Alibaba Cloud CDN to access a private bucket, you must authorize it by enabling private bucket access. If your bucket is public-read, this step is not necessary.

1. Go to the CDN console, click the target domain name, then click Origin Fetch in the navigation pane on the left.

2. Enable Alibaba Cloud OSS Private Bucket Access, as shown in the following figure.

   

Step 4: Verify the acceleration effect

After completing the configuration, run a comparison test to verify the performance improvement of the accelerated domain name.

1. Upload a file to the bucket

   On the Buckets page, click your bucket name. On the Objects page, click Upload Object. Select a static resource to upload, such as dest.jpg. Follow the on-screen prompts to complete the upload.

2. Obtain the file access URL

   • Default OSS access URL: On the Objects page, click View Details in the Actions column for the object. On the details page, click Copy Object URL.

     

   • CDN-accelerated access URL: Construct an access URL without a signature using the CDN-accelerated domain name and the file name. For example, http://example.cn/dest.jpg, where example.cn is the CDN-accelerated domain name.

3. Verify the acceleration effect

   Use a professional speed testing platform or tool, such as the CloudMonitor Synthetic Tests, to compare the loading times of the same file using the default OSS access URL and the CDN-accelerated access URL.

   Note

   The test data is for reference only. The improvement in access speed may vary due to different network environments, geographical locations, and other factors. During the first test, the acceleration effect may not be obvious because CDN POPs have not yet cached the resource and must perform an origin fetch to retrieve it. After the first test, wait for the CDN to cache the resource, and then test again to see the acceleration effect.

   

4. Check the cache hit status

   Use your browser's developer tools (F12) to check the value of the X-Cache field in the response headers. This value indicates whether the request hit the CDN cache.

   • If the value starts with HIT, the request successfully hit the CDN cache, and the acceleration was effective.

   • If the value starts with MISS, the request missed the CDN cache, and an origin fetch was sent to OSS to retrieve the resource.

Method 1: Independent subdomain architecture

Assign independent, semantic subdomains to buckets for different functions or resource types, and configure separate CDN acceleration for each subdomain. For example, use the subdomain img.example.cn for image resources and video.example.cn for audio and video resources. Semantic subdomains make resources easier to identify and maintain. They also enable DNS traffic distribution, which helps avoid single-domain connection limits.

This architecture completely isolates different types of resources, which lets you set and optimize cache policies, security configurations, and monitoring for each bucket independently:

• Configure a long-term cache policy for image resources to improve access speed.

• Enable range origin fetch for video resources to support resumable downloads.

• Enable URL signing for sensitive documents to ensure security.

An independent monitoring system accurately locates performance bottlenecks and unusual traffic. This enables fine-grained operational management and reduces the risk of interference between different services.

Method 2: Unified domain with path-based routing

If you have multiple buckets for different services or applications but want to provide a single, unified access point, configure a single CDN-accelerated domain name. Use the rules engine to route requests with different access paths to specific buckets. This approach unifies your brand image, simplifies domain name and SSL certificate maintenance, and reduces O&M complexity. The following example uses two buckets, cdn-bucket1 and cdn-bucket2, to explain the configuration.

1. Add path rules

   In the CDN console, click the target accelerated domain name. Then, click Rules Engine > Add Rule. Add two URL path rules to match http://example.cn/bucket1/* and http://example.cn/bucket2/* respectively, as shown in the following figure. In this example, example.cn is the accelerated domain name. bucket1 and bucket2 are virtual paths that point to cdn-bucket1 and cdn-bucket2 respectively. * represents the actual path of the object within the bucket.

   

2. Configure conditional origins

   In the Basic Information section for the accelerated domain name, configure two conditional origins. Attach the created path rules to their respective target bucket origin addresses. This ensures that requests are automatically routed to the correct origin based on the matching path rule.

   

3. Specify the origin host

   After configuring conditional origin routing, you must also specify the origin host for each origin server in the Origin Fetch configuration for the accelerated domain name. This ensures that origin requests are routed to the correct target bucket.

   

4. Rewrite the origin URL

   To ensure that the origin can correctly locate resources, you must rewrite the origin URL in the Origin Fetch configuration of the accelerated domain name. This rewrite automatically removes the virtual path used for routing (such as /bucket1) during origin fetch, so that the origin request path matches the actual storage path of the object in the bucket.

   

5. Verify the effect

   After the configuration is complete, you can use a single CDN-accelerated domain name to access resources in different OSS buckets based on different paths. This provides a unified entry point for multi-origin access.

   

Best practices

• Secure transmission: Enable HTTPS

  Configure an HTTPS certificate for your accelerated domain name and enable forced HTTPS redirection to encrypt data transmitted between clients and CDN POPs. HTTPS prevents data from being stolen or tampered with during transmission and avoids "Not Secure" warnings in browser address bars, enhancing user trust, brand image, and compliance with modern web security standards.

• Performance optimization: Configure comprehensive cache policies

  Cache policies are at the core of CDN performance. A well-designed cache policy should address both the cache duration and parameter handling to achieve optimal performance and functional compatibility.

  • Set TTL: By setting a reasonable cache period, you can maximize the cache hit ratio and significantly reduce the frequency of origin fetch requests and bandwidth costs.

    • Static files that are not updated frequently: For files such as images, audio, videos, and application installation packages, set a long cache period, such as one month or more, to reduce unnecessary origin requests.

    • Infrequently updated static files: For files such as JS and CSS, set the cache period to several hours or days based on your business update frequency. Use versioning (for example, style.v1.1.css) for release management.

    • Dynamic files or APIs: For files such as PHP and JSP, set the cache time to 0 seconds (no caching) to ensure that every request fetches the latest content.

  • Configure parameter handling to enable image processing: OSS provides image processing features, such as scaling, cropping, and watermarking. By default, CDN filters all parameters to maximize the cache hit ratio. This prevents image processing instructions, such as ?x-oss-process, from working. To use these features, go to the CDN console, navigate to Domain Names > the accelerated domain name > Performance Optimization, and modify the Ignore Parameters configuration.

• Ensuring availability: Use resource prefetch and automatic cache updates

  When caching is enabled, changes to origin files are not immediately propagated to CDN POPs. To ensure users can access the latest resources promptly and to maintain service stability during critical periods like a version release, we recommend the following strategies:

  • Resource prefetch: Before a version release or an operational activity, use the purge and prefetch resources feature of Alibaba Cloud CDN to distribute hot spot resources to global nodes in advance. This prevents a surge of origin requests from impacting the origin server when the content is published and ensures a smooth experience for users during their first access.

  • Auto CDN cache update: On the Bucket Settings > Domain Names page of the OSS console, enable Auto CDN Cache Update for the domain name. When you update an OSS file through an API, OSS automatically triggers a CDN refresh task, ensuring users can promptly access the latest content.

    Note

    This feature does not guarantee absolute real-time updates. For use cases with extremely high timeliness requirements, actively use the CDN refresh feature after updating a file.

• Cross-origin access: Configure a CORS policy

  Configuring CORS rules only at the OSS origin is unreliable for cross-origin requests. The CDN may cache and serve a response that lacks the necessary CORS headers, causing the browser to block the request. The recommended solution is to configure the Access-Control-Allow-Origin and other required CORS headers directly on the CDN. This ensures they are included in every relevant response, regardless of the cache status.

  1. On the CDN console, click the accelerated domain name or click Manage in the Actions column.

  2. On the Cache > Modify Outgoing Request Header page, configure the parameters and values for the response header as shown in the following figure.

     Note

     The parameter settings are for reference only. Adjust them as needed.

     

     After the configuration is complete, when you access OSS resources through a CDN POP, the response consistently includes the specified CORS headers. This ensures that cross-origin requests pass browser validation.

     

• Performance optimization: Improve efficiency for large files and data transfer

  • Enable range origin fetch: For use cases such as on-demand video/audio streaming and large file distribution, it is crucial to enable range origin fetch. It lets CDN POPs request parts of large files on demand. It not only enables advanced features such as seeking during video playback, but also significantly reduces unnecessary back-to-origin traffic and initial load times.

  • Optimize data transfer: Enable Gzip compression or HTML optimization in the CDN console to reduce the transfer size of text files, such as JS, CSS, and HTML, and improve transfer efficiency. Gzip compression compresses resources before they are returned, while HTML optimization automatically removes redundant content, such as comments and repeated whitespace characters, from HTML pages and embedded JavaScript and CSS.

    Note

    • Enabling HTML optimization or Gzip compression changes the Content-Length and Content-MD5 values of files. If your business logic relies on these values for verification, enable these features with caution.

    • If both HTML optimization and Gzip compression are enabled, the HTML optimization feature is ineffective. CDN only performs Gzip compression on the files.

• Seamless migration: Implement a zero-downtime domain switch

  When migrating an existing service from an OSS bucket domain to an accelerated domain dame, adopt a phased approach to ensure service continuity and stability.

  1. Preparation phase: Complete all configurations for the CDN-accelerated domain name and fully verify its functionality and performance in a test environment.

  2. Phased release phase (recommended during off-peak hours): Use a phased release approach to switch a portion of your service traffic to the CDN-accelerated domain name. Gradually increase the traffic to reduce switching risks.

  3. Verification phase: Closely monitor service access logs and error rates. Analyze key metrics such as response time and success rate to ensure that the phased release service is normal and the business is running smoothly.

  4. Full release phase: After thorough verification, switch all service traffic to the CDN-accelerated domain name to complete the domain name migration.

  5. Rollback plan: If you encounter any issues, have a plan to immediately roll back traffic to the original bucket domain. Analyze the root cause of the problem in detail before you redeploy.

Risk prevention

• Protecting against hotlinking and unauthorized access: Configure Referer-based hotlink protection and URL signing

  • Hotlink protection: Configure a Referer blacklist or whitelist to enable hotlink protection. This method validates the Referer field in the HTTP request header to prevent hotlinking, allowing access only from specified domains.

  • URL signing: When you enable private origin fetch for an OSS bucket, you grant CDN POPs direct access, bypassing OSS's native signature verification. This means that private resources can be publicly accessed through the CDN domain. To secure these resources, enable URL signing on the CDN. This feature requires requests to include a unique signature and timestamp, preventing unauthorized downloads and distribution.

• Ensuring origin connection security: Configure origin SNI and the origin host

  Ensuring stable and secure communication between Alibaba Cloud CDN and OSS is a key guarantee of service availability.

  • Configure origin SNI: You must configure origin Server Name Indication (SNI) in your CDN settings to match the origin host (typically the accelerated domain name). This is critical for secure connections to OSS.

    Without the correct SNI:

    • OSS cannot identify your domain during the TLS handshake and will serve a default certificate, causing a certificate mismatch error and connection failure.

    • OSS may treat your requests as unidentified traffic and apply stricter throttling, impacting performance.

  • Hide origin information

    By default, CDN uses the bucket domain name for origin fetch. When an origin fetch error occurs (for example, the file does not exist), the error message may expose the OSS bucket domain name, which poses a security risk.

    

    To hide the origin information and enhance security, follow these steps to change the origin host to the CDN-accelerated domain name:

    1. On the Buckets page, click the target bucket name. Then go to Bucket Settings > Domain Names, and map the accelerated domain name to the bucket.

       

    2. In the CDN console, click the target accelerated domain name. Then go to Origin Fetch > Default Origin Host, click Modify and change the domain name type to Accelerated Domain Name.

• Auditing and troubleshooting: Enable access logs For security auditing, performance analysis, and troubleshooting in a production environment, you must enable comprehensive logging. Configure real-time log delivery in the CDN console to send access logs to Simple Log Service (SLS). With SLS, you can perform in-depth analysis and set up alerts on key metrics, including access behavior and traffic distribution, popular resources and content, and error rates and request failures. This data is essential for optimizing performance and enhancing security.

Why do 5xx errors occur during CDN origin fetch?

A 5xx error indicates that CDN failed to retrieve the resource from the OSS origin. Check the following aspects to troubleshoot the issue:

• Origin configuration: Check whether the OSS origin address configured in the CDN console is correct.

• Origin protocol policy: If CDN is configured for HTTPS origin fetch or origin protocol policy, ensure that the origin supports HTTPS access and the SSL certificate is configured correctly.

• Network link: Test the network connectivity from the CDN POP or your local machine to the OSS origin. CDN POPs are on the Internet, so the origin configured for CDN must be accessible over the Internet. If the origin IP address is not reachable from the Internet, the port is closed, or the origin domain name is not resolved, CDN origin requests to the origin server fail.

• Origin server pressure: On the CDN real-time monitoring page, check for a sudden increase in bandwidth and traffic. Many back-to-origin requests can cause excessive origin server pressure, which leads to back-to-origin response timeouts. For hot spot resources, you should perform resource prefetch and set a reasonable cache period when the resources are published.

Why do I get a 403 Forbidden or You are forbidden to list buckets error when accessing a static page accelerated by CDN?

Cause analysis: This issue usually occurs after you enable CDN acceleration for a private bucket that is configured for static website hosting. The root cause is a conflict between two access mechanisms:

• CDN private origin fetch: When CDN performs an origin fetch to OSS, it carries signature information for identity verification.

• OSS static website hosting: Its default index page feature (for example, automatically returning index.html when accessing /) requires that access requests must be anonymous.

When a user accesses the root directory of the accelerated domain name, CDN initiates a signed request to access the bucket's root directory. When OSS receives this signed request, it does not trigger the static website hosting logic because the request is not anonymous. Instead, it attempts to perform a ListObjects (list files) operation. Because access policies usually prohibit this type of operation, a 403 Forbidden error is returned.

Solution: Bypass the static website hosting feature of OSS and achieve the same result by configuring URL rewrite rules directly on the CDN.

• Path To Rewrite: ^/$ (matches root directory access)

• Target Path: /index.html (or the actual file name of the index page)

• Set Execution Rule to Redirect.

Can I upload files to OSS through a CDN domain name?

For security reasons, do not upload files to OSS through a CDN domain name. If your CDN allows write methods (such as PUT and POST), anyone can upload files to OSS through CDN without identity verification or authorization. This makes your service vulnerable to malicious uploads and data tampering attacks. Upload files using the OSS domain name and following the principle of least privilege.

Will OSS outbound traffic decrease after using CDN acceleration?

Yes, significantly. When requests are served from the CDN cache instead of your OSS bucket, it reduces your OSS outbound traffic. This is most effective for frequently accessed content, such as popular images, downloads, or website assets.

A higher cache hit ratio directly translates to lower origin traffic and greater cost savings.

How can I count the actual number of times a file is accessed?

After CDN acceleration is enabled, OSS access logs cannot record end-user access requests that are directly served by the CDN cache. You can count the actual number of file accesses in the following ways:

• Log data within 30 days: You can download the CDN offline logs to view and analyze them.

• Log data older than 30 days: After you configure real-time log delivery in CDN, you can view and analyze the data on the CDN Data Statistics page.