Who Hosts This Website? A Practical Hosting Detection Guide

"Who hosts this website?" looks like a question with one clean answer. In practice it is several questions wearing one coat. The company that owns the server, the company that answers DNS, the registrar that sold the domain, and the CDN that sits in front of everything can all be different — and a naive lookup will happily report the wrong one with full confidence. This guide is about building an accurate mental model: what a hosting provider actually is, which manual checks you can run yourself, why reverse proxies like Cloudflare hide the truth, and how to read an automated website hosting checker without being fooled by it.

What a "hosting provider" actually means

The hosting provider is whoever runs the physical (or virtual) server that stores and serves the site's files and application. That is the thing you usually want when you ask "who is hosting a site" — for due diligence, competitive research, abuse reports, or migration planning.

It is easy to confuse this with three neighbours:

1. DNS provider — answers the domain's nameserver queries and decides which IP a name resolves to. A site can host its files at one company and run DNS at another (Cloudflare, Route 53, NS1). The DNS provider is not the host.
2. Registrar — sold and manages the domain name itself. A registrar may also offer hosting, but the two are independent contracts. Registrar data now lives behind IANA's RDAP bootstrap, which points you to the authoritative registry/registrar service for a given TLD — useful for ownership, useless for "where do the files live".
3. CDN / reverse proxy — caches and proxies the site from edge locations worldwide. When a CDN is in front, the IP you see belongs to the CDN, not the origin host.

So "find the hosting provider" really means: find the network that runs the origin server, and separate it from DNS, registrar, and CDN. The rest of this guide is methods for doing exactly that — and knowing when you cannot.

Manual methods: what you can check yourself

You can get surprisingly far with standard tools. Here is the order I run them, and what each one tells you.

DNS A / AAAA records

dig example.com A (and AAAA for IPv6) returns the IP addresses the domain currently points to. This is the starting point: the IP is the thread you pull on. But an A record only tells you what the domain resolves to right now — if that IP belongs to a CDN, you have learned the CDN, not the host.

NS records

dig example.com NS lists the authoritative nameservers. This identifies the DNS provider, which people routinely mistake for the host. ns1.digitalocean.com tells you DigitalOcean answers DNS; it does not prove the files are on DigitalOcean. Treat NS records as a DNS-provider signal only.

Reverse DNS (PTR)

dig -x <ip> looks up the PTR record for an IP. Reverse DNS is frequently set by the hosting network and can leak a hostname like srv12.somehost.net. It is a hint, not proof — PTR records are configured by whoever controls the IP block and may be generic, stale, or absent.

IP ASN / WHOIS on the IP

This is the most reliable single signal. Every routable IP belongs to an Autonomous System (AS) owned by an organisation. Looking up the ASN for the resolved IP tells you which network operator announces that address — e.g. AS14061 (DigitalOcean), AS16509 (Amazon), AS13335 (Cloudflare). For a site on its own infrastructure, the ASN org is the hosting provider. For a site behind a CDN, the ASN org is the CDN. Either way, the ASN is ground truth about whose network you reached; the interpretation is the hard part.

HTTP response headers

Headers often advertise the stack and sometimes the host or CDN. The MDN HTTP headers reference documents the standard set; the telling ones for detection are usually non-standard:

1. Server: — may say cloudflare, AmazonS3, nginx, or be stripped.
2. Via:, X-Cache:, Age: — typical of a caching proxy/CDN in the path.
3. X-Served-By, X-Powered-By, CF-RAY, X-Amz-Cf-Id — vendor fingerprints (Fastly, generic stacks, Cloudflare, CloudFront respectively).

Headers are self-reported and easily spoofed or removed, so they corroborate other signals rather than stand alone.

CDN CNAMEs

When a domain's record is a CNAME pointing at something like d111111abcdef8.cloudfront.net, example.fastly.net, or example.akamaized.net, that is a CDN, not a host. CNAME chains are one of the cleaner CDN tells — see CDN detection across Cloudflare, CloudFront, Fastly and Akamai for the per-vendor fingerprints. The catch: if a CDN sits in front, the CNAME and IP describe the edge, and the origin behind it stays hidden.

Why Cloudflare and other reverse proxies hide the origin

This is the single biggest reason hosting lookups go wrong. A reverse proxy like Cloudflare terminates the connection at its own edge servers and fetches from the origin privately. From the outside you see Cloudflare's IPs, Cloudflare's ASN (AS13335), and Cloudflare headers — the origin's real host is, by design, not exposed in DNS or HTTP.

