Which CDN detection tool is best? What information should be returned after entering a domain

To find out which CDN a website uses, many people open a CDN detection tool, enter the domain, and wait for the page to show “Cloudflare,” “Alibaba Cloud CDN,” or another provider name.

The problem is that returning only a provider name is not enough to prove the identification is reliable.

A domain may use CNAME cloaking or flattening, edge IPs may belong to a cloud provider rather than a CDN vendor, and multiple CDNs may be dynamically scheduled by region. Some sites even use only a reverse proxy, WAF, or load balancer, without a full CDN service.

Therefore, when judging which CDN detection tool is better, the key is not how many brands it can identify, but whether it can answer three questions:

1. Why does it conclude that this domain uses a particular CDN?

2. Is the evidence from DNS, IP, HTTP, or TLS?

3. If different pieces of evidence conflict, does the tool honestly flag the uncertainty?

A genuinely useful CDN detection result should return the identification conclusion, raw evidence, confidence level, data timestamp, and any necessary risk warnings—not just a seemingly definitive answer.

Which CDN Detection Tool Is Best? First Check Whether It Can Explain Its Results

Different tools have different strengths; you cannot judge them solely by a simple interface or fast queries.

If you only need a quick CNAME check, an ordinary DNS tool is sufficient; if you need to determine which CDN a website actually uses, choose a comprehensive tool that can cross-validate multiple dimensions.

CdnChart'sCDN detection toolCdnChart's CDN detection tool currently cross-checks suspected CDN vendors using the CNAME chain, HTTP response headers, public network signals, and other dimensions, and displays the identification evidence. The page also states that results include a confidence level and update time, rather than treating a single characteristic as a final conclusion.

After you enter a domain, the first item should return a clear identification conclusion

The top of the detection result should first give users a conclusion they can understand directly, for example:

• Suspected Cloudflare use;

• Akamai-related network characteristics detected;

• May use two CDNs simultaneously;

• Reverse proxy detected, but the CDN vendor cannot yet be confirmed;

• Insufficient public CDN characteristics found;

• The domain cannot be resolved, or the target refused access.

It is best to use different levels such as “confirmed,” “high probability,” “suspected,” or “insufficient evidence,” rather than giving every result the same assertive tone.

The tool should also distinguish between a “network service provider” and a “CDN product.” That an IP belongs to a large cloud vendor only indicates that the request entered a network controlled by that vendor; it does not directly prove that the website purchased a specific CDN, WAF, or DDoS protection product from that vendor.

Likewise, detecting Cloudflare's network does not mean the tool can further confirm whether the website uses a free plan, an enterprise plan, or has enabled a specific security feature.

The CNAME chain is an important starting point for CDN identification

A more complete result should show the entire CNAME chain from the user-entered domain to the final resolution target, not just the last IP.

For example:

www.example.com
→ www.example.com.cdn-provider.example
→ edge-region.example
→ 203.0.113.10

Vendor domain suffixes in CNAMEs often have strong identification value. According toRFC 9499's explanation of DNS terminology, a CNAME record indicates that a name is an alias and points to the corresponding canonical name.

Users can also check this themselves:

dig www.example.com CNAME
dig www.example.com A
dig www.example.com AAAA

On Windows, you can use:

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

The question is not simply whether a CNAME exists, but:

• What domain the CNAME ultimately points to;

• Whether there are multiple levels of CNAME;

• Whether IPv4 and IPv6 enter different networks;

• Whether the root domain andwwwsubdomains use the same configuration;

• Whether different DNS servers return different results.

However, not finding a CNAME does not mean a CDN is not in use. A root domain may use ANAME, ALIAS, or CNAME flattening, and some services return Anycast IPs directly. CNAME should therefore be treated as one important piece of evidence, not the only criterion.

Response IP, ASN, and IP ownership information must not be omitted

A CDN detection tool should also return the currently resolved IPv4, IPv6, ASN, and IP registration information.

Useful fields include:

• Response IP;

• IPv4 or IPv6;

• ASN number;

• ASN name;

• IP registry;

• Country or region;

• Network prefix;

• Query node;

• DNS resolution time;

• Data update time.

ASN is better suited than IP geolocation alone for determining network ownership. Users can query public registration data for IP addresses and autonomous systems via RDAP. ICANN'sRDAPdescription explains that this protocol is used to access current registration data and is gradually replacing traditional WHOIS queries.

But IP ownership likewise cannot independently prove a CDN vendor. Common cases include:

• The CDN leases addresses from a third-party operator;

• The website runs on a cloud server but does not use a CDN;

• Multiple products share the same edge network segment;

• IP registration information still shows a historical holder;

• Anycast addresses are announced simultaneously in multiple regions;

• The location shown in the database is only a registered or estimated location.

