Multiple IPs from a domain speed test: can you tell which CDN the site uses?

Putting a domain into a speed test tool can return a dozen or even dozens of responding IPs. Beijing Telecom connects to one address, Guangdong Mobile to another, and overseas nodes return a third set.

Does this mean the site uses a CDN? Can you determine which CDN provider it is directly from these IPs?

Here is the direct answer:

Finding multiple IPs for a domain can indicate that a site uses a CDN, DNS scheduling, or a distributed network, but the number of IPs alone cannot identify the CDN provider. To identify which CDN a site uses, you should also cross-check CNAME records, IP and ASN ownership, HTTP response headers, TLS certificates, and results from multiple regions.

Multiple IPs mean that different queries or access paths returned different addresses, but they do not directly explain whether those addresses belong to CDN nodes, cloud load balancers, multi-active origin sites, or multiple CDNs.

Why does the same domain resolve to multiple IPs?

A domain resolving to multiple IPs is not unusual; the underlying network architectures can be completely different.

CDN scheduling by region and ISP

A CDN selects an access point based on user location, recursive DNS, ISP, network quality, and node health.

The same domain may return:

• Beijing Telecom returns a North China Telecom node;

• Shanghai Unicom returns an East China Unicom node;

• Guangdong Mobile returns a South China Mobile node;

• Users in Japan return a Tokyo or Osaka node;

• Users in the United States return a North American edge node.

In this case, the multiple IPs are different edge entry points of the same CDN.

DNS round robin or load balancing

A domain can have multiple A or AAAA records configured at the same time. The DNS server may return multiple addresses in a query or change their order to spread requests across different servers.

This may be ordinary DNS load balancing and does not necessarily mean a CDN is in use.

For example:

www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.20
www.example.com. 300 IN A 203.0.113.30

If these IPs are the company's own servers, cloud hosts, or load balancer entry points, you cannot conclude that the site uses a CDN just because there are many of them.

Multiple data centers or multi-active origins

Some enterprises deploy multiple sets of business servers in Beijing, Shanghai, Guangzhou, Singapore, and other locations, then use DNS to direct users to different data centers.

This architecture provides geographic scheduling and redundancy, but it may be a self-built multi-active setup rather than a third-party CDN.

Using multiple CDNs at the same time

Large websites may use different CDNs in different countries, for different ISPs, or for different business domains, and may also configure primary/backup failover.

For example:

• Mainland China uses a domestic CDN;

• Overseas traffic uses a global CDN;

• Image and download domains use different providers;

• Traffic switches to a backup CDN when the primary CDN fails;

• Some traffic is sent to a new CDN for canary testing.

In this case, speed tests may indeed return IPs belonging to different networks or even different providers, but more evidence is still needed to confirm it.

IPv4 and IPv6 coexistence

If the results include both A and AAAA records, this only shows that the domain supports IPv4 and IPv6 dual stack.

203.0.113.10
2001:db8::10

The two types of addresses may belong to the same CDN. You cannot conclude that the site uses two providers just because the address formats differ.

Anycast uses the same IP to reach different nodes

There is also the opposite case: different regions resolve to the same IP, but the physical nodes they reach may not be the same.

Anycast allows nodes in multiple regions to advertise the same address, and the network routes users to different entry points based on routing. Therefore:

• Multiple IPs do not necessarily mean multiple CDNs;

• A single IP does not necessarily mean there is only one server.

The number of IPs only describes public results; it cannot fully reconstruct a CDN's internal topology.

Why is it difficult to identify the CDN provider from IPs alone?

An IP address primarily proves a network address and registration ownership, not a specific product.

The same ASN of a cloud provider may host all of the following at once:

• Cloud servers;

• Load balancers;

• Object storage;

• Hosting platforms;

• CDN nodes;

• Security proxies;

• Customer-built services.

Finding that an IP belongs to a cloud provider does not prove that the site uses that provider's CDN product.

Conversely, a CDN may use partner carriers, third-party data centers, or leased networks. The registered organization for some edge IPs may not directly show the CDN brand name.

Shared IPs bring another issue: the same edge address may serve a large number of customer domains. It can prove that requests enter a shared proxy network, but the address alone cannot reveal the specific plan, node type, or origin location.

In what order should evidence be examined when identifying a CDN provider?

A relatively reliable approach is to combine multiple pieces of evidence rather than look for a single decisive field.

Among these, CNAME, IP/ASN, and HTTP response headers are usually the three most commonly used types of public evidence for CDN identification.

Step 1: Query A, AAAA, and CNAME separately

You can usedigto view the records publicly returned for the domain:

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

Focus on three things:

• How many IPv4 addresses the A record returns;

• Whether an AAAA record exists, and whether it belongs to a different network;

• Whether the CNAME points to a scheduling domain with obvious provider characteristics.

A records in DNS store IPv4 addresses, while CNAME records point one name to a canonical name. These basic record formats are defined byRFC 1035.

