How to Detect the CDN and Hosting Provider of Any Website

Knowing what CDN or hosting provider a website uses is useful for a surprising number of reasons. Performance engineers compare CDN choices. Security teams map external attack surfaces. Sales teams use technographic data to qualify leads. Competitive researchers study infrastructure decisions across an entire market—from CDN selection to which sites run WordPress.

The problem is that most websites don’t advertise their infrastructure. There’s no “Powered by Cloudflare” badge in the footer. But the evidence is there if you know where to look: DNS records, HTTP response headers, TLS certificates, and IP address ranges all leave fingerprints.

This guide covers four practical methods to identify CDN and hosting providers, explains why browser extensions miss most of them, and shows how to automate the process with an API.

Method 1: DNS Lookup (CNAME Records)

DNS is the most reliable way to identify a CDN or hosting provider. When a company uses a CDN, they typically create a CNAME record pointing their domain to the provider’s infrastructure. These records are public, always available, and cannot be hidden without changing providers.

You can check CNAME records with dig or nslookup:

$ dig www.example.com CNAME +short
d1a2b3c4d5e6f7.cloudfront.net.

$ nslookup -type=CNAME www.example.com
www.example.com  canonical name = d1a2b3c4d5e6f7.cloudfront.net.

That *.cloudfront.net CNAME immediately tells you the site uses Amazon CloudFront as its CDN. Each major provider has distinct CNAME patterns:

• Cloudflare — Uses its own authoritative nameservers (*.ns.cloudflare.com). When Cloudflare’s proxy mode is enabled (the orange cloud), the CNAME target is hidden behind Cloudflare’s anycast IPs. However, the NS records still reveal Cloudflare, and HTTP responses include the cf-ray header.
• Amazon CloudFront — CNAME targets follow the pattern d*.cloudfront.net (e.g., d1a2b3c4d5e6f7.cloudfront.net).
• Fastly — CNAME targets use *.fastly.net or specific map patterns like *.map.fastly.net.
• Akamai — CNAME targets use *.akamaiedge.net, *.akamaized.net, or *.edgekey.net.
• Vercel — CNAME targets point to cname.vercel-dns.com.
• Netlify — CNAME targets point to *.netlify.app.

Method 2: HTTP Response Headers

HTTP headers are the second most useful signal. CDN providers inject proprietary headers into responses, and most don’t strip the Server header by default.

Run a simple curl -I to see the response headers:

$ curl -sI https://example.com | grep -iE "server|x-cache|x-cdn|via|cf-ray|x-amz"
Server: cloudflare
CF-Ray: 8a1b2c3d4e5f6-IAD

Key headers to look for:

• Server: cloudflare — Cloudflare identifies itself directly in the Server header.
• CF-Ray — Present on every Cloudflare response. The suffix (e.g., -IAD) indicates the edge PoP that served the request.
• X-Amz-Cf-Id or X-Amz-Cf-Pop — Amazon CloudFront request identifiers.
• X-Cache: HIT from cloudfront — Another CloudFront indicator, also showing cache status.
• Via: 1.1 varnish — Fastly runs Varnish at its edge nodes. The Via header often reveals this.
• X-Served-By — Fastly includes this with the cache node identifier.
• Server: AmazonS3 — Sites served directly from S3 buckets.
• X-Vercel-Id — Vercel deployments include this header.
• X-NF-Request-ID — Netlify request tracking header.

The limitation of HTTP headers is that operators can strip or spoof them. A well-configured reverse proxy can remove Server and X-Powered-By headers entirely. That’s why HTTP headers work best as a complement to DNS, not a replacement.

Method 3: TLS Certificate Inspection

The TLS certificate presented during the HTTPS handshake reveals information about the hosting infrastructure. You can inspect it with openssl:

$ echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject
issuer=C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3
subject=CN=example.com

When the issuer organization is “Cloudflare, Inc.”, you know the site is proxied through Cloudflare’s network—even if DNS or HTTP headers were somehow inconclusive. Other certificate patterns:

• Cloudflare — Issuer includes “Cloudflare Inc” in the organization or CN field. Cloudflare issues its own edge certificates for proxied domains.
• AWS/CloudFront — Certificates issued by “Amazon” via Amazon Trust Services, often with the issuer CN “Amazon RSA 2048 M02” or similar.
• Let’s Encrypt — Widely used by Vercel, Netlify, Heroku, and other PaaS platforms for automatic certificate provisioning. The issuer will show “Let’s Encrypt” or “R3” / “R10”.
• Fastly — Uses certificates from GlobalSign or Let’s Encrypt. The Subject Alternative Names (SANs) may include Fastly-managed wildcard domains.

TLS inspection is particularly useful for confirming Cloudflare usage. Even when a site uses Cloudflare’s proxy mode (which hides CNAME records), the Cloudflare-issued certificate is still visible during the TLS handshake.