So if a tool draws a definitive conclusion solely from “the IP belongs to a certain cloud vendor,” the probability of a false positive is not low.

HTTP status codes and response headers should show raw evidence

After the request reaches the target, the detection tool should display the HTTP status code, protocol version, redirect chain, and CDN-related response headers.

Fields worth noting may include:

Server
Via
Age
Cache-Status
X-Cache
X-Cache-Hits
X-Served-By
CF-Ray
CF-Cache-Status
X-Amz-Cf-Pop
X-Amz-Cf-Id
X-Akamai-Transformed

Not every website returns these fields, and no single field can cover all CDN vendors.

According toHTTP semantics defined in RFC 9110, the response status code describes the outcome of request processing; response headers carry fields related to the message and response handling. For CDN identification, the status code helps determine whether the detection request actually reached the target successfully, while characteristic response headers can provide clues about the vendor, node, or cache path.

You can check manually with the following commands:

curl -I -L https://www.example.com/

Focus on:

• Whether the final status code is200;

• whether it first goes through301or302redirect;

• Whether the domain changes with each redirect;

• Whether CDN-characteristic response headers appear

• Age,Cache-Statusor whether vendor cache headers indicate a cache hit;

• 403or429whether they are generated by security policies, rate limiting, or anti-crawler rules.

Note that site owners can hide or modifyServerand other response headers, and some security gateways also rewrite content returned by the backend. A field namedX-Cachemay even be added by the site itself, so a single response header cannot serve as absolute evidence.

TLS certificates and SNI can provide supporting clues

For HTTPS websites, detection results can also return:

• TLS protocol version;

• Domains covered by the certificate;

• Certificate issuer;

• Certificate validity period;

• Whether the certificate chain is complete;

• ALPN negotiation result;

• Whether HTTP/2 or HTTP/3 is currently supported;

• The certificate returned when performing an SNI handshake with the specified domain.

When checking TLS information, you must preserve the correct domain and SNI. Because a single edge IP may host many HTTPS websites, the certificate and response obtained by accessing the IP directly usually have no diagnostic value.RFC 6066explains the purpose of SNI: the client provides the target server name during the TLS handshake, enabling multiple virtual services on the same network address to return the appropriate configuration.

To inspect a certificate manually, you can use:

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

To verify whether a response IP can serve that domain, use:

curl --resolve www.example.com:443:203.0.113.10 \
  -I https://www.example.com/

--resolvetemporarily directs the domain to the target IP while preserving the HTTP Host and TLS SNI. Compared with accessinghttps://203.0.113.10/, this method is closer to the real access process.

However, a certificate issued by a common CA does not prove CDN identity; multiple CDNs may use the same CA. TLS information is better suited for confirming whether the domain is correctly served by that edge node and for checking whether the certificate and SNI configuration are normal.

A good CDN detection tool should show “why the evidence holds”

An ideal detection result should not be just one line with a vendor name; it should break out the evidence. For example:

If the CNAME points to Vendor A, but the response IP and HTTP characteristics look more like Vendor B, the tool should not force a single answer. This could be a multi-layer proxy, CDN-over-CDN, an incomplete migration, or outdated fingerprint data.

A more reasonable output would be:

主要判断：疑似使用厂商A
置信度：中等

支持证据：
- CNAME后缀与厂商A匹配
- 两个响应头符合厂商A特征

冲突信息：
- 当前响应IP登记在厂商B的ASN下

建议：
- 从更多地区重新检测
- 分别检查根域名与www子域名

Only such a result is easy for users to verify and avoids packaging an algorithmic guess as established fact.

Why CDN detection needs multi-region results

Querying a domain from only one region may show just a small part of the scheduling system.

A multi-CDN system may return different providers based on the user's country, ISP, network quality, failure status, or business rules. Even with the same CDN, the response IPs resolved by Beijing Telecom, Guangzhou Mobile, and overseas nodes may be completely different.

If the goal is to confirm multi-CDN scheduling or node coverage, you can first usethe CDN detection toolto view providers and identification evidence, then use CdnChart'swebsite speed test toolto observe the response IP, IP location, status code, resolution time, connection time, and total time returned in different regions and by different ISPs.

CdnChart's current website speed test page displays test results by China Telecom, China Unicom, China Mobile, as well as Hong Kong, Macao, Taiwan, and overseas nodes, and provides fields such as response IP, IP location, status, resolution, connection, download, redirect, and total time.

Here it is important to distinguish the responsibilities of the two features:

• CDN detection answers “which CDN appears to be used, and what is the basis for that judgment”;

• Multi-node speed testing answers “which IPs are reached in different regions, and whether speed and status are consistent.”

Speed alone cannot prove vendor identity, but multi-region response IPs can help reveal multi-CDN setups, scheduling anomalies, and cases where some regions are not connected to a CDN.

After entering a domain, the detection scope and time should also be returned

