How to Tell if a Website Uses Akamai, Fastly, or CloudFront

To tell whether a website uses Akamai, Fastly or Amazon CloudFront, read its HTTP response headers and match the fingerprint — each CDN leaves a distinct one. Run curl -I https://example.com (or use the DevTools Network tab) and look: Fastly shows x-served-by and a Via header mentioning varnish; Akamai shows x-akamai-* headers and an Akamai-style Server; CloudFront shows a Via naming cloudfront.net plus x-amz-cf-id and x-amz-cf-pop. One request usually settles it. The constant caveat: all three are reverse-proxy CDNs in front of the origin, so you are identifying who delivers the site at the edge, not where the origin is hosted — the CDN deliberately masks that.

It is a focused companion to how to tell if a website uses Cloudflare or another CDN and builds on how to read a website's HTTP response headers and what is a CDN and do you need one.

Why CDN fingerprints are so readable

A CDN works by putting edge servers between visitors and the origin, caching content close to users and adding its own processing. Those edge servers attach their own response headers — cache status, request IDs, the edge location that served you — both for operational reasons and for debugging. Because each provider has its own header conventions, the result is a distinctive fingerprint per CDN that is hard to hide while genuinely using the service. That is excellent news for detection: unlike a Server header that operators routinely strip, CDN markers are part of how the service functions, so they are usually present and recognisable. The three covered here — Akamai (the long-established enterprise CDN), Fastly (the Varnish-based, developer-friendly CDN) and CloudFront (AWS's CDN) — each have a signature you can learn to read at a glance.

Fastly fingerprints

Fastly is built on Varnish, the open-source HTTP cache, and its fingerprint reflects that heritage:

via: 1.1 varnish
x-served-by: cache-lhr-egll1234-LHR
x-cache: HIT
x-cache-hits: 2

The key markers:

• x-served-by — names the Fastly cache node(s) that served the response; the node identifiers are recognisably Fastly.
• Via: ... varnish — Fastly's Varnish foundation shows up in the Via header.
• x-cache: HIT/MISS and x-cache-hits — Fastly's cache status and hit count.

Seeing x-served-by together with a Varnish Via is a strong, reliable indication of Fastly. Some Fastly customers also expose additional debug headers, but the x-served-by/Varnish pair is the dependable core.

Akamai fingerprints

Akamai is the veteran enterprise CDN, and because it is heavily customised per customer, its exact headers vary more than the others — but the family is recognisable:

• x-akamai-* headers — for example x-akamai-transformed, which appears when Akamai has applied transformations to the response.
• Akamai Server value — some Akamai configurations expose an Akamai-style server signature.
• AkamaiGHost — the classic Akamai "Ghost" edge marker, which surfaces in certain configurations and error responses.
• Akamai request/debug headers — enterprise setups may carry additional Akamai-specific headers.

The x-akamai- prefix and Akamai server signatures are the reliable tells. Because Akamai serves many of the largest enterprises and governments, encountering it usually signals a high-traffic, security-conscious operation.

CloudFront fingerprints

Amazon CloudFront uses the AWS x-amz- header family, which makes it distinct from the other two:

via: 1.1 <hash>.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR50-C1
x-amz-cf-id: <long-identifier>
x-cache: Hit from cloudfront

The markers:

• Via: ... cloudfront.net (CloudFront) — names CloudFront explicitly.
• x-amz-cf-id — a CloudFront request identifier.
• x-amz-cf-pop — the edge point of presence (an airport-style code naming the city that served you).
• x-cache: Hit from cloudfront — CloudFront's cache status, phrased distinctively.

That x-amz-cf- prefix is unique to CloudFront and separates it cleanly from Fastly and Akamai. CloudFront is part of AWS, so its presence also ties into AWS hosting detection — though, as ever, CloudFront can front an origin hosted anywhere.

The comparison table

Signal	Fastly	Akamai	CloudFront
Signature header	x-served-by	x-akamai-* (e.g. x-akamai-transformed)	x-amz-cf-id
Via header	... varnish	(varies; Akamai infra)	... cloudfront.net (CloudFront)
Edge / node marker	Fastly cache node in x-served-by	AkamaiGHost (some configs)	x-amz-cf-pop (edge POP code)
Cache status	x-cache: HIT + x-cache-hits	Akamai cache headers	x-cache: Hit from cloudfront
Underlying tech	Varnish	Akamai proprietary	AWS CloudFront
Typical user	Developer-led, media, ecommerce	Large enterprise, government	AWS-based sites, broad range

Match the signature header and the Via value and you have the provider; the cache and edge markers confirm it.

Method 1: curl -I

The fastest check is one command:

curl -sI https://example.com

Read the headers and match against the table: x-served-by + Varnish Via → Fastly; x-akamai-* → Akamai; x-amz-cf-id + cloudfront.net Via → CloudFront. Because curl -I is scriptable, you can classify a whole list of domains by CDN in one pass. If the bare domain redirects, follow it with curl -sIL so you read the final response's headers — the redirect may not carry the CDN markers, a point from the HTTP headers guide.

Method 2: the DevTools Network tab

In the browser, open DevTools (F12), go to the Network tab, reload, and click the main document request. The Response Headers panel shows the CDN's signature headers in a clear list. The Network tab adds two advantages: you can inspect individual assets (sometimes images or static files are served by a different CDN than the HTML, revealing a multi-CDN setup), and you can watch the cache status change across requests (HIT vs MISS), which confirms the CDN is genuinely caching rather than merely proxying. This is the friendliest method for exploring a site's delivery in depth.

Method 3: detection tools and DNS hints

Tools summarise CDN detection automatically. Wappalyzer and BuiltWith report the CDN when its fingerprint is present, and dedicated CDN-finder tools do the same. DNS offers a corroborating hint: a CNAME pointing at a CDN-owned domain can reveal the provider — Akamai famously uses chained CNAMEs ending in Akamai domains (such as edgesuite.net / edgekey.net), Fastly customers often CNAME to a Fastly target, and CloudFront uses *.cloudfront.net distribution domains. Resolving the domain with dig www.example.com CNAME and reading the target is a useful cross-check, especially for Akamai whose CNAME chain is a giveaway even when headers are sparse.

A worked example

You want to know how a large retailer delivers its site. You run curl -sI https://www.example.com and read the response. There it is: Via: 1.1 varnish, an x-served-by naming a Fastly cache node, x-cache: HIT and x-cache-hits: 3. That is Fastly's signature — confirmed. You open the Network tab and reload to double-check: the document and most assets carry the same Fastly headers, and the cache status flips to MISS then HIT as you force-reload, proving Fastly is actively caching. Out of habit you also run dig www.example.com CNAME and see a Fastly target, corroborating through DNS. The read is clear: this site is delivered through Fastly. And you note the honest boundary — Fastly is the edge; the origin behind it (some cloud or server) is not revealed by these headers and is deliberately masked. A minute's work, a confident provider identification, and a clear-eyed note about what it does and does not tell you.

The origin-masking caveat that applies to all three

This is the single most important thing to keep straight: Akamai, Fastly and CloudFront are all reverse-proxy CDNs that sit in front of an origin. The headers you read come from the CDN edge, so detecting the CDN tells you who delivers the site to visitors — not where the origin is hosted. The origin could be on AWS, Google Cloud, Azure, a traditional host or on-premises hardware, and the CDN is specifically designed to keep it hidden (for performance, security and DDoS protection). So a clean "this site uses Fastly" is a statement about delivery, and any claim about the origin behind it needs separate evidence — and is often deliberately unanswerable from outside. This is exactly the edge-versus-origin distinction at the heart of how to find out where a website is hosted and what is a CDN and do you need one. Report the CDN with confidence; treat the masked origin with appropriate humility.

What the CDN choice tells you about a site

Which CDN a site picks is a quiet signal about its priorities and scale. Akamai is the long-standing enterprise choice — encountering it usually means a large, established organisation (big retail, banking, government, media) with serious traffic and security requirements. Fastly skews toward developer-led teams, media and ecommerce that value its real-time configurability and Varnish-based control; it often indicates an engineering-driven culture. CloudFront is the natural pick for sites already on AWS, so it frequently travels with an AWS-hosted stack and signals a cloud-native operation. The presence of any of the three tells you the site invests in performance, global delivery and resilience rather than serving straight from a single origin. For competitive research, sales qualification and architecture understanding, the CDN is an informative, easily read layer — best interpreted alongside the rest of the stack rather than in isolation.

How reliable is CDN detection?

Very reliable for identifying the CDN, because each provider's headers are distinctive and intrinsic to how the service runs — they are not routinely stripped the way a Server header is. The two honest limits are familiar. First, the origin stays hidden: detection names the edge delivery network, not where the site is actually hosted. Second, multi-CDN and layered setups exist — a site might use one CDN for HTML and another for assets, or chain providers — so check more than the document request and do not assume a single CDN handles everything. Within those bounds, "which CDN delivers this site?" is a question you can answer with confidence from one curl -I, while "where is the origin?" deliberately is not. Match the fingerprint, confirm in the Network tab, cross-check DNS for Akamai's CNAME chain, and report the CDN clearly while being honest that the origin is masked.

The workflow

1. Run curl -sI https://example.com and match the signature header (x-served-by, x-akamai-*, x-amz-cf-id).
2. Read the Via header — varnish (Fastly), CloudFront's cloudfront.net, or Akamai infrastructure.
3. Confirm in the Network tab and watch the cache status (HIT/MISS) flip.
4. Cross-check DNS with dig www.example.com CNAME — Akamai's CNAME chain is a giveaway.
5. Report the edge, not the origin — name the CDN confidently; note that the origin is masked.

Go deeper

• The Cloudflare-focused companion: how to tell if a website uses Cloudflare or another CDN.
• The header reference: how to read a website's HTTP response headers.
• CDN fundamentals: what is a CDN and do you need one.
• Where the origin lives: how to find out where a website is hosted.

Want the CDN, hosting and full delivery picture identified automatically? Analyse any site with StackOptic — one report, free, no sign-up.