Separate TLS errors from HTTP errors
A certificate warning, handshake failure or protocol error occurs before a normal HTTP response exists. A 301, 302, 307 or 308 is an HTTP response after TLS succeeds. Record the browser message, status code, hostname, address family and exact URL before changing rules.
Check certificate names and validity
Confirm that the certificate covers the exact hostname through its SAN entries, is within its validity period and chains to a trusted authority. A certificate for example.com does not automatically cover www.example.com. Check renewal, intermediate certificates and server time as well as the certificate’s issuer.
Test SNI and virtual hosts
SNI lets one IP serve certificates and sites for multiple hostnames. The client sends the requested hostname during TLS, and the edge or origin must select the matching certificate and virtual host. Testing an IP literal can show a default certificate and is not equivalent to testing the real hostname.
Test root and www independently
Treat the bare domain and www as separate endpoints. Check DNS, A and AAAA records, certificate coverage, HTTP status, final URL and page content for both. Choose one canonical hostname and configure the other to make one clear permanent redirect without competing proxy and origin rules.
Read every redirect hop
Inspect the Location target, scheme, hostname, path and query at each hop. 301 and 308 are normally permanent; 302 and 307 are temporary. An unexpected HTTP target, changing hostname, duplicated path or dropped query can reveal a proxy, application or rewrite configuration error.
Find loops and long chains
A loop occurs when one rule sends a request back to an earlier URL, often because a proxy terminates HTTPS while the origin believes the request is HTTP. Forwarded protocol headers, application URL settings and duplicate server rules are common causes. Keep the chain short and test with and without www.
Check proxy-to-origin TLS
When a CDN or reverse proxy terminates client TLS, separately verify its connection to the origin. Confirm the origin certificate name, trust mode, SNI behavior, supported protocol and port. A client-facing certificate can be valid while the edge-to-origin handshake still fails.
Verify after each configuration change
Use Website Diagnostics to record status, response time, final URL, redirect chain and headers, then compare with a normal browser. Test HTTP and HTTPS, root and www, IPv4 and IPv6 where applicable. Do not use a longer timeout or a generic redirect to hide a certificate or origin problem.
Common mistakes and safety limits
Do not treat a redirect as proof that the final page is healthy, test only an IP address, or publish credentials and private URLs to a public diagnostic tool. Important certificate and redirect changes should be verified with the hosting, CDN or certificate provider.
Check real data now
Use the live IIPP tool to inspect the domain or IP address you are working with.
Website Diagnostics →