Six cases where CDN detection fails: how to identify multi-CDN, self-built nodes, and proxy chains

Enter a domain name, and the detection result shows no clear CDN provider—only 'Unidentified,' 'Possible proxy use,' or two or three candidate providers at the same time.

Does this mean the detection tool is inaccurate?

Not necessarily.

CDN detection is not a one-time query against a public database that yields a single answer. It is closer to network forensics: first observe DNS resolution, the CNAME chain, response IPs, ASN, HTTP response headers, TLS certificates, and results from different regions, then determine whether these pieces of evidence collectively point to a specific CDN.

If a website uses multiple CDNs, white-label services, self-built nodes, CNAME cloaking, or multiple proxy layers, the evidence visible on the public internet may be incomplete or even conflicting.

So when you see 'No CDN identified,' the most important step is not to guess a provider immediately, but to first determine:

Is the website actually not behind a CDN, or is it already behind an edge proxy but the available evidence is insufficient to identify the provider?

This article does not discuss in general terms why a CDN cannot be detected. Instead, it breaks down the six specific architectures most likely to cause identification failures.

What evidence CDN detection typically relies on

Before analyzing identification failures, let's look at what a typical CDN detection system usually collects.

A reliable identification result usually requires two or more independent pieces of evidence that support each other.

For example:

• The CNAME suffix points to a specific CDN;

• The response IP belongs to that CDN's network;

• The response headers also contain node fields specific to that provider.

When all three pieces of evidence align, confidence is usually high. Conversely, if only a shared cloud platform ASN is available, it should not be treated directly as a definitive CDN provider.

For a more complete identification methodology, seeHow to Identify the CDN a Website Uses: CNAME, Response Headers, ASN, and TLS Evidence.

Scenario 1: The domain being tested is not the domain that actually uses the CDN

This is the most common and most easily overlooked scenario.

A website may include the following domains:

If you test onlyexample.com, and it directly returns a 301 redirect, the detection tool may only see the web server handling the redirect. The domains that actually use the CDN—www.example.comorstatic.example.com—are not checked, so they naturally cannot be identified.

Common symptoms

• Bare domain unidentified,wwwdomain can be identified;

• Homepage domain unidentified, image and static asset domains can be identified;

• The detection result shows a hosting platform, but assets in the browser come from another CDN;

• Before and after following the redirect, the connecting IP and response headers differ completely.

How to verify

First, check the final redirect URL:

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

Then check all key hostnames separately:

dig example.com A +noall +answer
dig www.example.com A +noall +answer
dig static.example.com A +noall +answer
dig img.example.com A +noall +answer

The Network panel in browser developer tools is also important. Check which domains the homepage actually loads, then test the HTML, image, JS, API, and download domains one by one.

The correct conclusion here is usually not 'the website has no CDN,' but:

The specific hostname tested shows no CDN evidence, but other business domains on the website may use a CDN.

Scenario 2: The website uses multiple CDNs, and a single node sees only one of them

Multiple CDNs do not necessarily make identification clearer; they may instead make different detection results contradict one another.

The same domain can be routed to different providers based on the following conditions:

• User country or region;

• Carriers such as China Telecom, China Unicom, and China Mobile;

• IPv4 or IPv6;

• Real-time network quality;

• DNS weight;

• Primary/backup health status;

• Canary release percentage;

• Cost and traffic quotas.

For example, China Telecom Beijing may reach Provider A, while Singapore reaches Provider B; IPv4 may go to Provider A, while IPv6 goes to Provider C. A single detection node can see only the path from its own location and cannot represent the entire website.

Common symptoms

• Domestic and overseas results differ;

• Different carriers get different IPs and ASNs;

• The same domain may show different providers at different times;

• IPv4 can be identified, while IPv6 shows another provider or is unidentified;

• Detection results flip back and forth between two CDNs.

How to verify

First, query IPv4 and IPv6 separately:

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

Then switch resolvers and observe:

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

You can also test the two protocol stacks separately:

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

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

However, changing public DNS resolvers is not a substitute for true multi-region testing. The resolver's egress location, cache, and EDNS Client Subnet policy all affect the answer.

To determine whether multiple CDNs are in use, repeat detection from multiple regions and carriers within the same time window, and record:

• Full hostname;

• A and AAAA records;

• Response IP;

• ASN;

• CNAME chain;

• HTTP response headers;

• Detection region;

• Detection time.

Only when the same domain consistently yields evidence of different providers across regions over time does it look more like true multi-CDN routing. For details, seeCan a Website Use Multiple CDNs? How to Interpret Conflicting Results.

Scenario 3: CNAME is flattened or hidden, and the provider's domain is not visible in DNS

Many CDN detection tools check CNAME first, because provider traffic-routing hostnames often have fairly distinctive suffixes.

