CDN provides a self-diagnosis tool to help you troubleshoot URL access failure. The self-diagnosis process includes detection of DNS resolution, linkage quality, node status, origin server, and data access consistency, enabling you to identify problems and offering relevant solutions.
The resource URL to be diagnosed should be an activated domain name under your account. The bandwidth incurred in the diagnosis process is billable bandwidth. We recommend the diagnosed resource to be no more than 200 MB in size.
If a resource URL cannot be accessed, you can initiate diagnosis through Fault Diagnosis in the following steps:
Log in to the CDN Console and select Inspect Tool > Fault Self-diagnosis.
On the Fault Self-diagnosis page, enter the URL to be diagnosed. The URL should begin with
Click Get a diagnosis link and the link address will appear on the page.
Click the link to open the diagnosis page where diagnosis information will be collected. Do not close the page during the diagnosis progress. You can manually close it after the diagnosis is completed.
You can also send the diagnosis link to others for local fault diagnosis. After the diagnosis is completed, you need to close the webpage manually.
- The diagnosis link is valid for 24 hours and supports up to 10 fault diagnoses.
- You can copy the available diagnosis links on the Diagnostic Report page.
After the diagnosis is completed, click Diagnostic Report to view the reports, which are displayed in a table in chronological order. The contents in the table include:
The URL for which a diagnosis link is generated.
The diagnosis link corresponding to the URL.
Time when the diagnosis link was generated.
A countdown to the expiration of the diagnosis link.
Number of remaining available diagnoses of the diagnosis link.
Click Expand in the operation column to view the report generated by each diagnosis and the diagnosis results.
The diagnostic reports will make an overall assessment based on the diagnosis for each step as shown below:
Click View Report to view the diagnosis details and suggestions.
The first part of the report displays diagnosis information, including:
Diagnostic report ID.
URL to be diagnosed.
Time when diagnosis was triggered.
The second part gives an overview of the diagnosis process and the results of each diagnosis module. Exceptional modules are clearly identified. Diagnosis modules include:
Client information detection result.
DNS detection result.
CNAME detection result.
Network linkage detection result.
Access node detection result.
Origin-pull node detection result.
Origin server detection result.
The third part elaborates on the diagnosis results.
Information such as client IP, district/ISP, and User-Agent, Referer, and Request Mode of the initiated HTTP/HTTPS request are obtained. Without client information, some subsequent detections cannot be conducted.
The client's DNS IP is collected and checked against the client IP, to determine whether exceptions in local DNS configuration are causing issues in scheduling requests to the optimal cache nodes.
The CNAME configuration of the domain name is obtained. The CNAME resolution of the domain name needs to be configured with the correct domain name suffixed with *.cdn.dnsv1.com (default); otherwise, requests will be unable to reach CDN nodes.
If CNAME configuration detection fails, the requests will not reach CDN nodes and subsequent diagnoses will not be conducted.
Multiple websites are checked locally to obtain the client's network status. If a website cannot be accessed due to local proxy configuration, the network linkage detection will fail, and subsequent diagnoses will not be conducted.
After a client request reaches a CDN node, node information will be collected, including node IP, node district/ISP, status code returned by node, hit status, and resource MD5.
If a resource has already been cached on a CDN node, it will directly be hit, and origin-pull node detection will not be conducted.
In case of a cache miss, origin-pull node detection will ensue.
If the status code returned by the URL is 301, 302, or 504, node detection information will not be obtained, and the subsequent detection will not be conducted.
If an ACL has been configured for the domain name, the access node will directly return 403, and the hit status is hit.
If the resource is directly returned by a CDN node, the hit status of both the access node and the origin-pull node is hit, and CDN will proceed to detect the origin server to help check whether the status codes and contents returned from the origin server are the same as those of the node.
If the resource is not directly returned by a CDN node, the hit status of both the access node and the origin-pull node is missed, and the contents will be returned by the origin server.
If an exceptional status code is generated at this time, you can compare the origin server status code and file MD5 value against those returned by the access module to determine whether the exception is caused by a CDN node or by the origin server, and then fix the problem accordingly.
If the diagnostic report cannot help you solve the problem, please submit a ticket or contact Tencent Cloud technical support.