Using the Enterramon Server Check
What is a Server Check
A domain name resolving is not the same thing as a server actually answering. Server Check is what confirms the second half of that, it connects to the server directly on ports 80 and 443, the ones a browser actually uses, and looks at what comes back.
At its core it’s a connection probe, not a crawl or a full site audit. It resolves the domain, connects over IPv4 and IPv6 where both are available, completes the TLS handshake, and reads what the server identifies itself as in the response. Everything it reports comes from that one connection attempt, timed at each stage, plus whatever the server’s headers and certificate reveal about themselves.
Using the Enterramon Server Check
Head to enterramon.com/server-check and enter a domain.
Pick a region before running it. Cape Town, Frankfurt, Singapore, St Louis, or Sydney. A server can connect cleanly from one region and show a completely different picture from another, particularly if there’s a CDN edge involved, so the region you test from actually changes what you’ll see.
Hit Run Test and we resolve the domain, then connect on both IPv4 and IPv6 where available, checking which one responds and how fast.
Understanding the server check results
Connection
Shows whether IPv4 and IPv6 are each active, and if so, the connect time and TLS handshake time for each, broken out separately rather than lumped into one number. This split matters, a slow connect time points at network or routing, a slow handshake points at the TLS setup itself, and separating the two tells you where to actually look first.
HTTP Version
Whether the server is answering on HTTP/1.1, HTTP/2, or HTTP/3. Worth checking if you’ve configured HTTP/2 or HTTP/3 and want to confirm it’s actually being served, since a misconfiguration can silently fall back to an older version without anything obviously breaking.
Security
Certificate validity, protocol version, and issuer. A quick way to confirm the certificate is current and who issued it, without digging through browser certificate details manually.
Server
The server software, if it’s exposed in the response headers, and whether a CDN was detected in front of the origin. Not every server announces itself, some deliberately hide this, so a blank result here isn’t necessarily a problem on its own.
Geography
Country, city if available, timezone, and network of the resolved IP. A fast way to confirm where the server is actually sitting, which matters more than people expect after a migration or a CDN change, when the domain can still be pointing somewhere unexpected without any obvious symptoms.
Warnings
Anything the check flags as worth a closer look, shown at the top of the results when present.
How a server check can help you
A domain resolving correctly and a server responding correctly are two different things, and a lot of real problems live in that gap. DNS can point exactly where it should while the server behind it is slow, misconfigured, or serving an expired certificate, and nothing about the DNS lookup itself would ever show that.
CDN detection is one of the more common uses. Plenty of site owners assume they’re 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 instead. The symptoms tend to be vague, slightly slower load times, occasional timeouts under load, nothing that points directly at a 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 a visitor on the failing protocol actually hits the problem and complains. Running both side by side turns that into something visible before it becomes a support ticket.
And separating connect time from TLS handshake time is useful anytime a site “feels slow” and you want to rule out the connection layer before looking at the application. If both of those are fast and the site still feels sluggish, the bottleneck is somewhere else entirely, server processing, database queries, or page weight, and you’ve just saved yourself time chasing the wrong thing.
What a server check is not
This is a connection-level probe, not a full site audit. It tells you whether the server answers correctly on 80 and 443, how fast, over which protocols, and with what certificate. It does not load the page, render it, or measure how long the actual content takes to appear to a visitor.
So a clean Server Check result doesn’t mean the site loads fast, it means the server itself is reachable and responding properly at the connection level. Page load speed depends on far more than that, page weight, how many resources need to load, how the browser renders everything once the connection is established. None of that is in scope here.
It also isn’t a security audit. Certificate validity and protocol are checked, but that’s a narrow slice of security, not a vulnerability scan or a hardening review. And CDN or server software detection depends entirely on what the server chooses to expose in its headers, some deliberately hide this information, so an “unknown” or blank result here isn’t a fault, it’s just a server that isn’t announcing itself.
If you want to know why a page feels slow rather than whether the server is reachable, that’s a different kind of test entirely, this one answers a narrower question, and answers it well.
