Can a Website Use Multiple CDNs? How to Interpret Results from Multiple CDN Tests

When tested from Beijing, the result shows a Chinese CDN; from Singapore, the identification changes to Cloudflare; a few hours later, another vendor appears.

For the same website, why can two or three CDNs show up? Is the check wrong, or does the site really use multiple CDNs at the same time?

The answer is: a website can absolutely use multiple CDNs.This architecture is usually called multi-CDN.

But detecting multiple names does not automatically mean the website uses multi-CDN. Domain redirects, separate domains for static assets, DNS caching, provider migrations, and CDN stacking can all make the results look like a mix of multiple providers.

Before making a judgment, remember one principle:

A single CDN detection result only represents one access path observed for a domain at a certain time, region, network, and protocol stack. It does not mean the entire website is always served by that CDN.

What counts as a website using multiple CDNs?

In real-world operations, “multiple CDNs” has at least five forms. They may look similar, but the architectures behind them are different.

Therefore, after seeing results from multiple providers, you cannot only ask “how many there are.” You also need to ask three questions:

1. Is the same complete hostname being tested?

2. Do these providers take turns serving as the user entry point, or are they in the same request chain?

3. Does this phenomenon exist stably over the long term, or only during a switch window?

Why would a website use multiple CDNs at the same time?

The most direct reason is that no single CDN can guarantee the best performance in every region, across every carrier, and at all times.

Large websites, streaming media, software downloads, e-commerce campaigns, and global businesses usually adopt multi-CDN for the following purposes.

1. Reduce the impact of a single provider’s failure

If the primary CDN has a regional failure, resolution anomaly, or degraded access quality, the traffic steering system can switch users to the backup CDN.

The core value here is not “having an extra name in normal times,” but avoiding having the entire business dragged down at once by one provider’s failure.

2. Use more suitable networks in different regions

One CDN may perform better on mainland China carrier lines, while another may have stronger coverage in North America, Europe, or Southeast Asia.

Through geographic or line-based steering, a website can route different users to different CDNs.

3. Share large traffic volumes and sudden events

Live streaming, game updates, software downloads, and major promotions can generate enormous bandwidth in a short time.

Distributing traffic proportionally across multiple providers can spread capacity pressure and reduce reliance on a single platform for temporary scaling.

4. Choose services by business type

The requirements for small web page files, image processing, video delivery, and large file downloads are not the same.

A website can route static web assets through a general-purpose CDN, video through a media CDN, and downloadable files through yet another high-throughput network.

Google Cloud’smulti-CDN strategy guidancealso states that multi-CDN can be used to optimize delivery by region and product capability, handle high-traffic events, and switch traffic to another provider when one provider has a localized failure.

How is multi-CDN implemented?

Approach 1: Select different CDNs at the DNS layer

This is the most common multi-CDN approach.

The access path can be simplified as:

用户查询域名
      ↓
DNS或流量调度平台
   ↙          ↘
CDN A        CDN B
   ↘          ↙
       源站

The steering system can return different CNAME or A/AAAA answers for different DNS queries based on region, carrier, latency, weight, or health status.

For example:

• Users in mainland China are returned provider A;

• overseas users are returned provider B;

• Most resolution traffic goes to the primary CDN, while a small portion goes to the backup CDN for warm-up;

• After the primary CDN health check fails, resolution switches to the backup CDN.

AWS Route 53’srouting policy documentationlists different DNS policies such as geolocation, latency, weighted, and failover. These mechanisms are not used only for CDNs, but they can handle the multi-CDN entry-point selection layer.

Note that DNS steering usually makes a selection for a resolution request; it does not mean every HTTP request reselects a CDN.

Weighted DNS sets the relative distribution of resolution answers; it does not mean HTTP request volume will keep exactly the same ratio. Recursive resolvers, operating systems, and browsers may cache DNS results, so a switch will not make all users migrate within the same second.

Approach 2: Use different CDNs for different subdomains

This is a relatively clear configuration method. For example:

www.example.com       → CDN A
static.example.com    → CDN A
video.example.com     → CDN B
download.example.com  → CDN C

From the user’s perspective, the entire website does use three CDNs; however, if you checkwww.example.com, you will usually see only CDN A.

Therefore, to determine whether a website uses multiple CDNs, you cannot only check the main domain in the address bar. You also need to find the resource domains that actually carry images, scripts, videos, and downloadable files in the page’s network requests, and then check each one separately.

Approach 3: Chain CDNs together

Another structure is: users connect to the outer CDN first, and the outer CDN then treats another CDN as its upstream.

用户 → 外层CDN A → 上游CDN B → 源站

This method is also called CDN stacking, a CDN chain, or stacked CDN. It is sometimes used for migrations, regional access, a unified security entry point, or complex resale services, but it is harder to configure.

Multi-layer CDNs need to handle issues such as cache keys, real client IPs, certificates, origin Host, and forwarding loops.

The IETF’sRFC 8586specifically definesCDN-Looprequest header, helping CDNs identify whether a request has already passed through their own network and avoid accidental forwarding loops between multiple CDNs.

