Identify the exact failure

Write down the complete URL, hostname, browser message, HTTP status if any, time and affected network. DNS errors, connection timeouts, TLS warnings, 403, 502 and 504 are different failures.

Check domain and IP resolution

Use DNS Lookup for the root domain and important hostnames such as www or api. Confirm A and AAAA point to the intended service, and that a CNAME eventually reaches usable address records.

Check IP and HTTPS

Use IP Lookup to compare the returned address, network and ASN with the expected host. Then use Website Diagnostics to inspect HTTPS status, response time, final URL, headers, certificates and redirects.

Check the origin stack

If DNS and HTTPS reach the expected host, check the CDN or reverse proxy, virtual host, firewall, listening ports, PHP-FPM or application process, database and server resources. A 502 often means the proxy cannot reach its upstream; 503 can indicate an unavailable service; 504 usually indicates an upstream timeout.

Compare networks and address families

If mobile data works but office Wi-Fi does not, compare resolver, firewall and routing conditions. If IPv4 works but IPv6 fails, test the AAAA path and IPv6 firewall separately.

A practical incident sequence

Capture the symptom, query DNS, confirm the intended IP, inspect IP and HTTPS, review origin logs, correct one layer at a time, and retest from more than one network after caches and services update.

What not to assume

A successful DNS lookup does not prove the application is healthy, a 200 response from one location does not prove global availability, and IP geolocation is not an exact physical location.

Check real data now

Use the live IIPP tool to inspect the domain or IP address you are working with.

Website Diagnostics →