Why does it just say "Cloudflare" without my real host?

Because Cloudflare proxies your origin in full-proxy mode. The CDN is what visitors hit; the origin is hidden by design. If you control the site, you already know where the origin is.

How accurate is the data-centre location?

Within ~50 miles for major providers (AWS, GCP, Azure). Less accurate for residential ISPs and small hosts. Treat it as "country + region" rather than "exact city".

Can it identify Kubernetes / Docker hosting?

Indirectly. A site on EKS will look like AWS; a site on GKE will look like GCP; a self-hosted k8s cluster will look like whatever cloud the underlying VMs run on. We don't fingerprint orchestration layers.

Does it detect serverless platforms (Lambda, Cloud Functions)?

Partially. Vercel, Netlify, and Cloudflare Workers are detected by their distinctive headers. Raw AWS Lambda behind API Gateway is harder unless distinctive headers are present.

Will it work on intranet / firewalled sites?

No — we need a public IP and reachable HTTP endpoint. Internal-only sites are invisible to this tool by design.

Free Tool

Updated 6 June 2026

Hosting Detector

Find out which hosting provider, CDN, and web server power any website. Identifies AWS, Cloudflare, Vercel, Netlify, Shopify, WP Engine, and 50+ other providers.

By Deepak Shukla — Founder & CEO, Pearl Lemon

Enter a domain

What This Tool Checks

Hosting provider (AWS, GCP, Azure, Cloudflare, Vercel, Netlify, WP Engine, etc.)
CDN in use (Cloudflare, Fastly, Akamai, CloudFront, BunnyCDN, etc.)
Web server software (Nginx, Apache, LiteSpeed, Caddy, Cloudflare's edge, etc.)
Server geolocation (country + region of the data centre)
Reverse DNS / PTR record clues

Why This Matters

Hosting tells you almost everything else about a site. WP Engine = WordPress. Shopify-hosted = Shopify store. Vercel = likely a JAMstack/Next.js app. Knowing the stack drives every conversation: agency pitching migration, security researcher mapping infrastructure, SEO consultant explaining why a site is slow (cheap shared hosting vs dedicated CDN). It's also the fastest way to spot single points of failure — a 500-site portfolio all on the same shared host is a disaster waiting to happen.

How to Fix Issues

1.If your site is on slow shared hosting, evaluate WP Engine, Kinsta, or Pressable for WordPress; Vercel/Netlify for static; Render/Fly.io for full-stack
2.Always front your origin with a CDN (Cloudflare free tier handles 99% of sites)
3.Remove the `Server:` and `X-Powered-By:` headers if you don't want to leak software versions (it doesn't hide hosting, but reduces information for attackers)
4.If you're consolidating an agency portfolio, audit hosting across every client site to spot cost-saving consolidation opportunities
5.For high-stakes sites, run a multi-CDN setup (primary + failover) to survive a single CDN outage

Every website lives somewhere. Knowing exactly where — which hosting provider, which CDN, which data centre — is the foundation of every infrastructure decision, every security audit, and every "why is this site so slow?" conversation.

Why hosting identification matters in 2026

The hosting market has bifurcated. On one side: traditional shared hosts (Bluehost, GoDaddy, Hostinger) serving the long tail of small business sites for $3/month. On the other: specialised platforms (Vercel, Netlify, WP Engine, Shopify) that bundle hosting + CDN + DevOps for $20-$500/month. The middle has collapsed.

Which side a site sits on tells you almost everything about its team, its budget, its likely performance, and its likely security posture. A site on cheap shared hosting in 2026 is almost certainly: slow, unmonitored, and one plugin-vuln away from being defaced. A site on WP Engine or Vercel is almost certainly: monitored, backed-up, behind a CDN, with someone watching the logs.

What we detect, and how

We combine three signals:

HTTP response headers — Server, X-Powered-By, Via, CF-Ray, X-Vercel-Id, X-Served-By, X-Cache, X-Amz-Cf-Id, etc. These are the cleanest tells: Cloudflare always sends CF-Ray, Vercel always sends X-Vercel-Id, Netlify always sends X-Nf-Request-Id. The header set is a fingerprint.
DNS A-record + reverse PTR — once we have the IP, we reverse-resolve. ec2-*.amazonaws.com = AWS EC2. *.cloudfront.net = AWS CloudFront CDN. *.googleusercontent.com = GCP. *.wpengine.com = WP Engine. PTR records are surprisingly accurate.
IP-range matching — for hosts that don't set distinctive headers and don't have helpful PTRs, we fall back to ASN/IP-range lookup. Known Cloudflare ranges, AWS ranges, GCP ranges, etc.

CDN vs origin host — they're different

A site fronted by Cloudflare will look like it's "hosted on Cloudflare" from the outside, but Cloudflare is the CDN — the origin server is somewhere else. We try to surface both: the CDN you hit and the origin behind it. Sometimes the origin is hidden (Cloudflare in full-proxy mode) and we can only see the CDN. That's a *feature* of Cloudflare, not a tool bug.

Server location and latency implications

We resolve the server's data-centre location via IP geolocation. A US-hosted site serving European users without a CDN will load slowly for them — period. The fix is almost always "add Cloudflare" before "migrate hosting."

What this won't tell you

Database hosting (Supabase, PlanetScale, Neon), email hosting (Mailgun, Postmark), search hosting (Algolia, Meilisearch), media hosting (Cloudinary, Bunny). Those are separate signals from separate endpoints — we focus on the page-serving layer here.

Methodology

Given a domain, we first issue a HEAD request to the homepage (10-second timeout) and inspect all response headers. We pattern-match against a registry of ~50 hosting providers and CDNs: Cloudflare (CF-Ray), Vercel (X-Vercel-Id, Server: Vercel), Netlify (Server: Netlify, X-Nf-Request-Id), AWS CloudFront (X-Amz-Cf-Id), Fastly (X-Served-By, X-Cache: HIT), Akamai (X-Akamai-Transformed, Server: AkamaiGHost), WP Engine (Server: WP Engine), Shopify (X-Shopify-Stage, Server: cloudflare + Shopify-specific cookies), Squarespace, Wix, Webflow, Ghost, and many others. In parallel, we resolve the domain to an IPv4 address and perform a reverse DNS lookup; the resulting PTR record is matched against another registry of provider patterns. The two signals are combined: header-based wins when present (more reliable), PTR is used as fallback or to identify the origin behind a CDN. We also extract the data-centre country via IP geolocation. All operations have hard timeouts to keep response time under 12 seconds even on slow targets.

Frequently Asked Questions

Monitor this continuously with LemWatch

A one-off free hosting detector & web server identifier shows you today. LemWatch re-runs the same checks around the clock and alerts you the moment something breaks — free for up to 10 sites, no card needed.