CDN:Traffic throttling troubleshooting guide

Symptom: After you save a throttling rule on the Traffic Throttling for Individual Requests tab, the client download rate remains unchanged, and throttling appears not to take effect.

Cause: CDN throttling configurations usually take effect immediately. If throttling does not take effect during testing, check the following causes:

• Browser cache: The browser may use a local cache instead of sending a new request to a CDN node. We recommend that you clear the browser cache or use a different browser to test.

• Segmented downloads (Range requests): If the client uses a browser or tool that supports segmented downloads, each segment request is treated as an independent new request and the throttling threshold is recalculated, which can make throttling appear ineffective.

• Check response headers: Check the response headers of the request to confirm whether the throttling policy was applied.

  For the parameter meanings and configuration steps for single-request throttling rules, see Configure single-request throttling.

Symptom: A CDN-accelerated domain name is repeatedly taken offline automatically or suddenly cannot be accessed. DNS resolution may point to an invalid address such as offline.*.kunlun*.com. The domain name status is displayed as Disabled in the CDN console domain name list.

Troubleshooting steps: If a CDN domain name is frequently taken offline automatically or suddenly becomes inaccessible, troubleshoot the issue as follows:

• Check the usage cap configuration: Log on to the CDN console. On the Domain Names page, find the target domain name, and then choose Traffic Throttling > Usage Cap to check whether bandwidth, traffic, or HTTPS request-count cap policies are configured and whether a threshold was triggered. Use operation records to confirm whether cap trigger records exist. If a low threshold causes frequent offline events, increase the threshold based on your business needs or delete the usage cap configuration.

• Check legacy bandwidth cap rules: Confirm whether legacy bandwidth cap rules (CloudMonitor alert rules) conflict with the new usage cap policy.

• Investigate unusual traffic: If unusual traffic is confirmed to be an attack, view offline logs in the console or enable Operations Reports to analyze Top IP and Top Referer sources. If you identify unusual IP addresses, configure IP blacklists and whitelists. If malicious requests have an empty Referer, configure Referer-based hotlink protection. For more mitigation policies, consider using WAF features of Edge Security Acceleration (ESA).

Symptom: The usage cap configuration was deleted or disabled, but the domain name still shows as Disabled in the CDN console domain name list, or is automatically taken offline again after the unblocking time is reached.

Cause: If a domain name remains offline after you delete or disable a usage cap configuration, check the following causes:

• The usage cap configuration was not completely deleted: Confirm that the usage cap configuration has been deleted. On the Usage Cap tab, find the corresponding cap policy, click Delete, and then click OK in the confirmation dialog box. For the complete steps to delete a configuration, see Configure a usage cap.

• Conflict with legacy bandwidth cap rules: A domain name may also have legacy bandwidth cap rules (CloudMonitor alert rules) configured. When a legacy rule is triggered, it also takes the domain name offline. Legacy rules cannot be modified directly and can only be deleted. Log on to the CloudMonitor console to check for and delete the legacy bandwidth cap rules. Retain only the new usage cap configuration.

• The domain name requires manual enabling: After a domain name is taken offline, manually enable it in the CDN console or wait until the configured unblocking time is reached to restore access.