How to Find Out Which CDN and Node Distribution a Competitor's Website Uses: A Complete Investigation Method

When preparing to switch a website to a new CDN, many teams start by researching competitors:

• Which CDN does the competitor use?

• Do they use the same provider in mainland China and overseas?

• Are images, APIs, and downloads deployed separately?

• Which nodes do users connect to when accessing the site?

• Why does the same CDN perform so differently across regions?

• Can we simply choose the same vendor based on the competitor's setup?

Publicly available network information can answer some of these questions, but you cannot run a single DNS lookup and label the city associated with an IP as the competitor's CDN node distribution.

Modern websites may use multiple CDNs, Anycast, intelligent DNS, cloud load balancing, WAFs, and self-built edge nodes at the same time. A single IP may also be announced simultaneously from multiple data centers around the world.

A competitor CDN investigation should therefore be split into two questions:

1. Identify the CDN providers the competitor may be using;

2. Observe which public entry points the target domain actually reaches in different regions.

The first can be assessed using CNAME, IP, ASN, response header, and TLS evidence; the second requires repeated observations across regions, ISPs, and time periods.

Keep one limitation in mind first:

External research can reliably identify the CDN entry points and vendor evidence currently observed, but it usually cannot reconstruct the competitor's full node topology, contracted resources, node capacity, or actual origin architecture.

Define the research objective before querying

If you only want to know which CDN a website uses, checking the primary domain may be enough.

However, if the goal is competitor infrastructure analysis, you should answer at least the following questions:

Different research goals require testing different targets.

Checking only the homepage domain may suggest the competitor uses Cloudflare; looking further at page resources may reveal images served through CloudFront, video through a specialized media CDN, and APIs protected by a different WAF service.

Step 1: Don't check only the primary domain in the address bar

The most common mistake in competitor CDN research is checking only:

www.example.com

A real website usually also includes:

example.com
www.example.com
static.example.com
img.example.com
api.example.com
download.example.com
video.example.com
assets.example.com

These domains may use completely different infrastructure.

How to collect service domains

Open the competitor's website in a browser and pressF12to open developer tools, then review the request domains in the Network panel.

Organize them by resource type:

During the investigation, distinguish the competitor's own domains from third-party public services.

Loading Google Analytics does not mean the competitor chose Google as its website CDN; calling a third-party payment API does not mean the payment domain is part of the competitor's infrastructure.

Record the final redirect destination

The apex domain may only handle redirects, while the actual website is atwwwor another domain.

You can run:

curl -sS -L -o /dev/null \
  -w 'final_url=%{url_effective}\nremote_ip=%{remote_ip}\nstatus=%{http_code}\n' \
  https://example.com/

Record the following:

• Final URL;

• Final hostname;

• HTTP status code;

• Actual connected IP;

• Whether a cross-domain redirect occurred.

Do not conflate the CDN results for the pre-redirect and post-redirect domains.

Step 2: Look up CNAME, A, and AAAA records

For each key service domain, look up the following:

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

What a CNAME can tell you

Many CDNs require customers to point their service domain to the vendor's routing domain, for example:

static.example.com → customer.cdn-provider.example

If the CNAME suffix belongs to a publicly documented and stable CDN provider, it is usually strong identification evidence.

But you cannot rely on CNAME alone, because in the following cases the provider name may not be visible:

• CNAME flattening is used;

• The apex domain uses ALIAS or ANAME;

• The CDN returns Anycast addresses directly;

• The enterprise uses a custom routing domain;

• A white-label CDN hides the upstream brand;

• A separate traffic routing platform sits in front of multiple CDNs;

• The vendor's routing domain uses a neutral name.

So the absence of a CNAME does not mean a CDN is not in use.

Record A and AAAA records separately

Some websites use different architectures for IPv4 and IPv6:

IPv4 → CDN A
IPv6 → CDN B或源站

It is also possible that IPv4 has migrated to a new CDN while IPv6 still uses the old configuration.

Querying only A records misses the IPv6 path, and querying only AAAA records does not represent most IPv4 users.

Step 3: Look up IP and ASN, but don't equate them directly with the CDN brand

Once you have the response IP, you can look up:

• IP registration authority;

• Network block;

• ASN;

• Network organization name;

• Reverse DNS;

• Whether it belongs to a cloud platform or CDN provider.

RDAP is the standard way to query registration information for IP addresses, ASNs, and related internet resources. ARIN'sRDAP documentationstates that RDAP can query IP and ASN registration data and return results in JSON.

However, IP registration information and the actual CDN brand are not the same thing.

For example, an IP may belong to:

• The CDN provider's own network;

• A public cloud platform;

• A partner data center;

• A carrier network;

• An enterprise-owned ASN;

• An upstream white-label CDN;

• A BYOIP customer address;