If you see a structure like the following:

www.example.com. 300 IN CNAME www.example.cdn-provider.net.

A CNAME suffix may be a strong provider clue, but you still need to confirm whether the domain is an official scheduling domain used by that provider.

If the CNAME query returns no result, you cannot immediately conclude that no CDN is used. Root-domain CNAME flattening, ALIAS/ANAME, A-record onboarding, and proxy DNS may all return only the final IP to the querying client.

Step 2: Change resolvers and see whether results change

A local query only represents the answer seen by the current recursive DNS. You can compare different public resolvers:

dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

dig @1.1.1.1 www.example.com AAAA +noall +answer
dig @8.8.8.8 www.example.com AAAA +noall +answer

If different resolvers return different addresses, this may involve:

• Different DNS cache durations;

• Geographic scheduling;

• ECS client subnet information;

• Multi-CDN strategies;

• Primary/backup failover;

• DNS changes that have not fully propagated.

Even if public resolvers return the same result, this does not prove that users worldwide will receive the same IP. To observe actual access paths across different regions and ISPs in China, multi-node speed tests are still needed.

In CDNChart'sCDN detection toolafter entering a domain, the system cross-checks the CNAME chain, HTTP response headers, and public network signals to infer the likely CDN provider and shows the supporting evidence, rather than returning a brand name based on a single IP.

Step 3: Check IP and ASN ownership, but do not treat ASN as the final answer

After obtaining the responding IP, you can look up its address block, registered organization, and ASN.

Modern network resource lookups can use RDAP.ICANN's description of RDAPstates that RDAP is used to access current registration data and serves as a replacement protocol for WHOIS.

The query results should focus on:

• Which organization registered the IP address block;

• The autonomous system number it belongs to;

• Whether multiple IPs belong to the same ASN;

• Whether different regions hit completely different networks;

• Whether IPv4 and IPv6 belong to the same organization.

The results can be interpreted as follows:

IP location also cannot be treated as the precise location of a physical data center. The registered location, database-inferred location, and actual traffic entry point may differ.

Step 4: View the complete HTTP response headers

Use curl to retrieve response headers:

curl -sS -D - -o /dev/null https://www.example.com/

You can look at:

Server
Via
Age
X-Cache
Cache-Status
X-Request-ID
X-Served-By
CF-Ray
X-Amz-Cf-Id
Location

These are common field types, not every site will return them.

Provider-specific request IDs, cache fields, or node identifiers can increase confidence in identification. However, a single response header cannot be an absolute conclusion, because:

• Sites can remove or rewrite response headers;

• Ordinary Nginx, Varnish, or reverse proxies can also add themX-Cache;

• Multiple proxy layers may overwrite upstream fields;

• Attackers or site administrators can manually set fields with the same name;

• Dynamic pages are not cached and may also lackAgeorHIT.

Therefore, seeingX-Cacheonly shows that a cache status field exists; it does not directly indicate which CDN is used.

Step 5: Access the different IPs found by the speed test separately

If you have obtained several responding IPs from multi-region speed tests, you can usecurl --resolveto access them one by one while preserving the correct Host and TLS SNI:

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -D - -o /dev/null \
  https://www.example.com/

After changing the address, continue testing:

curl --resolve www.example.com:443:203.0.113.20 \
  -sS -D - -o /dev/null \
  https://www.example.com/

Focus on comparing:

• Whether the TLS connection succeeds;

• Whether the certificate matches the domain;

• Whether the HTTP status codes are consistent;

• Whether the page content is consistent;

• Whether response headers show characteristics of different providers;

• Whether cache status and request ID formats are similar;

• Whether a particular IP directly refuses access.

You cannot simply write the following:

curl https://203.0.113.10/

Accessing an IP directly changes the Host and may cause a TLS SNI mismatch. A certificate error, default site, or 403 returned in this case does not represent the result when the real domain accesses through that node.

curl's official--resolvedocumentationexplicitly allows temporarily setting the target address for a specified hostname and port, which is suitable for testing a specific IP while preserving the domain request semantics.

Step 6: Check what clues TLS certificates can provide

You can use OpenSSL to connect to a specified IP while explicitly passing the domain as SNI:

openssl s_client \
  -connect 203.0.113.10:443 \
  -servername www.example.com \
  </dev/null

Focus on:

• Domains included in the certificate;

• Issuer;

• Whether the certificate chain is complete;

• Whether the TLS handshake succeeds;

• Whether different IPs return consistent certificates;

• Whether ALPN negotiates HTTP/2.

TLS certificates usually serve only as supporting evidence. Many CDNs use public certificate authorities to automatically issue certificates; seeing Let's Encrypt, DigiCert, or Google Trust Services does not directly identify the CDN provider.

If different IPs return completely different certificates, pages, and response headers, there may be incorrect scheduling, stale nodes, multi-CDN configuration differences, or an IP that does not serve the current domain.

How should you judge when multiple IPs correspond to these situations?