For example, a business domain may point to:

www.example.com → customer.vendor-cdn.example

If that suffixvendor-cdn.examplebelongs to a known provider, identification is relatively straightforward.

In real deployments, however, CNAMEs are not always publicly visible.

When CNAMEs may be hidden

• CNAME Flattening is used at the root domain;

• The DNS platform flattens the CNAME chain into A or AAAA records;

• Platform-specific record types such as ANAME or ALIAS are used;

• The reverse proxy DNS returns Anycast IPs directly;

• The provider offers a neutralized traffic-routing hostname;

• The enterprise wraps the upstream CDN with its own traffic-routing hostname;

• The DNS platform and CDN are provided by the same vendor, with mapping completed internally.

Take Cloudflare as an example. Itsproxy status documentationstates explicitly that CNAMEs in proxied status are flattened by default and return Cloudflare Anycast IPs externally rather than the original CNAME target.

Therefore, when the following command returns no CNAME:

dig www.example.com CNAME +noall +answer

it does not prove that the website has no CDN.

How to continue investigating

Continue by querying A and AAAA records:

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

Then combine:

• The ASN where the IP is located;

• Whether the IP block belongs to a known edge network;

• Whether different regions return different IPs;

• Whether response headers contain cache or node information;

• Whether the same IP serves many unrelated domains;

• Whether requests exhibit edge-cache characteristics.

Note that DNS toolsdig +tracecan help inspect DNS delegation and authoritative resolution, but they do not necessarily recover the original CNAME that has already been flattened by the authoritative DNS. When flattening happens inside the authoritative service, external queriers see only the final address.

Scenario 4: The website uses self-built nodes, a white-label CDN, or BYOIP

Some websites do use CDN-style architecture, but not under an easily recognizable public brand.

Common forms include:

• Enterprise self-built edge nodes;

• A private CDN made up of cloud servers plus load balancing;

• A distribution network built with open-source caching software;

• A CDN reseller using its own brand and domain;

• An upstream CDN providing white-label services to partners;

• An enterprise handing its own IP blocks to a CDN for announcement;

• A CDN using third-party data centers or carrier networks to provide nodes.

In this case, the detection tool may see the enterprise's own domain, its own IPs, and its own certificate, but not the CDN platform behind them.

Why ASN-based judgment fails

An ASN only indicates which network announces the IP block externally; it does not necessarily indicate:

• Who owns the current website;

• Who provides the CDN software;

• Who manages caching and security policies;

• Which brand of service the website purchased;

• Whether another partner network sits behind the IP.

BYOIP further blurs this relationship.

Cloudflare'sBYOIP documentationshows that enterprises can continue using their own IP addresses while using Cloudflare's security and performance services.

In other words, external observers may see the enterprise's own IPs, while traffic is still actually handled by the CDN's global network. IP ownership databases alone may classify it as a self-built network or fail to identify it entirely.

What about white-label CDNs?

A white-label CDN usually has an upstream provider supply nodes, routing, or management capabilities, while the reseller sells under its own brand, console, and traffic-routing hostnames.

External detection may see only:

• Reseller-defined CNAMEs;

• Neutralized response headers;

• ASNs of upstream networks or third-party data centers;

• The customer's own TLS certificate;

• Cache headers with no obvious brand characteristics.

Without vendor partnerships, public documentation, or long-accumulated fingerprints, it is difficult to accurately determine the final brand from a single public detection.

At this point, a more professional result than 'forcing an identification of a particular provider' would be:

Edge proxy or distributed node characteristics detected, but the specific CDN provider cannot be confirmed based on public evidence.

Scenario 5: There is more than one proxy layer in front of the website, and only the outermost entry can be identified

A modern website may not be simply:

用户 → CDN → 源站

but rather:

用户 → DDoS防护或WAF → CDN → 云负载均衡 → 应用网关 → 源站

or possibly:

用户 → CDN A → CDN B → 对象存储

In such proxy chains, ordinary users connect directly to the outermost entry. DNS and connecting IPs usually reflect only the proxy closest to the user, and inner CDN layers may be completely hidden.

Why response headers may show a different provider

Suppose a user first connects to CDN A, and CDN A then retrieves content from CDN B. If response headers returned by CDN B are not cleaned, they may pass through CDN A and continue to the user.

The final result may show:

• Response IP and ASN belong to CDN A;

• A cache header looks like CDN B;

• ServerA field shows origin server software;

• The TLS certificate is terminated by CDN A;

• Different detection rules give different providers.

This result does not necessarily mean someone identified it incorrectly; each piece of evidence may simply correspond to a different layer in the proxy chain.

Can Via and Proxy-Status reveal the full proxy chain?

HTTP standards define several fields for intermediary proxy information. For example,RFC 9209defines theProxy-StatusProxy-Status response field, which allows a proxy to report processing results and error details.

Real-world websites, however, do not necessarily deploy these fields, nor do they necessarily include vendor branding in them. Providers can also add, override, or remove certain headers according to response policies.

AWS CloudFront'sresponse headers policy documentationprovides the ability to add and remove response headers.

Therefore:

• The presence of ViaViaor Proxy-StatusProxy-Statuscan serve as proxy evidence;

• the absence of these fields does not prove that no proxy exists;

• the appearance of two provider fields also does not directly determine which one is outermost.

When determining the outer entry, priority should usually be given to the actual connecting IP, the TLS termination point, and multi-region DNS results, with response headers used as supporting evidence.

Scenario 6: CDN fingerprints are removed, shared, or distorted by error pages

The last scenario is not a special architecture but insufficient quality of the public fingerprint itself.

Common response headers used in CDN detection include:

Server
Via
Age
X-Cache
X-Cache-Status
CF-Cache-Status
X-Edge-Location
X-Request-ID

These fields do not have equal identification value.

Generic response headers may be used by multiple providers

For example:

X-Cache: HIT

Such a field can only indicate that some layer reported a cache hit; this field alone cannot confirm which CDN is in use.

Server: nginxSuch a value can only indicate that some layer returned this string. It may come from the origin server, an edge node, or simply be a custom value.

Vendor signature headers may be removed

Websites can use CDN rules, edge functions, or origin configuration to:

• Remove vendor branding headers;

• Override the valueServer;

• Modify cache status fields;

• Add custom node identifiers;

• Unify response formats across different CDNs.

Such configuration is sometimes intended to reduce information exposure, and sometimes simply to keep response structures consistent across multiple CDNs.

WAF challenge pages replace normal responses

Detection tools may also receive:

• 403 block pages;

• JavaScript challenge pages;

• CAPTCHA pages;

• 429 rate-limit responses;

• 502 or 503 edge error pages;

• Special responses aimed at bots.

These pages may be generated by the WAF or the outermost security proxy and follow a different cache path from that of normal user access.

If the detection tool determines the CDN based on the headers of a challenge page, the result may well identify only the security entry point, or fail to find any fingerprint of normal business traffic.

Shared IPs can also cause false positives

Large CDNs, reverse proxies, and cloud platforms often have many domains share the same Anycast IP. Seeing that an IP was once used by another website on a certain CDN does not prove that the current domain has purchased the same product.

Conversely, using dedicated IPs, static IPs, or BYOIP can also invalidate IP fingerprints of known CDNs.

Therefore, identification confidence should remain low when only the following results are available:

• Only one shared IP match;

• Only one generic response header;

• Only the certificate issuer is seen;

• Only the server software name;

• Detection requests keep returning challenge pages;

• The ASN belongs to a cloud platform rather than a clear CDN network;

• DNS, IP, and response headers point to different entities.

A table to understand the six identification failures

How to determine whether no CDN is used or a CDN is used but cannot be identified

The final result can be divided into four categories, rather than simply yes or no.

First: a specific CDN is identified with high confidence

This usually requires:

• CNAME, IP, or ASN clearly points to the provider;

• Vendor-specific response headers appear repeatedly;

• Results from multiple regions are basically consistent;

• Request content and status codes are normal.

Second: an edge proxy is confirmed to exist, but the provider is unknown

Common evidence includes:

• Different regions connect to different IPs;

• IPs have Anycast or distributed entry characteristics;

• Responses contain cache, node, or proxy fields;

• Origin characteristics are hidden;

• Multiple nodes return consistent content, but there is no clear brand fingerprint.

This result is best labeled as 'CDN or reverse proxy characteristics detected, provider unknown.'

Third: multiple candidate providers exist

For example, the IP belongs to Provider A, while response headers consistently show Provider B characteristics. In this case, all candidates should be retained, and the following should be stated:

• Which evidence supports which party;

• Which is more likely to be the outer entry;

• Whether a proxy chain may exist;

• How high the confidence in the conclusion is.

Fourth: insufficient CDN evidence is found

If multiple regions consistently return the same hosting IP over time, there are no CNAME, cache, proxy, or edge node characteristics, and the content appears to be returned directly by the origin server, then 'possibly no CDN in use' is a relatively reasonable judgment.

But it is still not absolute proof. For the specific distinction, seeCDN Detection Fails: No CDN in Use, or Failure to Identify?.

A reproducible manual verification workflow

Step 1: Confirm the full URL and final domain

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

Do not conflate the bare domain,wwwimage domains, and API domains.

Step 2: Query complete DNS records

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