Method 4: IP Address Ranges

Every major CDN operates from known IP address ranges. By resolving a domain to its IP address and checking which range it falls into, you can identify the CDN.

$ dig +short example.com
104.21.45.123

# Check: is this a Cloudflare IP?
# Cloudflare publishes their ranges at https://www.cloudflare.com/ips/

Cloudflare publishes its IP ranges publicly at cloudflare.com/ips. AWS publishes theirs at ip-ranges.amazonaws.com/ip-ranges.json (filterable by service like CloudFront). Fastly, Akamai, and other CDNs also publish their ranges or have well-documented netblocks.

This method works but is the most maintenance-intensive: IP ranges change as providers expand their networks, so any local database of ranges needs regular updates. It’s best used as a confirmation signal alongside DNS and header analysis.

Why Browser Extensions Miss This

Browser extensions like WhatRuns, Wappalyzer, and BuiltWith’s extension operate inside the browser sandbox. They can read the DOM, inspect JavaScript globals (which is how they detect JavaScript frameworks), and see HTTP response headers that the browser exposes. But they cannot:

• Perform DNS lookups — Browsers don’t expose DNS resolution details to extensions. A CNAME chain that reveals CloudFront, Fastly, or Akamai is invisible.
• Inspect TLS certificates — The browser handles the TLS handshake internally. Extensions cannot read the certificate issuer or Subject Alternative Names.
• Check IP address ranges — Extensions don’t have access to the resolved IP address of the site they’re viewing.

This means browser extensions can sometimes detect Cloudflare (because it sets a Server: cloudflare header and the CF-Ray header), but they’ll miss CDNs that don’t self-identify in HTTP headers. They’ll also miss hosting providers entirely when the only evidence is in DNS CNAME records. For more on this gap, see DNS + TLS Detection vs Browser Extensions.

Automating Detection with the DetectZeStack API

Running dig, curl -I, and openssl manually works for one-off checks, but it doesn’t scale to hundreds or thousands of domains. The DetectZeStack API combines all four detection methods into a single request. You can also integrate this into automated workflows—including AI agents via the MCP protocol—to scan infrastructure at scale without writing custom parsing logic.

The API resolves the full CNAME chain and matches against 111+ DNS CNAME signatures covering CDNs, hosting platforms, SaaS providers, and cloud infrastructure. It also inspects HTTP headers (using Wappalyzer’s 7,200+ fingerprint database), checks TLS certificates, and analyzes custom header patterns—all in one call.

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=shopify.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.technologies[] | select(.categories[] | contains("CDN") or contains("PaaS"))'
{
  "name": "Cloudflare",
  "categories": ["CDN"],
  "confidence": 80
}
{
  "name": "Fastly",
  "categories": ["CDN"],
  "confidence": 100
}

The confidence value reflects the detection method: 100% for HTTP header matches, 80% for DNS CNAME matches, 70% for TLS certificate matches. Even when a site blocks HTTP requests entirely, DNS and TLS detection still return results with a scan_depth: "partial" response. Note that Shopify uses its own CDN infrastructure—a detail that shows up clearly in DNS CNAME records and is a useful signal for e-commerce platform detection.

Common CDN and Hosting Fingerprints

Here’s a reference table of fingerprints for the most common CDN and hosting providers. Each row shows the DNS, header, and TLS signals you can look for:

Edge Cases: When Detection Gets Complicated

Not every website fits neatly into the patterns above. Here are the scenarios that make CDN detection harder:

Multi-CDN setups

Large-scale sites sometimes use multiple CDNs simultaneously, routing traffic through different providers based on geography or traffic type. A site might use Cloudflare for its marketing site and CloudFront for its API. DNS-based detection will identify whichever CDN serves the specific domain or subdomain you query, but you may need to scan multiple subdomains to get the full picture.

CDN chaining

Some architectures chain CDNs: traffic hits Cloudflare first (for WAF and DDoS protection), then routes to CloudFront or Fastly for origin shielding and caching. In these cases, DNS reveals the outermost CDN (Cloudflare), while HTTP headers may reveal the inner CDN. DetectZeStack’s multi-layer detection is designed to catch both signals.

Reverse proxies hiding the origin

A reverse proxy like Cloudflare in “proxy mode” replaces the origin server’s CNAME with Cloudflare’s own anycast IPs. This hides the origin hosting provider but doesn’t hide Cloudflare itself—the NS records, HTTP headers, and TLS certificate all still identify Cloudflare. To detect the origin behind a CDN, you would need techniques beyond standard DNS resolution, such as historical DNS data or certificate transparency logs.

Vanity CNAMEs

Some CDN configurations use intermediate CNAMEs that don’t obviously match a known provider. For example, a CNAME like edge.company-cdn.com might ultimately resolve to *.akamaiedge.net. This is why resolving the full CNAME chain is essential rather than just checking the first-hop CNAME.