How to Find Out Where a Website Is Hosted (Hosting, CDN & Server)

Want to know where a website is actually hosted — the hosting provider, the CDN in front of it, and the server software it runs? Unlike a CMS, hosting lives at the infrastructure layer, so you read it from DNS, WHOIS and HTTP headers rather than the page's HTML. Here is the reliable way to trace it, and why the answer is sometimes "a CDN" rather than a single server.

If you are starting from scratch, first see how to find out what a website is built with for the full-stack overview; this guide zooms in on infrastructure.

Why identify a site's hosting — and the three layers involved

Knowing where a site is hosted helps with due diligence (enterprise cloud or a budget shared host?), security research (which provider to contact about abuse), competitive benchmarking (what infrastructure a rival trusts) and migration planning (what you would be moving away from). But "hosting" actually spans three layers people routinely conflate:

• The hosting provider (origin) runs the server where the site's code and database live — a cloud such as AWS, or a host such as Hetzner or DigitalOcean.
• The CDN / reverse proxy is the edge network in front of the origin, caching and serving content close to visitors — Cloudflare, Fastly, CloudFront.
• The DNS provider answers the domain's lookups and may be a fourth party entirely (Amazon Route 53, Cloudflare DNS).

A single site frequently uses three different companies for these roles, so good detection reports each layer separately instead of collapsing them into one "host" — the answer to "where is it hosted?" depends on which layer you mean.

Step 1: Resolve the domain to an IP address

Every website lives at an IP address. A DNS lookup of the domain's A record (IPv4) or AAAA record (IPv6) returns it:

$ dig +short example.com A
93.184.216.34

That IP is the doorway to the hosting answer.

Step 2: Run a WHOIS / IP-ownership lookup

Public IP addresses are allocated in blocks to organisations and recorded by the regional internet registries (ARIN, RIPE, APNIC and others). A WHOIS lookup on the IP — not the domain — returns the owning organisation and its autonomous system number (ASN):

$ whois 93.184.216.34 | grep -i orgname
OrgName: Example Hosting Inc.

