Classify the failure first

Record the complete URL, hostname, browser message, HTTP status if any, timestamp and affected network. A name-resolution error, a TCP timeout, a TLS warning, a 403, a 502 and a 504 identify different layers. Do not start by changing DNS just because the page does not open.

Confirm the expected destination

Use DNS Lookup for the root domain and important hostnames such as www, api or a login subdomain. Check A, AAAA and CNAME records, then use IP Lookup to compare the returned address, ASN and network with the service you expect. A valid DNS answer can still point to an old, parked or unintended server.

Test TCP reachability separately

If the address is correct but the browser waits until timeout, investigate routing, security groups, firewalls, listening ports and rate limits. Test IPv4 and IPv6 independently. A successful DNS lookup does not open port 443, and a reachable server does not guarantee that the web application is accepting requests.

Inspect TLS before HTTP

A certificate warning, handshake failure or protocol error happens before the server can return a normal HTTP status. Check that the certificate covers the exact hostname, the chain is complete, the certificate is not expired, SNI selects the correct virtual host and the proxy-to-origin TLS mode is compatible. Test the bare domain and www separately.

Read the HTTP response and redirects

When TLS succeeds, inspect the status code, Location headers, final URL, response time and important headers. A 301 or 308 should lead to the intended canonical URL; a loop or long chain suggests conflicting proxy and application rules. A 403 may come from authentication, a firewall or an edge policy rather than DNS.

Trace 502, 503 and 504 to the origin

A 502 often means a proxy received an invalid response or could not speak to its upstream. A 503 can mean the service is unavailable, overloaded or in maintenance. A 504 usually indicates an upstream timeout. Compare CDN, proxy, web-server and application logs using the exact diagnostic timestamp, then check workers, sockets, PHP-FPM, databases and external APIs.

Compare networks and address families

If mobile data works but office Wi-Fi fails, compare resolver answers, firewall policy, proxy settings and routes. If IPv4 works but IPv6 fails, check the AAAA target, IPv6 listener, security rules, load balancer and certificate. Do not assume every client will reliably fall back from a broken IPv6 path.

A controlled incident workflow

Capture the symptom; query DNS; confirm the intended IP; test TCP and TLS; inspect HTTP and redirects; review the relevant logs; change one layer; record the result; and retest from more than one network. Keep the old configuration and service available until caches, proxy configuration and application health have converged.

What a public diagnostic can and cannot prove

IIPP can show public DNS answers, IP context, HTTPS status, response time, redirects and headers from its own network. It cannot prove that every resolver, ISP, firewall or authenticated user has the same experience. Do not submit credentials or private URLs, and only test systems you are authorized to inspect.

Check real data now

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

Website Diagnostics →