• An edge platform shared by multiple services.

The following conclusion is therefore not rigorous:

IP属于AWS，所以网站使用CloudFront。

The website may simply run servers on AWS EC2, use ALB, or be served by another provider renting AWS resources.

A more reasonable statement is:

当前响应IP注册于AWS网络；是否使用CloudFront，还需要结合CNAME、响应头和多地区结果判断。

Step 4: Inspect HTTP response headers

Run:

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

Look closely at:

Server
Via
Age
X-Cache
X-Cache-Status
CF-Cache-Status
CF-Ray
X-Amz-Cf-Pop
X-Amz-Cf-Id
CDN-Cache-Status
Server-Timing

Different CDNs may add their own request identifiers, cache status, or node codes.

Which response header evidence is stronger

For example, Cloudflare's official documentation states thatCF-Raythe response header contains information about the data center that processed the request, shown as a three-letter code. However, when Argo Smart Routing or tiered caching is used, this code may also represent the data center that connected to the origin, rather than the entry point the user first reached.

So even if a vendor publishes PoP codes, you must first determine whether the field describes:

• The user-facing entry node;

• An upper-tier cache node;

• The origin-facing node;

• Where the request was ultimately processed.

Why the provider is sometimes not visible in response headers

Possible reasons include:

• The competitor removes branded fields;

• The CDN allows custom response headers;

• The outermost WAF overwrites upstream fields;

• The website uses a white-label CDN;

• The current request returns an origin error page;

• The request is blocked by a bot rule;

• A multi-layer CDN exposes only part of the outermost or inner-layer information.

Response headers are therefore one piece of evidence, not the only answer.

Step 5: Inspect the TLS certificate, but don't mistake the issuer for the CDN

You can inspect the certificate:

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -ext subjectAltName

Record:

• Domains covered by the certificate;

• Issuer;

• Validity period;

• Whether it is a wildcard certificate;

• Whether it includes other service domains;

• Whether the certificate seen from different regions is consistent.

TLS certificates can help identify:

• Whether multiple service domains share an entry point;

• Whether certificates on different nodes are in sync;

• Whether there are signs of a CDN-managed certificate;

• Whether a region is connecting to the wrong node;

• Whether IPv4 and IPv6 return different certificates.

However, the certificate issuer does not directly represent the CDN provider.

Seeing Let's Encrypt, DigiCert, or Sectigo only means the certificate was issued by that authority; it does not indicate which CDN the website uses.

Step 6: Repeat queries from multiple regions and ISPs

Running a singledigorcurllocally only answers:

What my network sees at the current time.

It cannot answer:

• Which CDN users in mainland China reach;

• Whether overseas users use a different CDN;

• Whether China Telecom, China Unicom, and China Mobile hit the same entry point;

• Whether IPv4 and IPv6 are consistent;

• Whether failover switches to another provider;

• Whether nodes are adjusted during peak evening hours;

• Whether the competitor uses weighted multi-CDN.

With CDNChart CDN detection, you can first review what is observed in different regions:

• CNAME;

• A and AAAA records;

• Response IP;

• ASN;

• HTTP response headers;

• Candidate CDN providers;

• Identification evidence and confidence.

Then use CDNChart website speed tests to record:

• Probe region;

• ISP;

• Resolved IP;

• Status code;

• DNS time;

• Connection time;

• TLS time;

• TTFB;

• Download time;

• HTTP protocol version.

Node selection should at least reflect the competitor's actual market coverage. For example, if the competitor mainly serves users in mainland China and Southeast Asia, querying only from a U.S. cloud server provides little useful reference.

Step 7: How to estimate the competitor's CDN node distribution

Three concepts need to be distinguished here.

1. The CDN provider's publicly listed global nodes

This is the overall network coverage the vendor publishes and indicates which nodes the CDN may own or use.

It does not prove that the competitor's specific product has access to every node, nor that the competitor receives the same service quality in every region.

2. Addresses assigned in IP databases

IP geolocation databases may label an address with a country, city, or ISP.

Such results are useful as supplementary reference but should not be treated as physical data center addresses. MaxMind's official documentation also notes that IP geolocation cannot pinpoint a specific household, individual, or street, and many IPs can only be located to a broad area.

For CDN and Anycast addresses, city-level attribution is especially prone to being misleading.

3. Service entry points actually observed

This is the most valuable data: the actual IP, ASN, node code, and network latency obtained when accessing the competitor's domain from a specific region and ISP.

A complete record can be written as:

This describes the entry point observed from that location, not a claim that the physical server is necessarily in the corresponding city.

Why the number of distinct IPs cannot be used to count nodes

If 20 regions ultimately return 5 distinct IPs, you cannot directly conclude that the competitor has only 5 CDN nodes.

Reasons include:

• One IP may be announced by multiple Anycast nodes;

• Multiple IPs may belong to the same data center;

• DNS may return an address pool rather than physical nodes;

• The CDN may rotate IPs based on load;

• Different ISPs may reach different locations through the same IP;

• IPv4 and IPv6 may map to the same edge cluster;

• The same node may have multiple service addresses.

Cloudflare's official documentation states that its Anycast network announces the same IP from data centers around the world, routing different visitors to nearby data centers.

Therefore:

唯一IP数量 ≠ 节点数量

Conversely:

所有地区得到同一个IP ≠ 所有用户进入同一个机房

A node's geographic location is not necessarily the nearest city

CDN routing generally aims for network quality, not mere geographic distance.

Amazon CloudFront's official documentation states that DNS routes user requests to the PoP best suited to serve them, usually the edge location with lower network latency.

A user in Guangzhou may be routed to a node outside Hong Kong or Shenzhen due to ISP peering, node capacity, or failover; a city that looks closer on a map does not necessarily offer lower network latency.

Cloudflare also notes that Anycast requests do not necessarily reach the geographically closest data center; network reliability, congestion, and traffic engineering all affect the final path.

Competitor node analysis should therefore record:

• Probe location;

• ISP;

• PoP code;

• Network latency;

• TTFB;

• Response IP;

• Time;

• HTTP status code.

Drawing a node map from an IP geolocation database alone can easily lead to overly definitive conclusions.

How to determine whether the competitor uses multiple CDNs

Look for the following outcomes.

Case 1: The same domain is consistently identified as different providers in different regions

For example:

If repeated queries remain consistent, the competitor may use multiple CDNs by region or network path.

Case 2: Different service domains use different providers

For example:

www.example.com       → CDN A
static.example.com    → CDN B
video.example.com     → CDN C
api.example.com       → WAF或动态加速D

This indicates that the competitor separates infrastructure by service, but it should not be written as “the primary domain uses four CDNs at once.”

Case 3: The response IP belongs to one provider while headers show another

Possible reasons include:

• CDN stacking;

• An outermost WAF with an inner CDN;

• White-label service;

• Residual upstream response headers;

• Misclassification by identification rules.

In this case, generally treat the network associated with the actual connected IP as the outer entry point first, then investigate whether the other provider's evidence recurs consistently over time and across regions.

Case 4: Identification results differ between yesterday and today

This may be due to:

• CDN migration;

• Canary rollout;

• Primary/backup failover;

• DNS caching;

• Dynamic traffic routing;

• Different test conditions.

Only when two CDNs consistently appear in the same time window, across different regions, or under different weights is parallel use more likely. For a more complete assessment method, seeCan a website use multiple CDNs? How to interpret results from multiple providers.

A directly actionable query workflow

Round 1: Compile service domains

Compile from the browser Network panel:

主页面域名
静态资源域名
图片域名
API域名
下载域名
视频域名
WebSocket域名

Round 2: Collect DNS evidence

dig HOSTNAME CNAME +noall +answer
dig HOSTNAME A +noall +answer
dig HOSTNAME AAAA +noall +answer

Run the checks separately for each important hostname.

Round 3: Collect HTTP and connection information

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_version=%{http_version}\nstatus=%{http_code}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://HOSTNAME/

Record response headers; do not save only the final vendor name.

Round 4: Look up IP network information

Use RDAP, RIRs, or trusted ASN data sources to record:

• IP network block;

• ASN;

• Network organization;

• Registration region;

• Data query time.

Be careful to separate the network registrant from the final CDN brand.

Round 5: Run multi-region tests

Send the same request from different ISPs in core markets while keeping the following consistent:

• Same URL;

• Same request method;

• Similar test time;

• IPv4 and IPv6 tested separately;

• HTTP protocol recorded;

• Cache status recorded;

• Same number of retries.

Round 6: Continuous observation

A quick investigation can start with one cross-sectional check, but to assess multi-CDN use and node stability, continue covering:

• Weekdays;

• Weekends;

• Daytime;

• Evening peak;

• Multiple consecutive time points;

• Possible promotions or high-traffic periods.

Do not mistake a single failover result for the competitor's long-term architecture.

How to write a competitor CDN research report

You can use the following structure.

1. Scope of investigation

调查对象：
调查日期：
观测地区：
运营商：
业务域名：
测试URL：
IPv4/IPv6：

2. CDN identification results

3. Node observation results

4. Scope and limitations of conclusions

The report should explicitly state:

• Node cities are inferred from response headers, network paths, or IP databases;

• The number of unique IPs does not represent the number of physical nodes;

• The investigation covers only the specified times, regions, and URLs;

• A CDN that was not observed is not necessarily absent;

• CDN providers may remove or customize publicly visible fingerprints;

• Contracted capacity and protection specifications cannot be confirmed through public detection;