Multiple IPs belong to the same ASN and response headers are consistent

This looks more like multiple nodes or entry points of the same CDN.

If different regions hit different IPs, but the CNAME suffix, response header format, certificates, and page content are consistent, the identification result usually has high consistency.

Multiple IPs belong to different ASNs, but the CNAME is the same

You cannot immediately conclude that multiple CDNs are in use.

The same CDN may use its own network, partner carriers, and leased addresses, and may also deploy nodes on different cloud platforms. In this case, CNAME and HTTP characteristics may be more explanatory than IP registration organizations.

Different regions return different CNAMEs and different provider characteristics

This is a strong signal of multiple CDNs.

For example, if different regions not only have responding IPs in different networks, but the CNAME suffix, request ID format, and cache response headers also point to different providers, then the site may use geographic routing, ISP scheduling, canary traffic, or failover.

Detection results when a site uses multiple CDNsEssentially, they can only represent one path seen at a certain time in a certain region; a single-node result cannot be understood as the site's complete architecture.

Multiple IPs all belong to ordinary cloud host or load balancer networks

This may be:

• Multiple origin servers;

• Cloud load balancing;

• Multi-data-center deployment;

• Hosting platforms;

• Self-built reverse proxies;

• A private CDN not yet indexed.

Without CNAMEs, CDN response headers, or other edge network characteristics, the safest statement is: "Multiple service addresses are currently found, but there is not enough evidence to confirm the CDN provider."

All regions return the same IP

This also cannot prove that no CDN is used.

It may be Anycast, a single-region entry point, fixed scheduling, DNS caching, or the current sample did not trigger an address change.CDN node IPs differ across regionsThis is only a common phenomenon, not a requirement that a CDN must meet.

How can CDNChart be used to cross-check multiple IPs?

For sites you do not own, the main evidence available is public network evidence. A relatively safe sequence is:

1. Use CDN detection to view CNAMEs, response headers, and public network signals;

2. Check the supporting evidence, confidence, and update time in the identification result;

3. Use website speed tests to compare responding IPs across regions and ISPs;

4. Observe whether slow nodes or failed nodes are concentrated on a particular group of IPs;

5. Usedig,curland OpenSSL to verify key results;

6. When multiple pieces of evidence agree, then infer the likely CDN provider.

An effective identification tool should not return only a provider name.What information CDN detection results should includedepends on whether it can explain CNAMEs, IP networks, HTTP characteristics, and the basis for judgment, and whether it acknowledges the limits of what it cannot identify.

Pay particular attention to:

• Private CDNs may have no public fingerprint;

• Self-built nodes may not map to a commercial brand;

• White-label CDNs may hide the original provider's domain;

• Multi-CDN setups return different results by region and time;

• Different subdomains of the same site may use different providers;

• Not identifying something does not necessarily mean no CDN is used;

• Identifying a network does not prove that all traffic goes through it.

If it is your own site, the final authority should be the CDN console, DNS configuration, access logs, and origin logs. Third-party detection is for discovering public evidence and cannot replace first-party configuration records.

FAQ

Does a domain resolving to multiple IPs always mean a CDN is used?

Not necessarily. Multiple IPs may also come from DNS round robin, cloud load balancing, multi-data-center deployment, primary/backup servers, or dual-stack networking. You need to consider CNAMEs, ASNs, response headers, and multi-region results.

If an IP belongs to Cloudflare, Amazon, or Alibaba Cloud, can you be sure their CDN is used?

Not completely. Large cloud networks host multiple products at the same time; IP ownership only proves that the address belongs to the relevant network, not that a CDN service is specifically used.

Why does the same domain resolve to different IPs each time?

It may be DNS scheduling, cache changes, node health checks, load balancing, multi-CDN strategies, or resolution changes. You should also record the TTL, query time, and recursive DNS used.

If there is no CNAME, does that mean no CDN is used?

No. CNAME flattening, ALIAS, ANAME, A-record onboarding, and proxy DNS can all hide the intermediate CNAME chain.

If multiple IPs belong to different ASNs, does that always mean multiple CDNs are used?

Not necessarily. The same CDN may use partner networks or third-party addresses. Only when CNAMEs, response headers, TLS characteristics, and regional routing also point to different providers is the multi-CDN conclusion more reliable.

Can response headers identify a CDN with 100% certainty?

No. Response headers can be removed, rewritten, or forged, and generic fields may also be added by ordinary reverse proxies. Response headers are only one piece of evidence.

Can IP location represent the real data center of a CDN node?

Not entirely. The location in an IP database may be the registered location, an inferred location, or the network organization's location, and Anycast addresses may be advertised simultaneously from multiple physical nodes.

What do "suspected" or "unidentified" mean in CDNChart?

"Suspected" means some CDN signals have been found, but the evidence is insufficient to determine the provider; "unidentified" means the current public signals are insufficient, which does not prove that the site does not use a CDN.