UCDN Debugging Guidance

Introduction

In this article, we would like to share with you some tips that may assist you in debugging CDN. These troubleshooting suggestions will help you with collecting useful data, which is the most important thing you want to do when you believe you may have an issue with your content delivery network service.

Basic Checks

Verify that your CDN service is active by gaining access to your account at https://my.ucdn.com/.

If your account has been suspended you’ll see a message like the one above. You need to contact us at https://ucdn.com/#contacts for information about the reason for suspension and for reopening the account.

Verify that the content to cache is available on the origin server (if the content is stored at your server) and if it’s accessible on the Internet. The fastest way to do that is to open a browser in a private or incognito mode and browse directly to the file. Type or paste the URL into the address bar and verify that it results in the file you expect. You can verify what is the origin location specified for your zone with us by clicking on “My Zones”, then click on and navigate to “Main settings” tab in https://my.ucdn.com

Verify that your zone alias (CNAME) is correctly configured. You need to verify that your zone alias (e.g. cdn.example.com) points to your CDN zone URL (e.g. 11131-7.b.cdn12.com). You can verify what zone alias you specified by navigating to the “Domain name (CNAME)” at the “Main settings” tab. Ensure that you have properly added the CNAME record to your DNS settings.

UCDN Storage. By establishing an FTP connection to your UCDN storage container, you can verify if your content is still located on our servers.

You can find your FTP credentials by navigating to the “Storage” tab and clicking on next to your storage name.

Before proceeding with troubleshooting let us provide you with some information about Response Headers.