The organisation name typically identifies the hosting provider or cloud directly: Amazon AWS, Google Cloud, Microsoft Azure, Hetzner, OVH, DigitalOcean and similar. Reverse DNS (the IP's PTR record) often confirms it with a hostname like ec2-…compute.amazonaws.com.

Two practical notes. The registries are migrating from plain WHOIS to RDAP (Registration Data Access Protocol), which returns the same ownership data as structured JSON; most lookup tools now use it transparently. And a domain can resolve to several IP addresses — round-robin DNS, load balancers or anycast — so check whether those IPs belong to one organisation or several, since that itself hints at the architecture.

Step 3: Read the nameservers and mail records

Two more DNS record types are durable infrastructure tells that survive front-end redesigns:

• NS (nameserver) records name the DNS provider — *.cloudflare.com, *.awsdns-…, ns.google and so on.
• MX records name the email platform — Google Workspace, Microsoft 365 or Zoho — and the accompanying SPF/DKIM/DMARC TXT records reveal the email-sending stack.

Step 4: Detect the CDN from HTTP headers

Most production sites sit behind a content delivery network. The CDN identifies itself in the main document's response headers (DevTools → Network → the document request):

Header signature	CDN / platform
cf-ray, server: cloudflare	Cloudflare
x-vercel-id, server: Vercel	Vercel
server: Netlify	Netlify
x-amz-cf-id, via: … cloudfront	Amazon CloudFront
x-served-by, via: … varnish	Fastly
x-akamai-…, server: AkamaiGHost	Akamai

This matters because of scale: according to W3Techs, Cloudflare is the most widely used CDN and reverse proxy on the web, and Amazon Web Services is the largest cloud infrastructure provider — so a large share of sites resolve to one of these two.

Two supporting headers sharpen the picture. The Server header sometimes still names the origin web server (nginx, Apache, LiteSpeed) when the CDN passes it through. And cache-status headers — cf-cache-status (Cloudflare), x-cache: Hit from cloudfront (CloudFront) or Fastly's x-cache — confirm not only which CDN is in front but whether that specific response was served from its edge cache.

Why the origin is sometimes hidden

Here is the key caveat. When a site uses a CDN or reverse proxy, every request terminates at the CDN's edge, and DNS points at the CDN rather than the origin. The origin server's real IP is deliberately concealed — that concealment is a security feature, protecting the origin from direct attacks.

So if you look up a Cloudflare-fronted site, the IP belongs to Cloudflare, not the underlying host. That is not a detection failure; it is the honest description of how the site is served. The practical rule: report the edge you can see, and treat the origin as unknown unless a non-proxied record (such as a mail subdomain) leaks it.

When you can still find the origin

A CDN hides the origin on purpose, but legitimate research sometimes recovers it from records the operator left public. Historical DNS data captured before the site moved behind a CDN may still list the origin IP. Subdomains that bypass the proxy — often mail, ftp, cpanel or direct — can resolve straight to the origin. And TLS certificate transparency logs sometimes expose related hostnames through a certificate's Subject Alternative Names. None of this defeats the CDN's protection; if every path is proxied, the honest conclusion is simply that the origin is intentionally private.

Command-line quick reference

You can do most of this from a terminal in a few seconds:

dig +short example.com A        # origin / edge IP(s)
dig +short example.com NS       # DNS provider
dig +short example.com MX       # mail platform
whois 93.184.216.34             # IP owner + ASN
curl -sI https://example.com    # response headers -> CDN / server

Each command targets one layer; run together, they reconstruct the full infrastructure picture.

Reading the TLS certificate

A site's HTTPS certificate is another public infrastructure clue. Click the padlock in your browser, or run openssl s_client -connect example.com:443 -servername example.com, and read two fields. The issuer hints at the platform: Cloudflare, Google Trust Services and Amazon all issue certificates for their own customers, whereas a Let's Encrypt certificate often points to a self-managed VPS or a budget host. The Subject Alternative Names (SANs) list every hostname the certificate covers, which frequently exposes sibling domains and subdomains sharing the same infrastructure — handy corroboration, and occasionally a lead on a non-proxied origin.

Geolocating the server — and why it can mislead

IP geolocation will happily return a city for any address, but treat the result with caution. Behind a CDN, the location you see belongs to the nearest edge node, not the origin datacentre — a visitor in London and one in Tokyo may hit entirely different Cloudflare locations for the same site. Even on a direct connection, geolocation reflects the registry record, which can lag a server's real move by months. And providers such as AWS span dozens of regions, so "United States" tells you little about which datacentre actually serves the page. Use geolocation as a rough hint about a provider's region, then corroborate it with the IP owner from WHOIS and any non-proxied subdomain before you trust it.

How accurate is hosting detection?

The CDN and DNS provider are almost always identifiable, because they advertise themselves in response headers and NS records. The origin host is only as visible as the site allows: a directly connected site reveals it immediately, while a fully proxied site keeps it private by design. Reading "Cloudflare" for a Cloudflare-fronted site is therefore the correct answer, not a miss. As ever, corroborate with a second signal — pair the IP owner with the response headers — before drawing a firm conclusion.

The reliable workflow

1. Resolve the domain's A/AAAA record to an IP.
2. WHOIS the IP for the owning organisation and ASN.
3. Check NS and MX records for the DNS and email providers.
4. Read response headers to identify the CDN at the edge.
5. Separate the layers — report origin host and CDN distinctly, and flag the origin as hidden when a CDN is in front.

A platform that does this end to end saves the manual lookups and reconciles the layers for you. As the StackOptic Research Team puts it, "Hosting detection is detective work: the IP, the headers and the DNS records each tell part of the story, and a CDN's job is to make sure one of them stays blank."

Go deeper

• Confirm the software layer too: how to tell if a website is built with WordPress.
• See the complete picture: how to find out what a website is built with.

Skip the lookups — analyse any website with StackOptic to see its hosting provider, CDN, DNS and full stack in one report, free.