Can’t detect a CDN—is none in use, or was it just not identified?

You enter a domain, click Check, wait a few seconds, and the result tells you only one thing: No CDN detected.

At this point, many people’s first reaction is, “This website doesn’t use a CDN.” Others immediately suspect the tool is inaccurate, because they clearly enabled acceleration in the control panel.

Both scenarios are possible, but neither conclusion can be drawn from a single “not detected” result.

CDN detection is essentially about looking for evidence in the public network: whether DNS points to a CDN scheduling domain, who owns the response IP, whether response headers contain vendor fingerprints, and whether different regions connect to different nodes.

When there is enough evidence, the specific provider can be identified; when evidence is hidden, requests are blocked, or samples are insufficient, the only possible result is “not detected.”

Keep one thing in mind:

“No CDN detected” means the current check did not obtain enough evidence. It does not prove that the website is not using a CDN.

What exactly is the difference between “not using a CDN” and “not detected”?

Detection results can be understood as four states:

Truly establishing that no reverse-proxy CDN is in use usually requires additional pieces of information to corroborate one another.

For example: the site owner confirms that CDN configuration is not enabled; public DNS points directly to the origin server; and there is no corresponding traffic in the CDN logs.

If you are just an ordinary visitor, you can only observe public signals. The most rigorous statement is “no obvious CDN evidence has been detected so far,” not “this website definitely does not use a CDN.”

Why can a website use a CDN yet still not be detected?

1. The wrong domain was checked: the main site is not using it, but static assets are

This is the most common and easily overlooked scenario.

A website may host its pages on:

www.example.com

while placing images, JavaScript, and downloadable files on:

static.example.com
img.example.com
download.example.com

If you only checkwww.example.com, the result may show no CDN; however, most resources users actually load are already accelerated by the static asset domain.

Some websites also take the bare domainexample.comand 301 redirect it towww.example.com. Checking the bare domain and checking the final destination hostname can also produce different results.

So the first step is not to switch tools, but to determine:Which business domain are you actually checking?

2. CDN configuration exists, but proxying is not actually enabled

“Adding a domain to a CDN platform” and “live traffic already passing through the CDN” are not the same thing.

Common cases include:

• The CNAME has not been changed;

• DNS still points to the origin server;

• The CDN domain is paused, under review, or being deployed;

• Only the certificate configuration is complete; traffic has not been switched over;

• A record is set to DNS only, without proxying enabled.

For example, Cloudflare’s officialproxy status documentationclearly distinguishes between Proxied and DNS-only: the former routes HTTP/HTTPS traffic through Cloudflare, while the latter only provides DNS resolution and directly returns the origin server address.

In this case, the detection tool failing to find a CDN is not a “false negative”; the request being checked simply does not pass through the CDN.

3. The CNAME was flattened, hiding the provider fingerprint

Many checks look at CNAME first, becauseexample.cdnprovider.netthese kinds of scheduling domains often carry fairly clear provider fingerprints.

However, root domains usually cannot use a regular CNAME; some DNS services return the final A/AAAA address directly through ALIAS, ANAME, or CNAME Flattening. As a result, the querier sees only the IP, not the intermediate CDN scheduling domain.

Cloudflare’sCNAME Flattening documentationexplains this mechanism: the DNS platform follows the CNAME chain to find the final IP and then returns that address directly to the querier.

So “no CNAME found” only means there is no CNAME in the public answer; it cannot by itself prove that no CDN is used.

4. A custom domain or white-label CDN is used

Some CDNs provide a vendor domain as the CNAME target, which is highly recognizable; others use the customer’s own scheduling domain, a white-label domain, or a generic cloud platform entry point.

For example, CloudFront lets users configure a custom domain and certificate for a distribution, and DNS can point to the distribution through a CNAME or a root domain ALIAS.

AWS’sCloudFront domain configuration documentationalso explains that a root domain can be connected through ALIAS, so a regular CNAME does not necessarily appear in public results.

When the vendor name does not appear directly in the DNS chain, detection must rely on IP ownership, TLS, and HTTP characteristics. If those signals are also unclear, the result may only be “suspected proxy network use,” without being able to report the brand accurately.

5. Vendor-specific response headers are removed or rewritten

Common CDNs may addVia,Age,X-Cache, request IDs, or custom vendor fields, but these headers are not mandatory.

A site can remove some response headers through edge rules, or it may layer gateways, load balancers, or another proxy before or after the CDN. The fields ultimately returned to the client may not retain the original vendor fingerprints.

