Network Diagnostics
How do people check whether a website is reachable?
8 minLive network
Words you’ll meet:
Loading the simulation…
How do people check whether a website is reachable?
Loading the simulation…
You are in Learn mode: everything below is a simulation running in your browser. The “Live network” badge in the page header means this module can reach a network in Live mode, not that anything here does.
A short, healthy path to a cache on the local Internet exchange. Every router answers, the destination answers, and both tools mean exactly what they appear to mean. Read this one first so the other five have something to disagree with.
7 steps. Pause, step back or replay any of them.
Nothing selected
Click anything on the map (a device, a cable, or a moving message) to see what it is.
TCP handshake to port 443 completed in 20.65 ms. assets.example is up and serving, whatever the ICMP column says.
This is a TCP connection attempt, not an ICMP echo. It measures a different protocol reaching a different layer of the far end, which is exactly why it can disagree with the column beside it.
assets.example answers every probe in about 21.112 ms.
Next: Treat this as a floor on latency and a check on routing, then test the actual service. A clean ping and a broken application are an ordinary combination.
ICMP is a different protocol from the one you care about
An echo reply is generated by the IP stack in the kernel. It travels under protocol number 1, not 6, so a firewall rule, an ACL, or a cloud security group can permit every byte of your application traffic and still drop every probe. Filtering ICMP echo is a default in a large part of the Internet.
Answering an echo is not evidence that a service is running
The reply comes from the kernel, which has no idea whether the web server above it crashed an hour ago. A host can answer ping perfectly while every port on it refuses connections.
ICMP is the first traffic a busy router or host sheds
Generating ICMP is control-plane work on hardware built to forward packets, so it is rate-limited by design. Loss and latency spikes on probes routinely appear on a path that is carrying real traffic without a problem.
The loss you measure may not be at the far end
Every hop in between can drop the request on the way out or the reply on the way back, and ping cannot tell you which. A single number for a path made of eight independent links is an average, not a diagnosis.
PING assets.example (198.51.100.60) 56(84) bytes of data.64 bytes from 198.51.100.60: icmp_seq=1 ttl=60 time=21.5 ms64 bytes from 198.51.100.60: icmp_seq=2 ttl=60 time=20.8 ms64 bytes from 198.51.100.60: icmp_seq=3 ttl=60 time=21.1 ms64 bytes from 198.51.100.60: icmp_seq=4 ttl=60 time=20.8 ms64 bytes from 198.51.100.60: icmp_seq=5 ttl=60 time=21.7 ms64 bytes from 198.51.100.60: icmp_seq=6 ttl=60 time=20.8 ms --- assets.example ping statistics ---6 packets transmitted, 6 received, 0% packet loss, time 5021msrtt min/avg/max/mdev = 20.770/21.112/21.670/0.355 ms