How to Find Where a Website Is Hosted (And Why the Tools Get It Wrong)

To find where a website is hosted, resolve the domain to an IP address and look up who owns that IP. Two commands do it: dig +short example.com, then whois on the address that comes back. The organisation on the IP record is the host, unless a CDN is sitting in front of it, which is the case for a large slice of the web and the single reason most lookup tools return a confident wrong answer.

The one-click hosting checkers are not lying to you. They are answering a slightly different question than the one you asked. They tell you which network the request terminated on, and for an enormous number of sites that network is a proxy, not the machine running the code. Knowing the difference is the whole skill here, and it takes about five minutes to learn.

Table of contents

• The one-command version
• Why the answer came back as a CDN
• ASN lookup: the layer that does not lie
• What the HTTP response gives away
• Putting the layers together
• When this is actually worth doing
• How this fits the rest of the stack
• FAQ

The one-command version

Start at the bottom of the stack. Resolve the name, then ask who owns the address.

# A record for the domain
dig +short example.com

# Who owns that IP
whois 93.184.216.34 | grep -Ei 'orgname|org-name|netname|descr|country'

If the OrgName comes back as a company you recognise as a hosting provider, you have your answer and you can stop. If it comes back as a CDN or an edge network, you have found the front door, not the building.

The second half of the pair is the nameserver record, which is frequently more honest than the A record because plenty of teams proxy their traffic without moving their DNS.

dig +short NS example.com
dig +short MX example.com

Nameservers of the form ns1.somehost.com are a strong signal that the domain is managed by that host. MX records point at whoever handles mail, which is often a different vendor entirely and worth noting separately.

Why the answer came back as a CDN

When a site sits behind a reverse proxy, the public A record points at the proxy’s anycast range. The origin server, the machine that actually holds the application, never appears in public DNS at all. That is the point of the arrangement: it hides the origin so it cannot be attacked directly.

So a lookup that reports an edge network is telling you the truth about the request path and nothing at all about the host. Treat it as a partial answer.

There are a few ways to see past it, none of them guaranteed:

• Historical DNS. Passive DNS databases keep old A records, and the pre-proxy address is often still in there.
• Subdomains that were never proxied. Records like mail, ftp, cpanel, direct, or origin frequently point straight at the real machine because nobody thought to route them through the edge.
• Certificate transparency logs. Certificates issued for a domain sometimes reveal internal hostnames that resolve to the origin.
• SPF and TXT records. An SPF record listing an IP range is a hint about which network the organisation actually operates on.

If none of those work, the origin is properly hidden, and the correct answer to the question is that you cannot tell from outside. That is a legitimate finding, not a failed lookup.

ASN lookup: the layer that does not lie

An IP address belongs to an autonomous system, and the AS is registered to an organisation. This is the most reliable identification layer available from outside, because it is a routing fact rather than a self-declared one.

# Team Cymru whois interface, IP to ASN
whois -h whois.cymru.com " -v 93.184.216.34"

# Or with dig, using the origin lookup zone
dig +short 34.216.184.93.origin.asn.cymru.com TXT

The response gives the AS number, the allocation, the country and the registered organisation. A datacentre operator, a cloud provider and a residential ISP all look obviously different at this layer, and that alone answers most practical versions of the question.

One nuance worth keeping: large providers resell address space. An IP registered to a big cloud tells you the workload runs in that cloud, not which reseller or managed-hosting company put it there.

What the HTTP response gives away

Before you go digging through registries, ask the server. A single request often names the stack outright.

curl -sSI https://example.com | sed -n '1,20p'

Headers worth reading:

• Server. Sometimes a bare nginx or Apache, sometimes a product name that identifies the platform directly.
• X-Powered-By. Usually a language runtime, occasionally a whole PaaS.
• Platform-specific trace headers. Most managed platforms stamp a request ID with a recognisable prefix, and that prefix is effectively a signature.
• Set-Cookie. Session cookie names are often framework-specific and give away what is running.
• CF-Ray, X-Served-By, X-Cache. Edge network markers, which confirm a proxy is present.

This is the fastest method and the one with the highest false-negative rate, because any competent operator can strip or forge every header in that list. When the headers are silent, that silence is itself mildly informative.

Putting the layers together

No single lookup is authoritative. The reliable method is to run all four and see where they agree.

1. Resolve A, AAAA, NS, MX and TXT records. Note anything that names a company.
2. Run an ASN lookup on the A record. Write down the network operator.
3. Fetch the headers. Note any platform signature.
4. If the first three point at an edge network, check historical DNS and unproxied subdomains for an origin.
5. Compare. Three layers agreeing is a solid answer. Three layers disagreeing usually means a proxy, a multi-vendor setup, or both.

A worked example of disagreement: nameservers at a registrar, A record on an edge network, MX at a mail provider, and an origin subdomain sitting on a VPS in a third country. That is not a contradiction. That is a completely normal small-company setup, and describing it accurately means naming four vendors rather than one.

When this is actually worth doing

The lookup is a means to something. The usual reasons:

• You inherited a site. Nobody has the credentials, the previous developer is unreachable, and the invoice is the only remaining clue. DNS and WHOIS narrow the search to one or two vendors to call.
• You are planning a migration. Knowing whether the current setup is shared hosting, a VPS or a managed platform tells you how painful the move will be, and where the data actually lives.
• You are debugging someone else’s outage. If a partner API is down, knowing whose network it is on tells you whether to check a status page or send an email.
• You are doing due diligence. Infrastructure choices are a reasonable proxy for engineering maturity, and they are visible from outside without asking anyone.

What it is not good for is billing archaeology. The network the site runs on tells you nothing about the contract, the plan, or the monthly cost, and guesses in that direction are usually wrong by a factor of several.

How this fits the rest of the stack

Most of the time the reason for running this lookup is that someone is about to move a site, and the real question underneath is what the destination costs. That part is worth modelling before the migration starts rather than after, and the RunxBuild hosting calculator lays the line items out together: the service, the database, the storage and the bandwidth as separate numbers rather than one blended figure. Migrations go wrong less often when the target shape is decided in advance, and a static site with a custom domain and a certificate is a very different bill from an application server with a managed database beside it.

Useful related references:

• Where Your Content Is Inside an Exported WordPress Zip
• No Code Website Builders: Where the Ceiling Is and How to Tell You Hit It
• What Is a Static Website? Benefits, Examples, Hosting
• Services on RunxBuild

FAQ

Can I find where a website is hosted for free?

Yes. Every method in this post uses dig, whois and curl, all of which ship with or install freely on macOS and Linux, and are available on Windows through WSL or the Git for Windows shell. The paid tools mostly package historical DNS data, which is the one layer that is genuinely hard to get for free.

Why does every site I check come back as the same CDN?

Because a very large share of the web sits behind a handful of edge networks. That result means the request terminated at a proxy. The origin is deliberately hidden, and finding it requires historical DNS records or an unproxied subdomain.

Do nameservers always identify the host?

No, but they are a better signal than the A record. Many teams keep DNS at their registrar or a dedicated DNS provider while hosting elsewhere. Nameservers named after a hosting company are strong evidence. Generic ones are no evidence either way.

Is looking up a website host legal?

Every method here queries public records: DNS, the regional registries, and the site’s own HTTP response. These are the same lookups your browser performs to load the page. Scanning ports or probing for vulnerabilities is a different activity with different rules.

How do I find where a website is hosted if WHOIS is private?

Domain WHOIS privacy hides the registrant, not the IP registration. The ASN lookup on the resolved address still returns the network operator, because IP allocations are published by the regional registries and cannot be made private.