Web & TLS
Open HTTP Status →Start with the exact website symptom
Use HTTP Status when a website does not open as expected or behaves differently over IPv4 and IPv6. Enter the public target accepted by the tool and record the tested destination. The result describes a request from the test location. It does not load images, execute scripts or reproduce your signed-in browser session, so a normal response is only one piece of evidence.
Read the response class
A 2xx response reports success for the request, while 3xx responses need redirect or cache context. A 4xx response concerns the request or access to the resource, and 5xx indicates a server-side failure in handling it. Look at the exact code and redirect destination before acting. For example, a 403 can come from an access policy or edge filter; it is not automatically proof of a broken origin.
Separate an HTTP error from no HTTP response
DNS resolution, TCP connection or TLS verification can fail before an HTTP status exists. Preserve that stage and error instead of calling every failure a 500 error. Use DNS Lookup for address answers, Port Checker for TCP reachability and SSL Certificate for TLS findings. If a response is explicitly marked unverified, do not treat it as evidence that certificate verification passed.
Compare address families and follow through
The tool’s explicit IPv4 and IPv6 choices do not fall back to the other family. Compare the resolved addresses, TLS observations and response statuses separately. One family can reach a different endpoint. After a server response succeeds, check the real page in a browser; a 200 response can still contain an error message, missing assets or a failing JavaScript application.
Worked example
Illustrative example — not a live test IPv4: HTTPS 200 IPv6: connection timed out Conclusion: one family responded; investigate IPv6 addressing and reachability.
What to check next
- Record the status or the connection stage that failed.
- Compare the same hostname over both IP families if relevant.
- Validate the user-facing page after the server response is corrected.
Common questions
Does HTTP 200 prove every page feature works?
No. The checker does not execute the page’s application code or test its complete user journey.
Why can my browser work while the online request fails?
Source networks, IP versions, cookies and access policies can differ. Compare the tested endpoint and response before drawing a conclusion.