A response header is an HTTP header that can be used in an HTTP response and that doesn’t relate to the content of the message. Response headers, like Age, Location, or Server are used to give a more detailed context of the response (read more about Response Headers at https://developer.mozilla.org/en-US/docs/Glossary/Response_header ).

The response headers will provide you with detailed information you need to troubleshoot the issue you may have. There are a few ways to check response headers, by using the DevTools network panel in Chrome/Chromium, by using Developer Tools Network Monitor In Mozilla Firefox, or by the command-line tool cURL.

Using Curl Tool

Curl (or cURL) is a powerful command-line tool widely used for testing and troubleshooting client-server data transfer over HTTP/HTTPS. By using a series of command-line flags, you can test your CDN service.

-I, –head – Fetch the headers only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document.

-L, –location – If the server reports that the requested page has moved to a different location (indicated with a Location: header and a 3XX response code), this option will make curl redo the request on the new place. If used together with -i, –include or -I, –head, headers from all requested pages will be shown. When authentication is used, curl only sends its credentials to the initial host. If a redirect takes curl to a different host, it won’t be able to intercept the user+password. See also –location-trusted on how to change this. You can limit the number of redirects to follow by using the –max-redirs option.

-v, –verbose – Makes curl verbose during the operation. Useful for debugging and seeing what’s going on “under the hood”. A line starting with ‘>’ means “header data” sent by curl, ‘<‘ means “header data” received by curl that is hidden in normal cases, and a line starting with ‘*’ means additional info provided by curl.

Example:

$ curl -IL http://example.ucdn.com/Sample640.mp4

HTTP/1.1 200 OK
Server: ucdn
Date: Thu, 07 May 2020 11:52:29 GMT
Content-Type: video/mp4
Content-Length: 1804076
Connection: keep-alive
Keep-Alive: timeout=20
Last-Modified: Wed, 15 Apr 2020 17:57:18 GMT
Etag: “60df82646f4bedd777446e75f4305da8”
X-Timestamp: 1586973437.14001
X-Trans-Id: tx34e73eba3210470e90837-005eb3f67d
X-Ureq-ID: PYMqMNZBGwvabkCju9ID0//qq7/j4AvJcXzOEh4QieNDv3zYPfqllKhBt+cgeJdLpFDgmdfPxu4oUm1zLeANl2rRwsXgCTE/0OA5HsxaEvqrRxQdAtUeCAcemQ8kxlA5
X-Served-From: origin
Expires: Sat, 17 Oct 2020 19:37:40 GMT
Cache-Control: max-age=14111111
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: HEAD, GET, OPTIONS
Accept-Ranges: bytes

In the example above since example.ucdn.com is a CNAME linked to the CDN zone 11131-1.b.cdn12.com, the following command: “$ curl -IL http://11131-1.b.cdn12.com/Sample640.mp4″ will return the same output.

Is your content loading from CDN?

By using the command above (curl -IL) and by replacing http://example.ucdn.com/Sample640.mp4 with an URL of the file of yours (http(s)://URL_to_your_file.com) you can determine if the content is served by UCDN or by the origin server (A Web server that contains the original Web page. The term is used to identify the Web server from the cache server.)

HTTP/1.1 200 OK – shows that the request has succeeded.

Server: ucdn – shows that the file/content has been served by UCDN

The most useful information that can help us in troubleshooting is the value of the X-Ureq-ID. We very often ask our customers to provide us with this header. The value of this header will help us to determine which server is serving the file.

X-Ureq-ID: PYMqMNZBGwvabkCju9ID0//qq7/j4AvJcXzOEh4QieNDv3zYPfqllKhBt+cgeJdLpFDgmdfPxu4oUm1zLeANl2rRwsXgCTE/0OA5HsxaEvqrRxQdAtUeCAcemQ8kxlA5

-v flag is very useful for debugging and seeing what’s going on “under the hood” and will provide us with additional information which will help us in troubleshooting (e.g. $ curl -ILv http://11131-1.b.cdn12.com/Sample640.mp4)

Learn more about cURL and all the flags by reading the cURL manual page

Learn more about HTTP status codes at Status Code Definitions

Using Developer Tools Network Monitor In Mozilla Firefox

The Network Monitor shows you all the network requests Firefox makes, how long each request takes, and details of each request.

Opening the Network Monitor

There are a few different ways to open the Network Monitor:

Press Ctrl + Shift + E (Command + Option + E on a Mac).
Select “Network” from the Web Developer menu, (which is a submenu of the Tools menu on OS X and Linux).
Click the wrench icon, which is in the main toolbar or under the “Hamburger” menu, then select “Network”.

The Network Monitor will appear at the bottom of the browser window. When it first opens, the Network Monitor does not show request information. The just-opened tool looks like this:

Either action causes the Network Monitor to begin monitoring network activity. For demonstration purposes, we hit the URL http://11131-1.b.cdn12.com/Sample640.mp4 in Network Monitor in Mozilla Firefox. Select “Network” for the Developer menu, (which is a submenu of the Tools menu on OS X and Linux) and press Ctrl + R to reload the content, and click on the file(in the example above the file name is Sample640.mp4).

Let’s take a closer look at the “Headers” information. On the top, it shows the requested URL:http://11131-1.b.cdn12.com/Sample640.mp4, the request method, the remote address, and the status code. The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses an If-None-Match or an If-Modified-Since header.

The equivalent 200 OK response would have included the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

On the “Response Headers” section there are two parameters (Server and X-Ureq-ID) by which can be determined if the file is served by UCDN or by the origin server. The X-Ureq-ID will determine the particular UCDN server which served the content.

Since the URL in the example above (example.ucdn.com) is an alias (CNAME) to 11131-1.b.cdn12.com the output will be the same for the http://example.ucdn.com/Sample640.mp4 in the Network Monitor tool only the “Request URL” will change to http://example.ucdn.com/Sample640.mp4.

The value of these headers will help us in debugging CDN.

Using the DevTools network panel in Chrome/Chromium

The Network Panel shows you all the network requests Chrome/Chromium makes, how long each request takes, and details of each request.

Opening the Network Panel

Right-click the element and select Inspect or press Command+Option+C (Mac) or Control+Shift+C (Windows, Linux, Chrome OS).

For demonstration purposes, we hit the URL http://11131-1.b.cdn12.com/Sample640.mp4 in the Network Panel in DevTools. Select “Network” for the DevTools menu, and press Ctrl + R to reload the content, and click on the file (in the example above the file name is Sample640.mp4).

On the top, It shows the requested URL: http://11131-1.b.cdn12.com/Sample640.mp4, the request method, the remote address, and the status code. The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses an If-None-Match or an If-Modified-Since header.

The equivalent 200 OK response would have included the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

On the “Response Headers” section there are two parameters (Server and X-Ureq-ID) which can determine if the file is served by UCDN or by the origin server. The X-Ureq-ID will determine the particular UCDN server which served the content.

Since the URL in the example above (example.ucdn.com) is an alias (CNAME) to 11131-1.b.cdn12.com the output will be the same for the http://example.ucdn.com/Sample640.mp4 in the Network Panel only the “Request URL” will change to http://example.ucdn.com/Sample640.mp4.

The value of these headers will help us in debugging CDN.

Is the content not loaded correctly via HTTPS?

Universal CDN supports the automatic installation of LetsEncrypt certificates for all custom aliases added for a given zone. Тo install and enable them, you need to navigate to your UCDN control panel and go to the list of your zones. For the zone for which you want to enable LetsEncrypt, there should be added at least one custom CNAME and it should point to our default zone address. After that, you need to click on the button on the right side. Please read more about the SSL configuration at https://help.ucdn.com/content/47/94/en/letsencrypt.html

To install your custom SSL certificate please read the following article https://help.ucdn.com/content/47/19/en/how-to-install-ssl-certificate.html

Most popular help articles: