How to Check CDN Nodes: Methods for Viewing Domain Node IPs and Regions

To check a domain's CDN nodes, first use an online tool to see the response IPs in different regions, then verify the exact address with DNS queries or a browser. To determine where the nodes are, you also need to combine IP geolocation info and vendor clues.

What tends to confuse people most is when several results do not quite match: your computer resolves one IP, your phone on mobile data resolves another, or a speed test page shows Guangzhou while an IP query reports Shanghai.

When you have just connected to a CDN, these differences can make you suspect a misconfiguration. Do not rush to change DNS settings. Distinguish between “where the test was initiated” and “where the request actually connected,” and most doubts will become explainable.

Start with the easiest method below. The earlier checks can be completed even if you are not familiar with the command line.

First, confirm which domain you want to check.

Suppose your homepage opens but images load slowly. Checking only the homepage domain may not reveal the problem.

Resources on a website can be served from separate domains:

These are sample domains. Replace them with the actual domains you use.

If what you have is a complete image URL, such ashttps://img.example.com/images/banner.jpgwhen running a domain check, first queryimg.example.comWhen you need to troubleshoot the response for that specific image, use a browser to view the complete URL.

In addition,example.comandwww.example.comshould also be examined separately. They may be configured with different DNS resolution, and one may redirect to the other.

Checking the right target is usually more effective than switching between many tools.

If you do not want to type commands, start with an online check.

OpenCDNChart's CDN detection toolenter the domain you confirmed above and click “Start Detection”.

This step helps you identify which CDN the site appears to be using and what signals support that judgment. The page uses clues such as the CNAME chain and HTTP response headers. When reading the result, note the word “suspected” and the strength of the evidence instead of simply remembering one vendor name.

Next, openthe website speed test and multi-region access testenter the same domain, select the carrier categories you want to check, and run the test. If most of your users are in China, begin with China Telecom, China Unicom, and China Mobile; if you also have overseas users, include the relevant monitoring locations.

If the page still shows “Simulated Preview,” submit your domain first and wait for the task to return results. IPs and timings in the preview cannot be treated as a report for your website.

In the results table, understand these columns first:

For example, a record may show a monitoring location of “Guangzhou, Guangdong” while the IP location says “Shanghai.” Both can be true at the same time: the request originated from Guangzhou, and the report labels the response address as Shanghai.

When looking at node distribution, compare the response IPs from the same test round and record which regions and which ISPs returned different addresses. What you get isa set of addresses observed under the conditions of this test.

This cannot be directly converted into the number of vendor data centers. A node may use multiple IPs, and multiple regions may share the same public IP. If no address is seen from a certain region, that alone does not prove the vendor has no node there.

To verify local results, run a DNS lookup.

If you only need to know “what address does this computer get right now,” built-in system tools are sufficient.

Windows users can open Command Prompt and run:

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com
nslookup -type=CNAME www.example.com

Ato look up the IPv4 address,AAAAto look up the IPv6 address,CNAMEand to look up alias records. Replace the example domain with your target domain.

nslookupThe top of the output usually shows the DNS server that answered the query.That is the server that resolved the query for you, not the website node you are looking for.What matters is the answer section for the target domain later in the output. For parameter usage, seeMicrosoft's nslookup documentation.

On macOS, or on a Linux environment withdiginstalled, you can run:

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer

Below is a sampleoutput, for demonstration only—not a real domain or an actual CDNChart test result.The IPs shown in it use documentation example addresses:

www.example.com.       300  IN  CNAME  edge.example.net.
edge.example.net.       60  IN  A      198.51.100.10
edge.example.net.       60  IN  A      198.51.100.11

This result indicates that the query returned an alias target and listed two IPv4 addresses. The numbers300,60are TTL values in the answer, in seconds, not latency. They may reflect the remaining valid time in the recursive DNS cache.

What you obtain here is the address list in the DNS answer. Which address the browser later chooses and whether redirects occur still need to be verified through the actual request. The official dig manual provides a more complete explanation of query types and output options.

If a CNAME query returns nothing, do not immediately conclude that no CDN is in use. For example, Cloudflare's proxy and CNAME flattening mechanisms can make a public query directly return address records.Cloudflare's proxy status documentationexplains this behavior.

Conversely, having a CNAME only indicates an alias relationship; that record alone cannot confirm the CDN provider. To further identify the vendor, cross-check withthe CNAME, response-header, and network evidence in CDN provider detection.

To see which IP the browser actually connects to, look directly at the request.

If you can already open the website, Chrome DevTools is an intuitive way to inspect:

1. Open the target page and pressF12or enter DevTools from the browser menu.
   

2. Switch to the “Network” panel and refresh the page.
   

3. Click the request you want to inspect: choose the main document for the homepage, or select that image for an image.
   

4. In the basic information of “Headers,” check “Request URL” and “Remote Address.”
   

The Remote Address records the peer IP and port for this request. For example, a demo value198.51.100.10:443puts the IP first and the port after. Chrome also supports showing the Remote Address column in the request list for easier comparison.See Chrome DevTools network panel documentation.

If a resource comes directly from the browser cache, no new network connection may be created. While DevTools is open, check “Disable cache” and refresh to inspect. That option disables only the browser cache; CDN edge caches may still take part in the response.

When the site redirects, focus on the request for the final page. The homepage, redirect page, and image requests may connect to different addresses, so do not randomly pick one request and treat it as the node for the whole site.

If you are comfortable with the terminal, you can also usecurlto check. The commands below apply to macOS and Linux and output the final request URL, the most recently connected remote IP, and the HTTP status:

curl -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 \
  -o /dev/null \
  -w 'url=%{url_effective}\nremote_ip=%{remote_ip}\nhttp_code=%{http_code}\n' \
  'https://www.example.com/'

-LIt follows redirects, so after a redirect, read the output'surlandremote_iptogether. On the Windows command line, usecurl.exeset the output file/dev/nulltoNULand keep the whole command on one line. For variable meanings, seethe official curl documentation.

If the device uses a proxy or VPN, confirm the current egress first. The proxy connection may change the remote address you observe, so such a result should not be treated as a normal user's direct connection result.

At this point, you can separately answer two questions: which addresses DNS provided, and where one particular request actually connected.

After obtaining the IP, you still need to verify the location.

You can paste the IP intoMaxMind GeoIP Lookupto see its location, network, and organization information. When comparing with CDNChart results, write down the labels from both sides. If they disagree, keep the difference rather than quickly treating one side as absolutely correct.

IP geolocation databases provide location estimates. Differences in update timing, address usage, and other factors can affect the results, and some results include an accuracy range. Therefore, seeing a city name does not mean you have confirmed the physical data center where that server is located.

Anycast is especially easy to misunderstand:The same public IP can route requests to different locations under different network conditions.So “finding the same IP across the country” does not equal “all users access the same data center.” SeeCloudflare's explanation of Anycast.

MaxMind's demo page also notes that Anycast networks do not have a fixed physical location and may not provide location data for those addresses. When the location field is empty, leaving it as “cannot be determined from this data” is more reliable than forcing a city name.

If the vendor provides node identifiers, request logs, or diagnostic information, cross-check them with official documentation. The organization name or ASN shown in an IP database is only a network ownership clue and is not necessarily the brand name you see when purchasing CDN service.

Here is how to continue investigating several common situations.

If your phone and computer return different IPs, first confirm whether they are on the same network. A phone on mobile data and a computer on home broadband can naturally get different results, and it is also worth checking IPv4 vs. IPv6, DNS cache, and proxy settings.

To rule out network differences, connect both devices to the same Wi-Fi, query the same full domain around the same time, and record the results.

If the IP changes after switching to a public DNS, treat the resolver as one comparison condition. But querying two public DNS servers on the same computer still only returns answers from two resolving services; it cannot replace real access tests from two cities. Determining regional differences requires actual probes from the corresponding regions.

If you see multiple IPs but are still not sure whether the CDN is active, continue checking vendor integration status and request evidence. Load balancing can also return multiple addresses, so “multiple IPs” alone is not enough to confirm a CDN.

Seeing only one IP also does not directly prove there is no CDN. A single query has a limited scope, so combine it with proxy status, response evidence, and multi-region observations.

As for “why is access still slow when the IP location looks close,” you need to return to the specific request. In addition to geographic distance, connection establishment, cache hit rate, origin fetch processing, and resource size all affect latency. Only by looking at node addresses together with speed test results can you identify the slow stage.

You do not need to run all these checks at once. First focus on the symptom you are actually experiencing, then choose the related step; troubleshooting will become much easier.

Record the results so the next query can be meaningfully compared.

If you are troubleshooting user feedback, save at least the following: query time and time zone, full domain, probe location, ISP, response IP, and access status. If images or APIs are involved, include the complete URLs.

For example, “the site is slow” gives technicians little to continue with. Change it to “at 20:15, Beijing Unicom accessed this image, connected to this IP, and the connection stage took unusually long several times in a row,” and you now have verifiable clues.

When comparing two sets of results, keep the target resource and test conditions as consistent as possible, and keep failed records too. For sampling conditions and data interpretation, seeCDNChart's testing methodology.

This is the value of checking nodes: turning a vague “something looks wrong” into a problem that can continue to be located.

Now you can test it with your own domain: confirm the CDN clues, review the response IPs from different regions, and finally verify your own browser request. Once these pieces of information are brought together, it is usually much clearer which differences are normal and which deserve further investigation.