Record the TTL, CNAME, IPv4, and IPv6; do not just copy a single IP.

Step 3: Inspect normal response headers

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

Focus on:

• Status code;

• Whether a redirect occurs;

• Cache status;

• Age;

• Via;

• Server;

• Request tracing fields;

• Node or PoP fields;

• Whether a WAF challenge is returned.

Step 4: Retest with a fixed IP

If multiple IPs are found, preserve the correct Host and TLS SNI and access each:

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

Replace the IP192.0.2.10with the address actually observed.

Do not access it directlyhttps://IP地址/, because the certificate, SNI, and virtual host may not match, and the page returned may not be the target website.

Step 5: Compare IPv4 and IPv6

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

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

A dual-stack website may use completely different entry points on the two networks.

Step 6: Perform multi-region retesting

A single computer can only answer 'what I see here right now.'

When using CdnChart's CDN detection, check the following together:

• CNAME chain;

• Response IP;

• IP ASN;

• HTTP response headers;

• Detection region;

• Candidate providers;

• Evidence confidence;

• Whether there are conflicts across regions.

If you also need to confirm whether these IPs are CDN edge nodes or origin servers, continue readingWhat Is the Difference Between a CDN Node IP and an Origin IP?.

How CDN fingerprint databases can reduce false identifications

If you are developing a CDN identification system, the most important thing is not to keep adding static IP-to-provider mappings, but to assign different weights to each type of evidence.

One relatively reliable approach is:

The system should also allow output such as:

• Identified;

• Suspected;

• Multiple CDNs;

• Proxy chain;

• Provider unknown;

• Evidence conflict;

• No CDN evidence found;

• Request blocked.

If a detection tool must return a provider no matter what the situation, it may look certain but is actually more likely to mislead users.

What conclusions should really be retained when identification fails

CDN identification failure is not a single problem.

It may simply be that the wrong domain was tested, or that multiple CDNs are routed by region; the CNAME may have been flattened, or the enterprise may use BYOIP, self-built nodes, or white-label services; there may also be two or three proxy layers in front of the user, with only the outermost layer visible on the public internet.

Therefore, a professional detection result should not provide only a provider name; it should also answer:

1. Which full domain was tested;

2. Which IP the request ultimately connected to;

3. Which network the IP belongs to;

4. What evidence DNS, HTTP, and TLS each provided;

5. Whether different regions and protocol stacks produced the same result;

6. How high the confidence in the conclusion is;

7. Whether multiple CDNs, self-built nodes, or a proxy chain may exist.

Sometimes the most accurate answer is not 'this is such-and-such CDN,' but:

It can currently be confirmed that the request passed through an edge proxy, but public evidence is insufficient to determine the specific provider.

For CDN detection, acknowledging the limits of identification is more reliable than forcing a provider name based on one vague fingerprint.

Frequently asked questions

1. If CDN detection shows unidentified, does that mean the website does not use a CDN?

No. It only means that the current detection did not obtain sufficient evidence. CNAME cloaking, self-built nodes, white-label CDNs, multiple proxy layers, and WAF blocking can all cause identification failures.

2. Why does the same website identify two CDNs?

It may be multi-CDN routing, CDN layering, residual evidence from migration, different subdomains using different providers, or the outer IP and inner response headers belonging to different proxies.

3. Can a CDN be identified by IP ASN alone?

You cannot rely entirely on it. An ASN indicates the network entity announcing the IP externally, but the website may use partner networks, third-party data centers, shared cloud platforms, or BYOIP. It needs to be combined with CNAME, response headers, and multi-region results.

4. If there is no CNAME, does that mean there is no CDN?

No. CNAMEs may be flattened, the root domain may use ALIAS or ANAME, and proxy DNS may return Anycast IPs directly.

5. Can the Server header determine the CDN provider?

Usually not.ServerIt may come from the origin server, CDN, WAF, or custom rules, and it may also be overridden. Unless it is consistent with other independent evidence, it can only serve as a weak clue.

6. How can you tell whether a detected IP is a CDN node or an origin server?

If the domain returns multiple edge IPs across regions, the IPs belong to a CDN or proxy network, and they have cache and node response characteristics, it is usually more like a CDN entry point. Ordinary public internet detection cannot absolutely confirm the true origin server based on a single IP alone.

7. When one CDN is layered over another, can the inner provider be identified?

Not necessarily. Ordinary users connect first to the outer CDN, and the inner provider may be discovered only if its characteristics leak through CNAMEs, response headers, or other public fields.

8. Why should CDN identification results show confidence?

Because different evidence has different reliability. A brand CNAME and a vendor-specific response header combination are usually more reliable than a shared ASN or a singleX-Cachefield. Showing confidence helps avoid packaging 'possible' as 'certain.'