"It works for me" is the most frustrating sentence in web operations. Before you can fix an outage you have to answer one question honestly: is the server actually unreachable, or is only one path to it broken? A reachability check answers that in a few seconds.
Why a classic ping can lie
The ping command sends ICMP echo requests. That works on a home network, but on the public internet it is a weak signal:
- Many hosts and cloud firewalls drop ICMP on purpose, so a timeout can mean "filtered," not "down."
- ICMP reaching the machine tells you the box is up. It says nothing about whether the service, your website on 443, your mail server on 25, is actually listening.
That gap is why a server can answer ping while the site is dead, or ignore ping while serving traffic perfectly.
What a TCP reachability check proves
Instead of an ICMP echo, open a real TCP connection to the port the service runs on. If the handshake completes, you have proven two things at once:
- The host is reachable across the network.
- Something is listening and accepting connections on that port.
That is almost always the question you actually care about. Our Ping / Reachability tool does exactly this, it opens several connections to the host and port you choose and reports each attempt.
How to read the result
- 0% loss, low latency, the service is up and answering. A steady 20-80 ms to a distant host is normal; sub-millisecond means it is very close on the network.
- Partial loss (e.g. 50%), reachable but flaky. Suspect an overloaded server, a saturated link, or an anycast node flapping.
- 100% loss, no connection completed. The host may be down, the port may be closed, or a firewall is silently dropping the traffic. Re-check from a second network to rule out your own ISP.
A useful trick: change the port
Loss on port 443 but success on port 80 usually means the web server is up but TLS is misconfigured. Success on 80/443 but 100% loss on 25 is normal from cloud networks, outbound port 25 is widely blocked to fight spam, so that result reflects the tester's network, not your mail server. Always interpret a mail-port result with that in mind.
Quick command-line equivalents
# TCP connect test with netcat
nc -vz example.com 443
# curl reports connect time separately from total time
curl -o /dev/null -s -w "connect: %{time_connect}s\n" https://example.com
# PowerShell (Windows)
Test-NetConnection example.com -Port 443
FAQ
Why does the tester show a different result than my own ping?
The tester checks from a data-center network with a clean path. If your local result differs, the problem is likely between you and the host, your ISP, VPN, office firewall, or local DNS.
The host answers on 443 but my browser still fails. Now what?
Reachability is fine, so move up the stack: check the TLS certificate, then DNS for the exact hostname, then application errors. Start with the SSL/TLS certificate checker.
Can I trust a "100% loss" on port 25?
Not by itself. Cloud egress networks block outbound 25, so the loss reflects the tester's network. Verify mail reachability from a network that permits 25, or test STARTTLS on 587.