The reverse is also true: seeing aX-Cachedoes not immediately identify which CDN it is, because an origin server or an ordinary reverse proxy can also add a field with the same name.

Response headers should be treated as one piece of evidence, not the only answer.

6. Requests pass through the CDN, but content is not cached

This is where many site owners most easily misjudge the situation:

没有看到 HIT ≠ 没有经过 CDN

Login pages, shopping carts, API endpoints, and responses withCache-Control: privateorno-storemay simply not be cached by nature.

A CDN can also provide only TLS termination, WAF, DDoS protection, and dynamic acceleration, with every request still going back to the origin.

Google Cloud’sCloud CDN troubleshooting documentationalso notes that only responses that meet caching conditions are cached, and judgments should be based on console configuration, response headers, and logs.

In other words, repeatedMISS,BYPASS, or noAgeat all cannot by itself prove that the request did not pass through a CDN.

7. Multiple CDNs are used, or traffic is routed by region and ISP

A website may use two or even more CDNs at the same time:

• Mainland China goes through domestic providers, while overseas traffic goes through global providers;

• China Mobile, China Unicom, and China Telecom use different routes;

• When the primary CDN fails, traffic automatically switches to a backup CDN;

• Some traffic is used for canary testing;

• IPv4 and IPv6 use different entry points.

If a check is initiated from only one region and one network, it sees only the path that was hit at that moment. A node failing to identify something does not mean other regions will see the same result.

For these websites, it is best to useCdnChart Website Speed Testto cross-test from different regions, then compare response IPs, ISPs, ASNs, and HTTP results.

8. WAF, anti-crawler, or access policies block probe requests

Detection usually requires at least DNS resolution, a TLS handshake, and an HTTP request.

If the website restricts data center IPs, specific regions, User-Agent, or access frequency, the probe node may only receive a 403, a CAPTCHA page, a connection reset, or a timeout.

In this case, the tool may see an error page returned by the WAF, or it may not obtain enough HTTP evidence at all.

This should be understood as “detection blocked,” not “no CDN.”

9. A self-built edge network or smaller provider is used

CDN identification relies on a maintainable fingerprint database.

Large providers usually have relatively stable CNAME rules, IP ranges, ASNs, or response fields; self-built CDNs, regional providers, and newly launched products may have few public fingerprints and may not yet be indexed.

In this case, you may observe phenomena such as “different IPs in different regions” or “responses coming from a shared edge network,” but you may not be able to name the provider accurately.

For a detection platform, it is better to display unknown than to force a guess just to provide an answer.

If CDN detection fails to identify anything, how should you verify it?

The following process does not require you to be an operations engineer. Ordinary users can complete the first four steps; site owners can then continue by checking the console and logs.

Step 1: Confirm the final domain being accessed

First check whether the domain redirects:

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

Focus on:

• Whether the final URL redirects from the bare domain towww;

• whether it redirects to another branded domain;

• what the final connection IP is;

• whether it returns 200 normally, or returns 403, 5xx, or times out.

If the final domain has changed, put the redirected domain back into theCDN detection tooland check.

Step 2: Query A, AAAA, and CNAME separately

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

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

Do not query only A records. Some websites use different IPv4 and IPv6 paths, and the bare domain andwwwmay also use completely different connection methods.

The results can be interpreted as follows:

• A clear CDN scheduling domain appears: this is relatively strong evidence;

• Only a CDN network IP is returned: traffic may pass through a CDN, but other signals must also be considered;

• Only an ordinary cloud host or origin server IP is returned: there may be no proxy, or it may be a hard-to-identify cloud edge entry point;

• No CNAME: it may be a direct A record connection, or it may be ALIAS or CNAME flattening.

Step 3: Compare DNS results using 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 the answers differ, it may involve DNS caching, geographic routing, multiple CDNs, or configuration changes.

Public resolver results still cannot represent all real users, so multi-region testing is still needed.

Step 4: Review the complete response headers, not just one field

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

Pay particular attention to:

• Via;

• Age;

• X-Cacheor similar cache status;

• vendor request ID;

• Server;

• certificate and TLS connection details;

• HTTP status code and redirect location.

Some CDNs addAge. For example, in the example given in the Google Cloud documentation,Ageindicates that the response was served from an existing cache entry.

However, the absence of these fields still cannot rule out a CDN, because the fields may be hidden, or the current content may not be cacheable.

You can request a public static file repeatedly and observe:

for i in 1 2 3; do
  curl -sS -D - -o /dev/null https://www.example.com/assets/logo.png
done

Do not use pages with login state, order information, or user data for cache testing.

Step 5: Test from multiple regions and networks

