Fastly

What Is Fastly?

Fastly is a high-performance edge cloud platform and content delivery network (CDN) built on a heavily customized version of the Varnish HTTP cache, designed to give engineering teams fine-grained, programmable control over how content is cached and delivered at the edge. The short answer to what Fastly is: it is a developer-oriented, performance-focused CDN known for instant cache purging and its Varnish Configuration Language (VCL), and when a site uses it, content is served from Fastly's edge while the website's true origin server sits hidden behind it.

Fastly was founded in 2011 and went on to power some of the most demanding properties on the web, including major media, commerce, and developer platforms. According to technology surveys such as W3Techs and BuiltWith, Fastly is consistently reported as one of the leading CDNs, smaller in raw site count than Cloudflare but with a strong presence among high-traffic, performance-sensitive sites. Exact market-share figures vary by source and over time, so treat any single percentage with caution; the dependable finding is that Fastly is a top-tier CDN especially favored by engineering teams that want deep control over caching behavior.

The essential concept for analysis is the same as for every CDN: the difference between the edge and the origin. When Fastly fronts a site, its edge nodes (built on Varnish) receive and serve requests, and Fastly masks the origin behind them. The origin could be running on AWS, Google Cloud, a dedicated server, or anywhere else, and Fastly's response headers reveal the edge layer, not the host. Recognizing that you are seeing Fastly's Varnish-based edge rather than the underlying server is the key to interpreting what its headers tell you.

How Fastly Works

Fastly is a reverse-proxy CDN whose edge nodes run a modified, hardened build of Varnish, the well-known HTTP accelerator. Each customer configures one or more services, each mapping a domain and a set of caching rules to one or more backends (origins). The defining characteristic is that this configuration is expressed largely in VCL, Varnish Configuration Language, which lets teams script exactly how requests are routed, cached, transformed, and served at the edge.

When a request arrives at a Fastly edge node, Varnish checks its cache. On a hit, the cached object is returned immediately and the origin is not contacted, which Fastly records in an X-Cache: HIT header (and tracks how many times it has been served via X-Cache-Hits). On a miss, Fastly fetches the object from the configured backend, applies any VCL transformations, returns it to the visitor, and stores it at the edge for subsequent requests, recording X-Cache: MISS. Because the edge is Varnish, the response also passes through a Via header that references varnish, and Fastly stamps an X-Served-By header naming the specific cache node (or chain of nodes) that handled the request.

Two capabilities define Fastly's reputation. The first is instant purging: Fastly can invalidate cached content across its entire network in roughly 150 milliseconds, which makes it practical to cache even frequently changing content such as news headlines or inventory, then purge the instant it updates. The second is programmability: through VCL and, more recently, a WebAssembly-based compute platform, teams can run sophisticated logic at the edge, from request routing and header manipulation to full applications. Fastly also provides real-time logging and analytics, image optimization, TLS, and DDoS and WAF protection layered on top of the cache.

This combination, a Varnish-based edge with instant purge and deep scriptability, is why Fastly is the CDN of choice for teams that treat the edge as programmable infrastructure rather than a set-and-forget cache.

How to Tell if a Website Uses Fastly

Fastly leaves recognizable header fingerprints, anchored by its Varnish heritage, that make it identifiable with a quick look at the response.

Signals in response headers

• X-Served-By. Names the Fastly cache node(s) that handled the request, often a chain like cache-lhr1234-LHR, cache-iad1234-IAD. This is a strong primary signal.
• X-Cache. Reports HIT or MISS (and combinations along a node chain), indicating whether the edge served a cached copy.
• X-Cache-Hits. A count of how many times the object has been served from that cache node, a header pattern characteristic of Fastly's Varnish setup.
• Via: ... varnish. Because Fastly's edge is Varnish-based, the Via header references varnish, frequently alongside a version string.
• Fastly-* headers. Various Fastly-specific headers may appear, and debugging headers such as Fastly-Debug can surface additional detail when enabled.

Signals in asset domains and DNS

• *.fastly.net / *.fastlylb.net domains. Look in the page source and Network tab, or run dig/nslookup on the site or its asset subdomains; Fastly-fronted hosts frequently resolve through *.fastly.net or *.fastlylb.net (Fastly's load-balancer domain) via CNAME.

Tools to confirm it

Tool	What you do	What it reveals
curl -I https://example.com	Fetch response headers only	X-Served-By, X-Cache, X-Cache-Hits, Via: ... varnish
DevTools Network tab	Reload, click the document, inspect Headers	The same Fastly/Varnish headers in context
dig example.com / nslookup	Resolve the domain or asset subdomain	A CNAME or address chain through *.fastly.net / *.fastlylb.net
View Source	Scan asset URLs	Resources served from *.fastly.net domains
Wappalyzer	Run the browser extension	Flags Fastly in the CDN category

Keep the origin-versus-edge distinction in mind throughout. The X-Served-By and Varnish Via headers prove Fastly is delivering the content, but they say nothing about the real origin hidden behind the edge. Because the X-Cache and Via: varnish pattern can superficially resemble a self-hosted Varnish cache, the combination with X-Served-By and Fastly domains is what confirms it is Fastly specifically. For a side-by-side method of distinguishing the major CDNs, see how to tell if a website uses Akamai, Fastly, or CloudFront; for the rationale behind adopting a CDN at all, read what a CDN is and whether you need one; and for a deeper dive into the headers themselves, see how to read a website's HTTP headers.

Key Features

Fastly's feature set is oriented around performance and programmable control.

• Varnish-based edge cache. A high-performance HTTP cache at every point of presence, the foundation of the platform.
• VCL configuration. Varnish Configuration Language gives engineers granular, scriptable control over caching and routing.
• Instant purging. Network-wide cache invalidation in roughly 150 milliseconds, enabling caching of dynamic content.
• Edge compute. A WebAssembly-based compute platform for running custom logic and applications at the edge.
• Real-time logging and analytics. Streaming logs and live metrics for immediate visibility into edge behavior.
• Image optimization. On-the-fly resizing and format conversion at the edge.
• Security. Integrated TLS, DDoS mitigation, and a web application firewall.
• Origin shielding. Designating a shield POP to reduce origin load and improve cache efficiency.

A few features stand out for anyone analyzing a site. Instant purge is why Fastly often fronts news and commerce sites that cache aggressively yet update constantly. VCL means the edge behavior is genuinely custom per customer, so two Fastly sites can behave quite differently. And origin shielding adds another layer between the edge and the origin, which is one more reason the origin stays well hidden from outside observers.

Pros and Cons

Fastly's trade-offs follow from its engineering-first, programmable design.

Pros

• Excellent raw performance built on a tuned Varnish edge.
• Near-instant cache purging that makes caching dynamic content practical.
• Deep programmability through VCL and edge compute.
• Strong real-time logging and observability.
• Trusted by large, demanding media and commerce properties.

Cons

• A steeper learning curve; VCL and fine-grained control assume engineering expertise.
• Less of a turnkey, all-in-one bundle than some competitors.
• No broad always-free tier comparable to Cloudflare's.
• Smaller edge footprint than the very largest networks in some regions.
• For observers, it masks the origin and can be confused at a glance with self-hosted Varnish.

Fastly vs Alternatives

Fastly competes with other major CDNs, distinguished by its programmability and instant purge rather than by bundling or sheer scale.

Provider	Primary strength	Configuration model	Tell-tale headers
Fastly	Programmable, high-performance edge	VCL + edge compute	X-Served-By, X-Cache, Via: ... varnish
Cloudflare	All-in-one CDN, DNS, security	Dashboard + Workers	Server: cloudflare, CF-RAY
Amazon CloudFront	AWS-native CDN	AWS console + Lambda@Edge	Via: ... cloudfront.net, X-Amz-Cf-Id
Akamai	Enterprise scale and reach	Property Manager	AkamaiGHost, X-Akamai-*

The most instructive comparison is Fastly versus Cloudflare. Both are modern edge networks, but they serve different instincts. Fastly appeals to engineering teams that want to treat the edge as programmable infrastructure, writing VCL to control caching precisely and relying on instant purge to cache content others would consider too dynamic. Cloudflare leads with a bundled, turnkey package, an enormous free tier, and integrated DNS and security, which makes it the default for the long tail of the web. In header terms they are easy to tell apart: Fastly reveals itself through X-Served-By and a Varnish Via header, while Cloudflare announces itself with Server: cloudflare and CF-RAY. Against CloudFront and Akamai, Fastly trades ecosystem lock-in (AWS) and enterprise sales motion respectively for openness and edge programmability.

Use Cases

Fastly fits scenarios where performance and control at the edge are paramount.

• High-traffic media and news. Caching content aggressively while purging instantly the moment it changes.
• E-commerce. Serving product and inventory pages fast while keeping them fresh through rapid purges.
• API acceleration. Caching and shaping API responses at the edge with VCL logic.
• Edge applications. Running custom logic and full applications on Fastly's compute platform.
• Origin protection. Shielding and concealing the real origin behind the Fastly edge.

For competitive research and lead generation, spotting Fastly on a prospect's site signals a performance-conscious engineering culture, which is itself useful intelligence. But because Fastly masks the origin (and may add origin shielding on top), confirming the CDN is only the first step; identifying the real host behind the Varnish edge is the kind of origin analysis StackOptic specializes in.

Frequently Asked Questions

How is Fastly different from a self-hosted Varnish cache?

Fastly is built on a customized Varnish, so a self-hosted Varnish instance and Fastly both produce Via: ... varnish and X-Cache headers, which can look similar at a glance. The distinguishing signal is Fastly's X-Served-By header, which names Fastly cache nodes (often with airport-style location codes), along with Fastly-specific headers and resolution through *.fastly.net or *.fastlylb.net domains. The presence of those Fastly-specific artifacts is what confirms it is the Fastly platform rather than someone running their own Varnish.

What does X-Cache: HIT mean on a Fastly site?

It means the Fastly edge node served the response from its cache without contacting the origin, the fast path. X-Cache: MISS means the object was not cached, so Fastly fetched it from the backend and likely stored it for next time. On requests that pass through multiple nodes you may see a combination such as MISS, HIT. The companion X-Cache-Hits header counts how many times that node has served the object, which is a pattern characteristic of Fastly's Varnish-based edge.

Does Fastly reveal where a website is actually hosted?

No. Like any CDN, Fastly is a reverse proxy that sits in front of the origin and masks it. The headers confirm Fastly is delivering the content, but the real host, which could be on any cloud or dedicated server, stays hidden behind the edge, sometimes with an additional origin-shield layer in between. Determining the true origin requires indirect techniques such as historical DNS, certificate analysis, and subdomain inspection.

Why do some sites choose Fastly over Cloudflare?

Teams often choose Fastly when they want fine-grained, programmable control over caching and near-instant purging, treating the edge as scriptable infrastructure through VCL. That control is especially valuable for media and commerce sites that cache aggressively but must update content the moment it changes. Cloudflare, by contrast, is frequently chosen for its bundled DNS and security, generous free tier, and turnkey simplicity. The two reflect different priorities: programmability and performance versus all-in-one convenience.

How can I check for Fastly from the command line?

Run curl -I https://example.com and look for an X-Served-By header naming Fastly cache nodes, an X-Cache header showing HIT or MISS, an X-Cache-Hits counter, and a Via header referencing varnish. As a secondary check, run dig example.com (or on an asset subdomain) and look for resolution through *.fastly.net or *.fastlylb.net. Together these confirm Fastly is fronting the site.

Want to see past the Varnish edge and identify the real origin, hosting provider, and full technology stack behind any website? Try StackOptic at https://stackoptic.com.