For external detection tools, chained architectures are especially likely to produce “evidence of multiple providers”: the response IP usually belongs to the outermost CDN, but response headers may retain fields from an upstream CDN.

How should multiple CDN detection results be interpreted?

Do not count provider names first. Put each piece of evidence back into the layer it belongs to.

Look at the response IP first: it usually represents the outermost entry point

The address to which the user actually establishes a TCP or QUIC connection usually belongs to the outer CDN closest to the user.

This IP is important evidence for determining which network the request enters first.

However, an ASN only indicates network ownership; it cannot by itself prove a specific CDN product. A large cloud provider’s network may simultaneously host virtual machines, load balancers, managed platforms, and CDN services; some CDNs also use partner carriers or leased network resources.

Next, look at the CNAME: it reflects the direction of DNS steering

If queries for the same complete domain from different regions consistently return characteristic CNAMEs of two CDNs over time, this is a strong signal of multi-CDN steering.

However, the CNAME chain may first point to a third-party traffic management platform, which then selects the specific CDN; the root domain may also use ALIAS or CNAME flattening and only return A/AAAA addresses externally.

Therefore, not seeing two CNAMEs does not mean multi-CDN does not exist.

Finally, look at response headers: they may come from a multi-layer chain

For example, the response IP of a request belongs to CDN A, but a cache field from CDN B appears in the response headers.

Possible explanations include:

• A is at the outermost layer and B is an upstream CDN;

• the website is migrating from B to A and old fields have not been cleaned up;

• the origin or application intentionally mimics generic cache headers;

• the detection rule overweights a certain generic field;

• CDN resale or white-label services are involved.

Cloudflare’sHTTP header documentationalso specifically discusses the stacked CDN scenarioCDN-LoopandX-Forwarded-Forthe handling of fields such as these.

This shows that multi-layer proxies can indeed leave traces of multiple networks in one request, but seeing two headers is still not sufficient evidence.

What do the four common detection results mean?

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

For example:

If this result remains stable across multiple checks, and the CNAME, response IP, and response headers support each other, then the website very likely uses multi-CDN by region.

Case 2: Different subdomains are identified as different providers

For example, the main domain is identified as Cloudflare, the image domain as CloudFront, and the video domain points to yet another media CDN.

This shows the website as a whole uses multiple CDNs, but it should not be written as “www.example.comuses three CDNs at the same time.”

A more accurate description is:The website splits CDNs by business domain.

Case 3: The IP belongs to one provider, but another provider appears in response headers

This may be CDN stacking, residual headers, white-label services, or misidentification.

When judging, first confirm the outer response IP and the complete CNAME chain, then check whether the characteristics of both providers recur across multiple regions and multiple times.

If only one generic header matches, it is not enough to confirm a chained relationship.

Case 4: Yesterday it was one provider, today it has become another

Do not rush to conclude that it is multi-CDN.

The website may have just completed a switch, and old DNS answers may still be in recursive resolver or client caches; it may also be performing a canary migration or failover.

Only when the old and new providers continue to appear at different nodes within the same time window is it more like parallel steering.

How can you verify whether it is multi-CDN yourself?

Step 1: Fix the complete domain and URL

First confirm whether the test involved a redirect:

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

Apex domain,wwwimage domains, and download domains should be recorded separately; do not mix them into the same set of results.

Step 2: Check A, AAAA, and CNAME separately

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

Then switch to two public resolvers for comparison:

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

Note that the location and cache of public resolvers affect the answers. They can help reveal differences, but they cannot replace true multi-region probing.

Step 3: Test IPv4 and IPv6 separately

curl -4 -sS -D - -o /dev/null \
  -w 'ipv4_remote_ip=%{remote_ip}\n' \
  https://www.example.com/

curl -6 -sS -D - -o /dev/null \
  -w 'ipv6_remote_ip=%{remote_ip}\n' \
  https://www.example.com/

Some websites have already switched IPv4 to the new CDN while IPv6 is still on the old CDN; some websites intentionally use different entry points for the two protocols.

Testing only one of them may miss the other path.

Step 4: Repeat detection with multi-region nodes

InCdnChart CDN Check, review CNAME, response header, and IP/ASN evidence, then useCdnChart Website Speed Testto compare response IPs and access results across different regions.

It is recommended to record at least:

Do not treat a one-off result as a long-term architecture. Repeat observations across at least two points in time to rule out short-term failover, DNS caching, and deployment changes.

Step 5: Site owners should check backend logs

If this is your own website, external detection is only auxiliary; the real answer should come from:

• DNS or global traffic steering policies;

• domain configurations for each CDN;

• access logs and bandwidth curves for each CDN;

• health check and failover records;

• cache purge records;

• origin fetch sources in origin logs.

Only when both CDNs have real user requests and outbound traffic in the same time window can you confirm that both are actually carrying business traffic.

Merely adding the domain in both providers’ consoles does not mean online traffic is using them simultaneously.

One table to judge: which situation does a multi-provider result actually represent?

