Troubleshooting
Open HTTP Status →Record the symptom before changing anything
Save the exact URL, browser error, time and affected network. Try the intended hostname rather than only its server IP, because shared hosting and certificates depend on the hostname. If it works on Wi-Fi but not mobile, compare the network paths and IPv4/IPv6 behavior. A successful test from this VPS does not establish availability for every visitor.
1. Check DNS resolution
Use DNS Health & DNSSEC to separate NXDOMAIN, missing address records, resolver errors and suspected DNSSEC validation problems. Compare A and AAAA records with your DNS provider’s intended values. A provider migration can leave stale DS records; DNS Resolver Comparison can reveal differing cached answers but cannot measure every region.
2. Check the connection
If DNS resolves, use Run Diagnostic and review its connection stage. A timeout can involve routing, filtering, an unreachable address or a service that is not answering. Connection refused usually means an active rejection. Test the expected TCP port, commonly 443 for HTTPS. Ping failure alone does not prove a website outage.
3. Check TLS separately
Use SSL Certificate to inspect hostname coverage, expiry and chain verification. A valid certificate for another hostname will not fix a hostname mismatch. If a CDN proxies the website, the public certificate belongs to the visitor-facing connection; the CDN-to-origin certificate needs a separate check in your hosting configuration.
4. Interpret the HTTP response
A 404 can mean the requested route is missing while the server remains available. A 403 can reflect an access rule. A 502 or 504 suggests an intermediary could not obtain a suitable upstream response. A 200 response alone does not verify login, database operations or every resource. Compare the exact URL, IP family and response body in your browser.
5. Retest the affected path
After changing one confirmed cause, repeat the original test and test from the affected device or network. For intermittent failures, retain timestamps and enable scheduled monitoring where appropriate. Do not change DNS, certificates and firewall rules together without a way to identify which change mattered.
Worked example
Illustrative investigation — not a live test DNS A: returns an address DNS AAAA: returns an address HTTPS over IPv4: 200 HTTPS over IPv6: connection timeout Interpretation: investigate the IPv6 listener, routing and firewall. The AAAA record alone does not establish IPv6 readiness.
What to check next
- Record the exact browser error, URL, network and time.
- Open Run Diagnostic, then use the linked tools to inspect the failing stage.
- Compare IPv4 and IPv6 when the issue depends on the visitor’s network.
- Check server or CDN logs for the same timestamp.
- Make a targeted correction, retest and keep the before/after evidence.