CDN fingerprints are not permanent. Vendors add IP ranges, adjust CNAME suffixes, and modify response headers, and a website may switch providers at any time.

Therefore, detection results should at least specify:

• Detection time;

• Fingerprint database update time;

• Query location;

• Specific hostname queried;

• Whether redirects are followed;

• Whether IPv6 is tested;

• HTTP request method;

• Whether the request was blocked;

• Whether raw evidence can be expanded for viewing.

If a tool only shows a vendor logo without showing the detection time and the hostname entered, users can hardly tell whether the result corresponds to the current domain, a historical cache, or another website after a redirect.

Also pay special attention to the difference between a “domain” and a “website.” The following addresses may use completely different providers:

example.com
www.example.com
static.example.com
api.example.com
download.example.com

Detectionwww.example.comresults cannot automatically represent all subdomains.

Situations that easily cause CDN detection tools to misjudge

Private CDNs or small providers

Private CDNs have no public CNAME suffixes, IP ranges, or response header fingerprints; the tool may identify only the hosting network and cannot determine the specific product.

The root domain hides the CNAME

The DNS provider may perform CNAME flattening at the authoritative end and return only A or AAAA records externally. In this case, you must use IP, ASN, and HTTP characteristics to make a judgment.

The website uses multiple CDNs simultaneously

Different regions, ISPs, or business subdomains may be routed to different CDNs. Seeing only one provider in a single query does not rule out others.

WAF, reverse proxy, and CDN are mixed together

The tool may identify the outermost proxy network but cannot determine whether another CDN layer lies behind it, nor can it confirm from network characteristics alone whether a WAF is enabled.

The detection request is blocked

If the tool receives403,429a connection timeout, or a CAPTCHA page, the returned response headers may come from a security block page rather than normal business content.

IP location is mistaken for the node's physical location

IP databases usually provide only registered or estimated locations. They cannot precisely prove the city where the server room is located, let alone that the request was processed there.

When choosing a CDN detection tool, use the following criteria

If your only goal is to view domain resolution, choose a DNS tool that can fully display CNAME, A, and AAAA records.

If you need to determine which CDN provider a website uses, prioritize tools that also have the following capabilities:

• Display the complete DNS resolution chain;

• Return the response IP and ASN;

• Preserve raw HTTP response headers;

• Explain the specific identification evidence;

• Provide a confidence level rather than an absolute conclusion;

• Show the detection time and data update time;

• Support identification of multiple CDNs or conflicting results;

• Integrate with multi-region node speed testing;

• Clearly explain why identification failed.

CdnChart is suitable for preliminary provider identification and evidence verification; if you also need to assess actual access conditions in different regions, you can continue with multi-node speed testing. The platform'stesting methodology and scoring criteriaprovide details on probes, samples, metrics, and known limitations. Detection results are useful for uncovering clues and troubleshooting configurations, but they cannot replace internal enterprise network logs, CDN console records, or vendor contract confirmation.

Frequently asked questions

1. If a CDN detection tool shows “not identified,” does that mean the website does not use a CDN?

No. “Not identified” only means the currently available public evidence is insufficient. Private CDNs, hidden CNAMEs, custom response headers, delayed IP database updates, and blocked detection requests can all prevent a tool from confirming the vendor.

2. If a CNAME points to a CDN, can you be sure the website is using it?

A CNAME is strong evidence, but you should still check the final response IP and HTTP results. Migration remnants, misconfigurations, or expired access domains can all create the appearance that DNS is connected to a CDN while actual requests do not pass through it correctly.

3. Why do two CDN detection tools give different results?

They may use different fingerprint databases, IP databases, query regions, and decision rules. Compare the CNAME, ASN, response headers, and detection times shown by each, rather than only the final vendor name.

4. Is it normal for detection results to show two CDN vendors?

Yes. A website may use multiple CDNs by region, or adopt CDN-over-WAF, CDN-over-CDN, or dual-track operation during migration. You should query repeatedly from multiple regions and check each business subdomain separately.

5. Can checking only the IP address identify a CDN?

It provides only partial clues. Shared networks, leased addresses, and cloud platform IPs can all cause misjudgments. A more reliable approach is to cross-validate the IP with the CNAME, ASN, HTTP response headers, and TLS handshake results.

6. Can CDN detection determine whether a cache hit occurred?

Sometimes.Age,Cache-Statusand vendor-specific cache headers may show HIT, MISS, or cache residence time, but not all websites expose these fields. The absence of cache headers does not necessarily mean there is no cache.

7. Can CDN detection results be used as a basis for changing vendors?

They can serve as a basis for preliminary investigation, but cannot alone determine a migration. Formal selection should also test real business URLs, compare latency, availability, throughput, security capabilities, price, and technical support in target user regions, and validate through a trial or POC.