CDN Server Locations

What is a CDN server?

A CDN server (also called CDN edge server) is a caching server located at a particular point of presence (POP). Depending on your CDN provider, a POP may contain several servers at one location. These servers are used for caching your content upon user request. This means that when a visitor makes the first request for a static asset from your site, the asset is retrieved from your origin server and then cached at the visitor's nearest POP.

Since there can be several servers located at a single POP, there is a chance that upon the same user making a request for the same asset a second time, they hit a different server. Therefore, the request gets sent to the origin server again and upon delivery back to the client, the asset gets cached on the second server.

The more traffic an asset receives the quicker it gets cached on all of the CDN server locations. Therefore, once the asset is cached on all CDN servers, subsequent requests (no matter which server receives the request) will return the asset from cache. You can verify that the asset is delivered from cache by checking the HTTP response headers. If the X-Cache header shows a HIT then your asset was delivered from cache, otherwise, it will likely be a MISS which means the asset was delivered from the origin server.

Visit our technical questions page for a full list of KeyCDN cache statuses.

What does the X-Edge-Location HTTP header mean?

The X-Edge-Location header is another response header included in assets requested from the CDN domain (e.g. example-hexid.kxcdn.com). The value of this header is dependent upon your location when requesting an asset. Based on your location, this will determine which POP delivers you content. The first two letters of the X-Edge-Location header stand for the country TLD while the last two letters stand for the city.

You can verify which POP assets are being delivered from by checking the Network panel in Chrome DevTools.

The above image shows that the response is coming from the camo POP which is our Montreal, Canada location.

Alternatively, you can use our site speed test tool to verify which POP the response is coming. Simply test a CDN URL and check the X-Edge-Location in the response header. The example below shows a test from Seattle which used the usse (Seattle, USA) POP to deliver the asset.

For a full list of KeyCDN POP locations, visit our CDN Network page.

Debugging improper CDN edge server location routing

You may be using a CDN and have noticed some visitors get routed to a sub-optimal CDN server location when there is, in fact, a closer POP located near them. This issue is most commonly associated with the DNS resolver that the client is using.

Depending upon which DNS you are using and where the resolver is situated, responses may not be delivered from the nearest POP in respects to your location. For example, if a visitor is situated in Montreal they should be routed to our Montreal, Canada POP. However, if the DNS resolver they are using doesn't support EDNS client subnet and is located in Chicago for example, the user would be routed to our Chicago, USA POP instead.

An important point to mention with DNS servers is whether or not they support EDNS client subnet. EDNS client subnet allows DNS resolvers to pass along the client's IP address to compatible authoritative DNS servers. Therefore, in the above example, if the client was based in Montreal, however the DNS resolver was in Chicago, the client's IP would be passed along to the DNS resolver and therefore the client would be properly routed to their nearest POP (in Montreal).

The following image is an example of a request to a CDN that supports EDNS and a client using OpenDNS.

Both Google DNS and OpenDNS support EDNS, however many DNS servers (such as your ISP's DNS) may not support EDNS. Depending upon your situation, you may have to check (and possibly change) your DNS settings in order to be properly routed to the nearest POP if you are experiencing issues. You can use our DNS Checker tool (which also supports EDNS queries) to get more detailed information.

DNS resolvers are not always responsible for improper routing to the CDN edge server locations. A few other things to consider when debugging improper CDN POP routing include:

• ISPs may apply a quality of service (traffic shaping). Therefore they may handle certain media types differently.
• Changes in DNS resolvers may result in POP routing changes (if EDNS is not supported).
• The Internet is best effort. A CDN is just one part of the equation and therefore not in control of the full network / peering.