Server Check
A comprehensive health audit that verifies server reachability, SSL validity, and CDN performance. It ensures your site is correctly configured and accessible across both modern and legacy IP versions.
Enter a domain and pick a region, or run it across all five if you want a wider view.
The tool resolves the domain first, then connects to the server over both IPv4 and IPv6 where available, checking which one actually responds and how fast.
You'll get back the resolved IP, HTTP version (1.1, 2, or 3), full SSL certificate details, detected CDN provider, and the server software if it's exposed in the headers.
Everything is timed. Connection time, TLS handshake time, and total response time are all broken out separately, so if something is slow, you can see exactly which stage is responsible rather than just knowing the page took a while to load overall. There is also a geo lookup on the resolved IP, showing country, city, and network, which is a fast way to confirm where a server is actually sitting versus where you think it is.
A domain resolving correctly and a server responding correctly are two different things, and a lot of problems live in the gap between them.
DNS can point exactly where it should while the server behind it is slow, misconfigured, or serving an expired certificate.
This check looks past the DNS answer and actually talks to the server, which is the only way to catch issues that a ping or a DNS lookup would miss entirely.
CDN detection is a good example of why this matters. Plenty of site owners assume they are behind a CDN because they set one up months ago, then a plugin update or a DNS change quietly routes traffic straight to the origin server instead. The symptoms are usually vague, slightly slower load times, occasional timeouts under load, nothing that points directly at the cause. Seeing the CDN provider (or seeing that none is detected) settles that question immediately.
The IPv4 versus IPv6 comparison catches a similar class of problem. It's common for a server to be perfectly healthy on one protocol and quietly broken on the other, especially after a network change, and most site owners have no way of knowing unless something breaks for a visitor whose ISP prefers the failing protocol. Running both side by side turns that into something you can see and fix before it becomes a support ticket.