This matters because reverse proxying is now the norm, not the exception. The HTTP Archive Web Almanac 2025 CDN chapter documents how large a share of the web is served through CDNs, with Cloudflare a dominant share of that traffic. So for a big slice of sites, the honest answer to "who hosts this" is two-layered: "served via Cloudflare; the origin host is not externally visible." Any tool that flattens that into a single name is overstating what the network actually reveals.

Origins do leak — via stale DNS history, an unproxied subdomain (direct.example.com, mail.example.com), SSL certificate metadata, or misconfigured records that bypass the proxy. But those are heuristics with real error rates, not guarantees.

What hostingchecker.org detects, and how to read confidence

Our checker automates the chain above: it resolves A/AAAA, walks CNAMEs, maps the resolved IP to its ASN and organisation, inspects HTTP headers, and matches known CDN and host fingerprints. It then reports a provider with a confidence level rather than a bare name — because the underlying signals genuinely differ in strength.

Read confidence like this:

1. High — multiple independent signals agree and there is no proxy in the path: the ASN org, reverse DNS, and headers all point at the same provider. This is usually a site on its own or a single host's infrastructure.
2. Medium — signals are consistent but partly self-reported (e.g. headers plus ASN, no PTR), or the provider is a large cloud where the ASN org is correct but coarse (you reached Amazon AS16509, which could be EC2, S3, a customer VPC, or a SaaS built on AWS).
3. Low / "CDN detected" — a reverse proxy is in the path. We name the CDN (which we can see) and state plainly that the origin host is not externally determinable from public signals. We would rather say "we don't know the origin" than invent one.

The tool is a fast, repeatable version of the manual checks — not an oracle. When it reports low confidence, that is information, not a failure: it usually means there is genuinely a proxy hiding the origin.

Common false positives

Being honest about where detection breaks is the whole point of a credible checker. The recurring traps:

1. CDN reported as host. The most common one. Cloudflare/CloudFront/Fastly/Akamai is the network you reached; it is not where the site is actually hosted.
2. DNS provider reported as host. NS records say who answers DNS, not who serves files. Cloudflare DNS without Cloudflare proxying is a frequent mix-up.
3. Registrar reported as host. RDAP/WHOIS data describes domain ownership, not server location.
4. Shared / hyperscale IPs. On AWS, Google Cloud, or large shared hosts, one IP or ASN can sit under thousands of unrelated sites; the org is right but tells you little about this site specifically.
5. SaaS and managed platforms. A site on Shopify, Webflow, Vercel, or WordPress.com resolves to that platform's infrastructure — which is the accurate answer, but easy to misread as "self-hosted on AWS" when the platform runs on a hyperscaler.
6. Stale data. DNS and headers change; a cached or historical lookup can name a provider the site already left. According to W3Techs' web hosting rankings, provider market share shifts continuously as sites migrate — yesterday's answer is not guaranteed to be today's.

A checklist for agencies

For agencies doing audits, migrations, or competitive research, a repeatable procedure beats one-off guessing:

1. Resolve and record A/AAAA, CNAME chain, and NS records — and label each one (host candidate / CDN / DNS provider).
2. ASN-map the resolved IP. If the org is a CDN (Cloudflare, CloudFront, Fastly, Akamai), stop and mark the origin as proxied / unknown rather than guessing.
3. Check headers for Server, Via, X-Cache, and vendor fingerprints to confirm whether a proxy is in the path.
4. Probe likely-unproxied subdomains (mail., cpanel., direct.) for an origin leak — note it as a heuristic, not proof.
5. Separate the four roles explicitly in your report: host, DNS provider, registrar, CDN. Clients conflate them constantly.
6. Record confidence and date with every finding, because results decay.

Run this with a tool to go fast, but keep the manual fallbacks for the cases where confidence is low — those are exactly the cases that matter most.

Summary

"Who hosts this website" is really four questions: the host, the DNS provider, the registrar, and the CDN. You can answer most of it yourself with DNS records, reverse DNS, IP-to-ASN mapping, HTTP headers, and CNAME inspection — and the ASN of the resolved IP is your most reliable single signal. The hard limit is the reverse proxy: when Cloudflare or another CDN fronts a site, the origin host is genuinely not visible from public data, and any honest checker — including ours — should say so rather than guess. Treat confidence levels as the real answer, not the provider name on its own.

As more of the web moves behind proxies and SaaS platforms, the gap between "the network you reached" and "where the site actually lives" only widens. The useful skill is no longer naming a single provider — it is reading the layers correctly and knowing which question you have actually answered.

Run the resolved IP, ASN, headers, and CNAME chain through a checker, read the confidence level honestly, and fall back to manual checks whenever a proxy is in the path.