Origin fetch FAQ

After setting the origin protocol to HTTPS, the website becomes inaccessible and returns a 502 error. How do I resolve this?

• Check whether the origin server supports HTTPS access. Open https://Origin Domain Name directly in your browser to verify that the origin server responds correctly. If the origin server does not support HTTPS, change the origin protocol to HTTP.

• Check whether the origin port matches the HTTPS listening port on the origin server. The default origin port is 443. If the origin server uses a custom HTTPS port, configure the corresponding HTTPS port (1–65535) in the Static Origin Protocol Policy dialog box.

• Check the origin HOST and origin SNI settings. If the origin IP address is bound to multiple domain names, configure origin SNI to specify the exact domain name being requested, and set the origin HOST to the origin domain name.

• Check the validity of the SSL certificate on the origin server. If the SSL certificate has expired or does not match the domain name, the CDN node fails validation and returns a 502 error. Update the SSL certificate on the origin server.

• For a more detailed troubleshooting guide, see the “FAQ” section in the Configure origin protocol document.

After the origin server is configured to redirect HTTP to HTTPS, CDN origin fetch causes a redirection loop. How do I resolve this?

Symptom: The website returns an error such as “Too many redirects” or “ERR_TOO_MANY_REDIRECTS.”

Cause: The origin server enforces HTTP-to-HTTPS redirection (returning a 301 status), but the CDN uses HTTP for origin fetch. After receiving the 301 response, the CDN retries the request over HTTP, creating an infinite redirection loop.

Solution:

1. Change the CDN origin port to 443 and set the origin protocol to HTTPS.

2. If the origin server listens on multiple domains, configure both origin SNI and origin HOST to use either the accelerated domain name or the origin domain name.

3. Perform the cache purge steps described in Solution for too many redirects.

When CDN uses an IP address to fetch content from a Server Load Balancer (SLB) that has an SSL certificate and redirects port 80 to 443, will there be certificate issues or other impacts?

If the CDN performs origin fetch using the public IP address of the SLB and the SLB redirects port 80 to 443, set the CDN origin protocol to HTTP (fetching from port 80 on the SLB) to avoid certificate validation issues. If you must use HTTPS for origin fetch, ensure that origin SNI is enabled and that the Common Name whitelist includes the certificate’s domain. Otherwise, validation may fail due to missing SNI or a domain mismatch.

What does the Common Name whitelist validate?

During origin fetch, the system validates the SNI value in the origin request from the CDN node against the Common Name in the certificate returned by the origin server. These values must match for origin fetch to succeed.

If you do not modify the origin SNI, the CDN node uses the accelerated domain name as the default Host value in the origin request. Therefore, the system validates the Common Name of the certificate for the accelerated domain name.

How do I configure a custom port for HTTPS origin fetch?

1. Log on to the CDN console.

2. In the left navigation pane, click Domain Names.

3. On the Domain Names page, find the target domain name and click Manage in the Actions column.

4. In the domain's navigation pane, click Origin Fetch.

5. In the Origin Protocol Policy section, turn on the Origin Protocol Policy switch.

6. Click Modify.

7. Configure the custom port as needed.

CDN uses HTTP or HTTPS for origin fetch after enabling HTTPS on the accelerated domain?

Configuring an HTTPS certificate on CDN does not affect the origin protocol. By default, the origin protocol depends on the origin port configured in Configure origin server:

• If the origin port is set to 443, origin fetch uses HTTPS.

• If the origin port is set to 80 or another value, origin fetch uses HTTP.

To specify the origin protocol explicitly, configure the origin protocol as needed.

After enabling CDN acceleration, the origin server still listens on port 80. Should I keep it open? Will disabling it affect CDN service?

Before disabling port 80 on the origin server, confirm the following:

• The origin protocol for the accelerated domain name is already set to HTTPS (using port 443).

• No other services or processes on the origin server depend on port 80 (such as a web server or HTTP redirection).

If the origin protocol is still HTTP or “Follow Client,” disabling port 80 will cause CDN origin fetch to fail. You can check the current origin protocol under Domain Names > target accelerated domain name > Origin Fetch.

When the origin protocol is set to “Follow,” origin fetch fails because the origin server does not support HTTPS. How do I resolve this?

Cause: When the origin protocol is set to “Follow,” and the client accesses the CDN over HTTPS, the CDN performs origin fetch over HTTPS. If the origin server does not support HTTPS, the request fails.

Solution:

• Option 1: Change the origin protocol from “Follow” to “HTTP.” The CDN will always use HTTP for origin fetch.

