tencent cloud

CDN provides a self-diagnostic tool to help you troubleshoot URL access failure. It locates the problem by checking the DNS resolution, linkage quality, node status, origin server, and data access consistency, and offers relevant solutions.

Note：

The resource URL to be diagnosed should be an activated domain name under your account. As the bandwidth generated during the diagnosis incur charges, we recommend the diagnosed resource being no more than 200 MB in size.

Fault Diagnosis

Diagnosis process

If a resource URL cannot be accessed, you can initiate diagnosis through Fault Self-diagnosis in the following steps:

1. Log in to the CDN console and select Inspect Tool -> Fault Self-diagnosis.
2. On the Fault Self-diagnosis page, enter the URL to be diagnosed. The URL should begin with http:// or https://.
   
3. Click Get a Diagnosis Link and the link address will appear on the page.
   
4. 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.
   
5. 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.

Note：

• 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.

Diagnostic Report

Viewing the report

1. 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 target area of the URL diagnosis.
   • The diagnosis link corresponding to the URL.
   • The time when the diagnosis link was generated.
   • The status of the diagnosis link.
   • The number of remaining available diagnoses of the diagnosis link.

2. Click Expand in the operation column to view the report generated by each diagnosis and the diagnosis results.
   
3. The diagnostic reports will make an overall assessment based on the diagnosis for each step as shown below:
   • Normal
   • Abnormal
   • Page abnormally closed. This happens generally when the page is closed before the diagnosis is completed.
4. Click View Report to view the diagnosis details and suggestions.

Report interpretation

1. The first part of the report displays diagnosis information, including:

   • Diagnostic report ID.
   • URL to be diagnosed.
   • Time when the diagnosis was triggered.
     

2. 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 check result.
   • DNS check result.
   • CNAME check result.
   • Network linkage check result.
   • Access node check result.
   • Origin-pull node check result.
   • Origin server check result.
     

3. The third part elaborates on the diagnosis results.

   Section 1. Client information

   Information such as client IP, district/ISP, and User-Agent, referer, and request method of the initiated HTTP/HTTPS request are obtained. Without the client information, some subsequent checks cannot be conducted.
   

   Section 2. DNS check

   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.
   

   Section 3. CNAME check

   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.
   

   Note：

   If CNAME configuration check fails, the requests will not reach CDN nodes and subsequent diagnoses will not be conducted.

   Section 4. Network linkage check

   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 check will fail, and subsequent diagnoses will not be conducted.
   

   Section 5. Access node check

   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 check will not be conducted.
   • In case of a cache miss, origin-pull node check will be conducted.
   • If the status code returned by the URL is 301, 302, or 504, node check information will not be obtained, and the subsequent checks 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.
     

   Section 6. Origin-pull node check

   1. 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 check 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.
      
   2. 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.
      
   3. 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.

Note：

If the diagnostic report cannot help you solve the problem, please submit a ticket or contact Tencent Cloud technical support.