Identify the public delivery network behind a domain
Combine observed IP, ASN, CNAME, and response-header evidence to see which network or supported edge platform visitors reach.
Hosting Checker
Free, no signup. See which public network and edge platform a domain exposes — and the specific DNS or response-header evidence for it.
Checks run from our server; we fetch the URL you enter and don't keep the results. This queries public DNS and makes one public web request. A CDN or reverse proxy can hide the origin provider; this tool never treats edge evidence as proof of the origin. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Illustrative example — fixed public signals, not a domain lookup
Cloudflare is proxying this site; the origin host is not visible from this public check.
- Evidence:
server: cloudflareandcf-raywere present. - IP & network: the displayed addresses belong to the public edge network.
- DNS & mail: an MX answer is listed separately and is not called the web host.
- Transfer:
Content-Encoding: brmeans Brotli was observed on this response.
How to use it
- Enter a bare domain such as
example.com. - Choose Check hosting and read the delivery verdict with its evidence.
- Separate the observed IP network, CNAME, and response-header fingerprints from the mail-host MX records.
- If a proxy is detected, treat the origin as unknown unless you can verify it through your own account or configuration.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
IP & network
DNS & mail
Transfer
Rate this tool
How to read the result
- Delivery verdict summarizes the strongest supported edge or ASN evidence.
- Origin not visible means a proxy or edge platform terminates the public request.
- IP network is the ASN organization for the observed A/AAAA address, not necessarily the hosting brand.
- CNAME and MX are raw public DNS answers; MX describes email.
Data sources & freshness
The endpoint performs bounded public A/AAAA, CNAME, and MX lookups and one web request. Team Cymru ASN DNS data enriches observed IPs with network organization, registry, and country. A deterministic fingerprint table checks selected headers and CNAMEs for supported edge platforms, while transfer inspection reports compression and only documented protocol hints.
Features
- Public IP, ASN, CNAME, and MX evidence in one report.
- Supported CDN and edge fingerprints from DNS and headers.
- Compression and protocol-hint summary.
- Explicit distinction between delivery network, origin host, and mail host.
Limitations
A Cloudflare, Fastly, or similar result describes the public edge and may conceal the origin. ASN country is not a physical server location. Private DNS, multi-CDN routing, geographic answers, reseller relationships, and infrastructure without a supported fingerprint can make the picture incomplete.
Frequently asked questions
Can a hosting checker identify the origin host behind Cloudflare?
Usually not. A reverse proxy publishes its own edge IPs and headers while deliberately hiding the origin. The checker reports Cloudflare as the delivery layer and leaves the origin unclaimed.
Is the reported country the server location?
No. Country and registry values come from public ASN data for the observed IP network. They are not proof of the physical datacenter, origin server, or where site data is stored.
Why does the tool show a CDN instead of my web host?
Public DNS and HTTP requests terminate at the CDN or edge proxyA CDN (content delivery network) is a geographically distributed network of edge servers that caches and serves your content from a location close to each visitor and crawler. It isn't a ranking factor itself, but it affects things Google and Bing do use — page speed and Core Web Vitals, crawl efficiency, uptime, and HTTPS delivery — and, if misconfigured, can block crawlers or muddle canonicalization. when one is configured. That is the infrastructure visible to visitors; the underlying host may not expose a public fingerprint.
Does the MX record show who hosts the website?
No. MX records describe mail delivery. The report lists them separately because email and web hosting are often provided by different companies.
Feature requests for Hosting Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Recognize when a CDN hides the origin host
Treat Cloudflare, Fastly, Vercel, and similar edge evidence as the public delivery layer without claiming that it reveals the underlying server.
Separate web hosting from email delivery
Review MX answers independently so the company handling mail is not mistakenly reported as the website host.
Document network and transfer evidence for troubleshooting
Record public addresses, ASN organization, registry country, compression, and supported protocol hints as a bounded technical snapshot.
Know when to verify the origin elsewhere
Use hosting-account, DNS-zone, or infrastructure configuration when the public report says the origin is unknown or the evidence is incomplete.
Watch the full workflow
Hosting Checker walkthrough
Read the transcript
Hosting Checker
This beginner walkthrough uses a repeatable fictional domain to explain what Hosting Checker can and cannot identify. We will inspect public network addresses, an edge-platform fingerprint, D-N-S and mail evidence, compression and protocol hints, result interpretation, limitations, and the right next step when a proxy hides the origin server.
Step 1
Hosting Checker reports the infrastructure a visitor can observe from one public check. It combines D-N-S answers, public I-P network ownership, supported C-D-N or edge fingerprints, and selected response-header facts. That can identify a delivery layer. It cannot automatically reveal a private origin server hidden behind a reverse proxy.
Step 2
Use the tool to identify a public delivery network, recognize when a C-D-N hides the origin, keep mail hosting separate from web hosting, document network and transfer evidence for troubleshooting, or decide when the real answer must come from an account or configuration you control. Each use case stays within observable public evidence.
Step 3
Enter a bare domain such as example dot com, then choose Check hosting. The privacy note is also the scope statement: the tool queries public D-N-S and makes one public web request. A C-D-N or reverse proxy may hide the origin, and the tool never turns edge evidence into proof of that hidden host.
Step 4
The sample report demonstrates the most important interpretation. Cloudflare response headers identify a proxying layer, so the origin remains unknown. The public addresses belong to the visible edge network. The M-X answer is listed separately because it describes email delivery. Content-Encoding B-R means Brotli compression was observed on that response.
Step 5
For the full workflow, enter atlas dot example dot test. Dot-test and every displayed address are reserved for documentation, so this cannot expose a customer site. The capture fulfills the hosting endpoint locally with fixed evidence and blocks every external response.
Step 6
Choose Check hosting. The button changes while the bounded request is pending, then the result opens beneath the workflow. This successful run means the deterministic public-signal fixture was processed. It does not prove account ownership, a physical server location, or the identity of an origin hidden behind the visible edge.
Step 7
The delivery verdict says Cloudflare is proxying the site and that the origin is not visible from this public check. The next sentence repeats the boundary: the edge provider may hide the origin, so no origin-host claim is made. This is the main conclusion, not a missing-data error.
Step 8
The evidence list shows why the detector reached that conclusion. The Server header contains Cloudflare, and the C-F-Ray header is present. These are selected response fingerprints from the public request. They support the edge-platform verdict, but they still do not disclose the private machine behind it.
Step 9
I-P and network lists one reserved I-P-v-four address and one reserved I-P-v-six address. Both map to the fictional Example Edge Network and A-S-six-four-five-zero-zero in the United States. An A-S-N identifies the organization announcing the observed network. Its country value is registry data, not proof of a physical datacenter or data-storage location.
Step 10
D-N-S and mail shows the fictional C-NAME and M-X answers returned by the fixture. A C-NAME can help identify the public delivery path. An M-X record routes email. Even when the same company provides both services, an M-X answer alone does not identify the web host.
Step 11
Transfer reports Compression B-R, meaning Brotli was observed in Content-Encoding. The response also advertises H-T-T-P three through Alt-Svc. Advertisement is only a protocol hint: the Worker cannot confirm which H-T-T-P version was actually negotiated for this request.
Step 12
Read the report in order: delivery verdict and fingerprints, public I-P network, D-N-S and mail answers, then transfer facts. Together they describe the surface visitors reached. None of the sections independently proves the hosting contract, physical server, private origin address, or who controls the account.
Step 13
The result-reading section defines the evidence boundaries. The delivery verdict summarizes the strongest supported edge or A-S-N signal. Origin not visible means the public request ended at a proxy. I-P network is the observed A-S-N organization, not necessarily the hosting brand. C-NAME and M-X are raw D-N-S answers, with M-X reserved for email.
Step 14
The endpoint performs bounded A, quadruple-A, C-NAME, and M-X lookups plus one public web request. Team Cymru D-N-S data adds A-S-N organization, registry, and country for observed addresses. A deterministic table checks selected headers and C-NAMEs. Transfer inspection reports compression and only documented protocol hints. Cached results can trail a recent change.
Step 15
The main features are public I-P, A-S-N, C-NAME, and M-X evidence in one report; supported C-D-N and edge fingerprints; compression and protocol-hint summaries; and an explicit distinction between delivery network, origin host, and mail host. That separation is what keeps the result useful and honest.
Step 16
A C-D-N result may conceal the origin. A-S-N country is not physical location. Private D-N-S, geographic routing, multiple C-D-Ns, reseller relationships, unsupported platforms, and signals that change by request can make the snapshot incomplete. One public check cannot prove an infrastructure contract or where data is stored.
Step 17
When the origin matters, verify it in the hosting account, D-N-S zone, load-balancer configuration, or provider records you control. Save the lookup evidence and time, then repeat the check after a routing or platform change. Use the public result to narrow the investigation, not to override authoritative account configuration.
Record the public evidence—and keep the origin claim honest.
Save the exact domain, lookup time, delivery verdict, supporting headers, public addresses, A-S-N organization, C-NAME, M-X answer, and transfer facts with your notes. If the public edge hides the origin, verify the actual host inside the hosting account, D-N-S zone, or infrastructure configuration you control. Repeat the check after a change because public routing and response headers can vary.
Common issues & how to fix them
- Warning CDN evidence obscures the origin host Fix: Check account, DNS history, and origin-only records rather than treating the CDN edge network as the hosting provider.
- Information Hosting provider cannot be identified Fix: Confirm the provider from billing, infrastructure configuration, or origin DNS because public signals are insufficient to identify it.
- Warning DNS and header provider signals conflict Fix: Verify the active origin in DNS and deployment settings, then remove stale provider records and headers.