• Option 2: Configure an SSL certificate on the origin server to ensure it supports HTTPS access.

For details, see the Configure origin protocol document.

When accessing OSS resources through CDN, the error You have no right to access this object because of bucket acl. appears. How do I resolve this?

The OSS bucket is configured in private mode (which enforces access authentication and prevents unauthorized traffic consumption). In this case, enable the Private OSS bucket origin fetch feature for the accelerated domain name to resolve this error and allow CDN to accelerate resources from a private OSS bucket.

When accessing OSS resources through CDN, the error This request is forbidden by kms. appears. How do I resolve this?

If your OSS bucket uses Key Management Service (KMS) for encryption, grant the CDN origin role additional permissions to use KMS keys. Otherwise, CDN cannot decrypt and access these files, resulting in the error This request is forbidden by kms.

1. Log on to the RAM console.

2. In the left-side navigation pane, choose .

3. In the Role Name list, find and click the AliyunCDNAccessingPrivateOSSRole role.

4. Click Add Authorization. The Principal is automatically populated.

5. Under Policies, select System Policies, search for and click AliyunKMSCryptoUserAccess to add it to the Selected Policies box.

6. Click Confirm New Authorization. A message indicates that the operation is Completed.

7. Click Disable.

8. Use the refresh and prefetch feature to clear the cache. After the refresh task is complete, try to access the resource again.

How do I use STS to enable cross-account origin fetch from a private OSS bucket?

By default, CDN uses Security Token Service (STS) temporary security tokens to fetch content only from private OSS buckets under the same Alibaba Cloud account. To enable cross-account origin fetch using STS, add a Bucket Access Policy in OSS as follows:

1. Log on to the Alibaba Cloud account that owns the private bucket and go to the OSS console.

2. Click Buckets > Target Bucket. On the Permission Control > Bucket Policy tab, click Authorize.

   

3. Set Authorized User to Other Accounts. In the ARN field, enter the value based on how CDN accesses the private OSS bucket:

   • Direct STS authorization: Enter arn:sts:{CDN account UID}, where {CDN account UID} is the Account ID of the CDN account.

   • AssumeRole (role assumption): Enter arn:sts::{CDN account UID}:assumed-role/{CDN account role name}/*, where {CDN account UID} is the Account ID of the CDN account, and {CDN account role name} is the name of the RAM role assumed by CDN.

   For Authorized Operation, choose Simple Settings > Read-Only (excluding ListObject), then click OK to complete the configuration.

   

4. After successful configuration, you can view the authorization information on the Bucket Policy tab.

   

After configuring a CNAME for the accelerated domain name, origin fetch fails. How do I troubleshoot this?

After adding a CNAME record for the accelerated domain name, if CDN nodes fail to perform origin fetch, the issue is usually caused by DNS resolution errors, origin server misconfiguration, or incorrect CDN origin fetch parameters. Troubleshoot as follows:

1. Verify that the CNAME resolution has taken effect.

   Run ping accelerated domain name or nslookup accelerated domain name. If the result contains .*.kunlun*.com, the CNAME resolution has taken effect. If the result still shows the origin IP address or fails to resolve, check your DNS record configuration.

2. Check the CNAME record type and conflicts.

   The record type must be CNAME. Using any other record type causes resolution to fail. A single host record cannot have both a CNAME record and other record types. Delete conflicting records and reconfigure.

3. Verify origin server reachability.

   Use curl -I http://origin IP address or domain name to check whether the origin server responds correctly. Ensure the origin server is running and accessible from external networks.

4. Check the origin server’s IP whitelist for origin fetch.

   CDN nodes use specific IP ranges for origin fetch. If the origin server has an IP whitelist or firewall rule, add the CDN origin IP ranges to the whitelist. Otherwise, the origin server rejects CDN origin requests.

5. Check the origin protocol and port configuration.

   Ensure the origin protocol (HTTP or HTTPS) configured in CDN matches what the origin server supports, and that the origin port matches the actual listening port on the origin server. If the origin server uses HTTPS on a non-standard port, configure a custom origin port in CDN.

Is it normal for the Server response header of a CDN-accelerated domain name to show AliyunOSS?

No. This indicates that the request bypassed the CDN node and accessed the OSS origin server directly. Check and correct your DNS resolution configuration to ensure the domain name resolves only to the CNAME record provided by CDN.

When CDN origin fetch returns a 5XX error, does subsequent access return the error page or retry the origin request?

By default, CDN does not cache responses with 5XX status codes. Therefore, on subsequent requests, CDN retries the origin request instead of returning the previous error page.