• The results do not involve origin probing or bypassing access controls.

Such a report may not contain a single “100% certain” statement, but it is more credible than a seemingly precise global node map drawn from a single IP.

Common misconceptions when researching a competitor's CDN

Misconception 1: One CNAME can determine the CDN for the entire website

A CNAME only shows the DNS relationship for the current hostname. Image, API, video, and download domains may be served by different providers.

Misconception 2: If an IP belongs to a cloud provider, the site uses that provider's CDN

A cloud platform IP may be used for virtual machines, load balancing, object storage, managed services, or third-party products, so more evidence is needed.

Misconception 3: If IP geolocation shows Shanghai, the node must be in Shanghai

IP geolocation databases contain estimated data. Anycast, ISP registration details, and proxy networks can all make the geolocation result differ from the actual service location.

Misconception 4: If different regions return the same IP, there is no node routing

Anycast allows nodes in multiple regions to announce the same IP. Different users may reach different data centers even when connecting to the same address.

Misconception 5: Finding 10 IPs means the competitor has 10 nodes

The number of IPs, hosts, edge clusters, and physical PoPs are not the same concept.

Misconception 6: If the competitor uses a certain CDN, we should choose it too

The same CDN may perform differently for different customers depending on the plan, node coverage, traffic volume, configuration, caching strategy, and commercial resources. A competitor's setup can be a lead, but it cannot replace your own testing.

Which activities fall outside normal competitor research

Public DNS records, HTTP response headers, TLS certificates, and normal low-frequency access can be used for infrastructure research, but you should not proceed with:

• Unauthorized port scanning;

• High-frequency requests or stress testing;

• Attempting to bypass a WAF;

• Probing or verifying the competitor's origin server;

• Exploiting misconfigurations to access non-public services;

• Cracking administrative backends;

• Obtaining data that is not part of a public response;

• Tests that affect website availability.

The goal of competitor CDN analysis should be to understand publicly observable delivery paths, not to bypass the other party's security boundaries.

Which results should you ultimately trust?

In competitor CDN research, evidence credibility can be roughly ranked as follows:

CDNChart CDN detection is useful for viewing CNAME, response IP, ASN, and HTTP response headers in a single result; node coverage still requires multi-region website speed tests. For detailed node lookup methods, seeHow to look up CDN nodes: methods for checking domain node IPs and regions.

The most valuable competitor conclusion is usually not:

竞品有37个节点。

but rather:

竞品主站在中国大陆和东南亚观察到不同CDN入口；
静态资源与API采用不同厂商；
核心地区的响应IP、PoP代码和TTFB较稳定；
海外路径疑似使用Anycast，无法按唯一IP推算物理节点数量。

This wording preserves the value of the research without packaging limited public observations as a complete internal architecture.

Frequently asked questions

1. Can entering a domain accurately reveal which CDN a competitor uses?

Sometimes, but not always. Clear CNAMEs, dedicated IPs, and response headers can provide high-confidence results; white-label CDNs, self-built nodes, CNAME flattening, and multi-layer proxies can make results inconclusive.

2. How can you tell whether a queried IP is a CDN node or the origin server?

Assess it together with CNAME, ASN, response headers, and multi-region results. If different regions return different edge addresses with vendor cache or node characteristics, it is more likely a CDN entry point. Do not draw conclusions from a single IP.

3. Can the number of IPs be used to calculate how many CDN nodes the competitor has?

No. One Anycast IP can correspond to multiple nodes, and multiple IPs may belong to the same data center. External research is better suited to counting observed entry IPs and PoPs than to calculating the total number of physical nodes.

4. Why do different lookup tools show different node cities?

Different tools may use different IP geolocation databases, with different update times and geolocation methods. Addresses on CDNs, Anycast networks, and carrier networks are especially difficult to locate precisely.

5. If different CDNs are detected for the competitor in different regions, is that a detection error?

Not necessarily. It could be regional multi-CDN, network-path routing, primary/backup failover, IPv4/IPv6 splitting, or a migration in progress. Repeat the checks across multiple regions within the same time window.

6. If response headers contain no CDN field, does that mean no CDN is used?

No. Vendor fields may be removed, overwritten, or white-labeled, or they may appear only in certain responses. Also check DNS, IP networks, and results from different regions.

7. If the competitor's CDN performs well, will ours perform the same after onboarding?

Not necessarily. CDN performance depends on user regions, ISPs, plans, caching strategy, protocol configuration, origin location, and business resources. Competitor research can only help narrow the candidates; you still need to test with your own domain and user distribution.

8. How long must observations run to be useful?

A single check is suitable for a quick assessment; to analyze multi-CDN use, failover, and node stability, cover multiple time points, major traffic periods, and core regions, and retain the raw results from each run.