Hosting & Infrastructure: what this section covers
Hosting & Infrastructure identifies the public network and technology signals visible from a website: resolved endpoints, ASN ownership, CDN/reverse-proxy signatures, server/platform hints and CMS/framework fingerprints. It deliberately separates an edge provider from a protected origin host.
Signals that matter for hosting infrastructure
The pages here interpret origin reachability and HTTP availability evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.
- Hosting checker — Verify hosting checker from the public Internet and compare it with the value the responsible provider says should be live.
- Asn lookup — Verify asn lookup from the public Internet and compare it with the value the responsible provider says should be live.
- Cdn detector — Verify cdn detector from the public Internet and compare it with the value the responsible provider says should be live.
Which Hosting & Infrastructure check to start with
Use Who Hosts This Website? for the combined network/provider view, ASN Lookup for ownership of a public endpoint, CDN Detector for edge signatures and CMS Detector for application fingerprints. A Cloudflare address normally identifies Cloudflare, not the hidden server behind it.
Diagnosis first, raw evidence second
The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For hosting infrastructure, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.
What a repaired hosting infrastructure problem should look like
Infrastructure detections are confidence-labelled observations, not repair instructions by themselves. Use them to find which provider/layer to investigate, then follow the DNS, HTTPS, HTTP or provider guide tied to the actual failure. Unknown and CDN-hidden origins stay unknown rather than guessed.
Validate the origin reachability and HTTP availability change
The redirect chain should terminate at one intended HTTPS URL without a loop or unnecessary hop, and the final response should be the expected application page. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.