If you want to implement multi-CDN yourself, what are the most common pitfalls?

Multi-CDN is not simply buying one more service. As the number of providers increases, configuration differences multiply.

Cache rules must be as consistent as possible

If the same URL is cached for 10 minutes on CDN A and for one day on CDN B, users in different regions may see different versions.

Whether the cache key includes query parameters, cookies, Host, and request headers should also be kept as consistent as possible.

Cache purges must cover all providers

If you purge only one CDN when releasing a new version, another CDN may still return old content.

The automated release process should call the purge APIs of all CDNs currently carrying traffic simultaneously and record the execution results.

Security policies cannot be configured only on the primary CDN

If the primary CDN has WAF, rate limiting, and bot protection enabled, but the backup CDN does not have equivalent policies, then once traffic switches, attack traffic may enter through the weaker security entry point.

Origin access control must allow all legitimate origin fetch networks

Allowing only the primary CDN’s origin IPs and forgetting to add the backup CDN will cause all users to receive 5xx after failover.

Conversely, if you open direct public access to the origin to accommodate multiple providers, attackers may bypass all CDNs.

The real client IP chain must be consistent

Different providers may use different fields and trusted proxy configurations to pass visitor IPs; when CDNs are chained,X-Forwarded-Forsuch fields will continue to be appended.

Applications, logs, rate limiting, and security rules must clearly define which proxy layer is trusted.

DNS switching is not an instantaneous toggle

Even if authoritative DNS has switched, recursive resolvers and clients may still use old answers within the TTL period.

The backup CDN cannot wait until a failure occurs to configure certificates, caching, and security rules on the fly.

Google Cloud’s multi-CDN recommendations note that the backup CDN can carry a small amount of traffic during normal times. This not only continuously validates the configuration, but also keeps part of the cache warm, so that when failover occurs, not all requests hit the origin at the same time.

Logs and metrics must be normalized

Different providers may define HIT, MISS, BYPASS, origin fetch time, status codes, and traffic somewhat differently.

Before comparing, unify fields and time ranges; do not directly draw conclusions by putting percentages from two console screenshots together.

Is more CDNs always better?

Not necessarily.

Multi-CDN can improve resilience, but it also increases complexity in cost, certificate management, cache consistency, security policies, log analysis, and troubleshooting.

For websites with modest traffic, concentrated users, and ordinary availability requirements, one stable CDN plus clear origin and monitoring is often easier to maintain.

Multi-CDN is truly suitable mainly for:

• Users across multiple countries and carriers;

• Very high sensitivity to interruption;

• Live streaming, downloads, or major campaign traffic;

• A single provider performs poorly in some regions for a long time;

• The team has the ability to unify configuration, monitoring, and release processes.

The value of multi-CDN lies not in the number of providers, but inwhether switching actually works, policies remain consistent, and problems can be explained in terms of where traffic went.

Frequently asked questions

Can one domain resolve to two CDNs at the same time?

This can be achieved through DNS traffic steering, but it is usually not as simple as arbitrarily adding two CNAMEs to the same name.

The steering platform selects the appropriate CDN target for a DNS query based on weight, region, line, or health status, or returns the corresponding A/AAAA result.

Will a single browser request pass through two CDNs at the same time?

Normally, a request connects to only one user-facing outer entry point.

However, if the website uses CDN chaining, the outer CDN may request content from an upstream CDN; different resources in one page may also be provided by different CDNs.

Why do different detection websites give different CDN providers?

The detection location, DNS resolver, IPv4/IPv6, detection time, and evidence database may all differ.

First confirm whether they are testing the same final domain, then compare CNAME, response IP/ASN, and response headers, rather than only comparing the final provider names.

Can the same IP be identified as two CDNs?

It can happen.

Reasons include shared or partner networks, CDN resale, generic cloud platform addresses, and inconsistent updates to IP ownership databases. IP evidence should be cross-validated with DNS and HTTP characteristics.

Do small websites need multi-CDN?

Most small websites do not need to adopt multi-CDN from the start.

First configure one CDN’s caching, origin fetch, security, and monitoring correctly; that is usually more beneficial than adding a second one. Only evaluate multi-CDN when business regions, availability, or capacity requirements clearly exceed what a single provider can deliver.

Finally: understand multi-provider results as “paths”

A website can use multiple CDNs, but each detection does not show the website’s complete architecture—it shows one specific access path.

When judging multi-CDN results, it is recommended to always follow this order:

1. Confirm whether it is the same final domain;

2. Distinguish the main domain, static asset domain, and video domain;

3. Look at the outermost network corresponding to the response IP;

4. Use CNAME and response headers to supplement evidence;

5. Compare different regions, IPv4/IPv6, and multiple time points;

6. For your own website, use DNS policies and each CDN’s logs as the final authority.

You can start withCdnChart CDN Checkto analyze the domain’s CNAME, response headers, and IP/ASN signals, then useCdnChart Website Speed Testto compare the nodes actually hit in different regions.

For how to combine detection evidence, you can also refer toHow to identify the CDN used by a websiteandCdnChart Methodology.