A local query represents only one access path.

When usingCdnChart Website Speed Test, you can compare results from different probe regions side by side:

• whether the response IP changes;

• whether IP ownership and ASN are consistent;

• whether domestic and overseas traffic hit different providers;

• whether IPv4 and IPv6 paths are consistent;

• whether 403s or timeouts are concentrated in certain regions.

If multiple regions all connect to the same clear origin server IP, this only indicates that “no obvious edge scheduling has been observed.” If different regions connect to different networks, you should continue to determine whether it is a CDN, cloud load balancing, DNS scheduling, or a multi-active architecture.

Step 6: Site owners check the console and logs

For your own website, the most reliable evidence always comes from first-party configuration:

1. whether the CDN accelerated domain is enabled;

2. whether live DNS already points to the current distribution or proxy entry point;

3. whether the CDN access logs contain corresponding requests;

4. whether the connection sources in the origin logs are the CDN origin-facing network;

5. whether cache rules allow the test resource to be cached;

6. whether the WAF or access control blocked the probe node.

You can place a small static file with no sensitive information on a site you control, for example:

/_cdn-check.txt

Write a clear version identifier into the file, then check requests, cache status, and logs in the CDN console; if necessary, perform a cache purge and observe subsequent requests.

Because different regions may hit different cache nodes, a singleMISSmay not immediately produceHIT, and the vendor console and logs should still be the deciding factor.

Based on the results, what is a more reliable judgment?

Which judgment methods are most prone to error?

“No CNAME, so no CDN is being used”

Not accurate. Root domain ALIAS, CNAME flattening, and A record connections may all avoid showing a regular CNAME.

“No cache HIT, so no CDN is being used”

Not accurate. Dynamic content, private responses, first visits, and deliberate cache bypass may all lack HITs, but traffic still passes through the CDN.

“The IP belongs to a cloud provider, so it must be that provider’s CDN”

Not accurate. The same cloud network may carry compute, load balancing, hosting platforms, and CDN services at the same time. An ASN only proves network ownership; it cannot by itself prove a specific product.

“Three different detection tools failed to identify it, so there must be none”

That is also not rigorous enough. Multiple tools may rely on similar public fingerprint databases. If a website hides the same evidence, adding more tools will not automatically fill in the gaps.

FAQ

What does “not detected” mean in CDN detection?

It usually means the public signals collected—DNS, IP, HTTP, TLS, and others—are insufficient to determine the CDN provider.

It may mean no CDN is used, or that fingerprints are hidden, detection is blocked, the CDN is used only on some domains, or the provider has not yet been indexed.

CDN detection shows no CDN is used, but the website loads quickly. What’s going on?

Fast speed does not necessarily mean a CDN is in use.

The origin server may be close to you or have good performance, or the site may use cloud load balancing, dedicated lines, or other network optimizations.

Conversely, a website using a CDN may also load slowly because of slow origin fetches, a low cache hit rate, or network route issues.

Why can the same domain be identified when checked from a different region?

The website may use geographic DNS, multiple CDNs, or ISP-based routing, so different regions enter different networks; or requests from one region may be blocked by the WAF while another region receives a complete response.

A single-node result cannot represent global access paths.

Can a single response header directly identify the CDN provider?

Some provider fields are highly distinctive, but reliable identification should still combine CNAME, IP/ASN, TLS, and multi-region results.

Generic fields may be rewritten, forged, or added by an ordinary reverse proxy.

My own website clearly has CDN enabled. Why is it still not detected?

First check whether the detection domain is correct, whether live DNS has been switched, whether proxying is enabled, and whether requests are blocked by the WAF.

Then check the CDN console and access logs. Real request records in the console are more reliable than any external fingerprint judgment.

Finally: “Not detected” is both a result and a statement of limits

CDN detection is not about slapping a label on an IP as soon as you see one. A reliable judgment usually requires combining CNAME, response IP and ASN, HTTP response headers, TLS certificates, and multi-region observations.

Therefore, when you encounter “not detected,” the correct order of handling is:

1. confirm that you are checking the final business domain;

2. check A, AAAA, and CNAME separately;

3. review the complete HTTP response and redirects;

4. use multi-region probes for cross-validation;

5. if it is your own site, go back to the CDN console and logs to confirm.

You can first useCdnChart CDN Checkto view the public evidence for a domain, then useCdnChart Website Speed Testto compare the response IPs actually hit in different regions.

To learn how the platform combines CNAME, response headers, ASN, and TLS signals, continue readingHow to Identify the CDN a Website Usesandthe CdnChart Methodology.