ping: What an Echo Actually Proves

ping builds an ICMP echo request (type 8) inside an IP packet, sends it to the destination, and waits for an echo reply (type 0). The reply is generated by the destination’s kernel — no process, no port, no listener is involved. So a reply proves exactly this: a route to the host exists in both directions, the host is powered on with a working IP stack, and nothing on the path filtered ICMP echo. Nothing else.

ICMP is not a transport. It has no ports, so it cannot address a service; it carries a sequence number and an identifier so that the sending ping can match replies to requests and detect loss and reordering. The round-trip time it reports is the time for a tiny packet — 64 bytes by default on Linux and macOS, 32 bytes of payload on Windows — to be routed there and back. It says nothing about bandwidth, and only a little about what a 100 kB HTTP response would experience.

That tiny scope is also what makes ping useful: because it needs nothing running on the far end, it is the cleanest test of the lower rungs of the Why Can’t I Connect? ladder — route and host — with no application in the way.

Firewalls, cloud security groups and host firewalls routinely block ICMP echo while allowing TCP 443. AWS security groups have no ICMP rule by default; Windows Firewall blocks inbound echo by default on public profiles; many hardening guides drop ICMP wholesale. The result is a host that serves HTTPS flawlessly and never answers a ping. The correct reading of a failed ping is "ICMP echo is not reaching or not being answered", not "host down".

The confirmation is a probe at the layer you care about: nc -vz host 443, curl -sI https://host/, or Test-NetConnection host -Port 443. If the TCP probe connects, the host is up and the ping was filtered. If the TCP probe times out too, you now have two layers agreeing, which is much stronger evidence. The interview question "ping fails but the service works" is exactly this reasoning.

A rare inverse: ICMP is sometimes rate-limited rather than blocked, so a long ping shows sporadic loss that TCP never experiences. Routers and hosts cap ICMP generation on their control plane; a 2% ping loss to a router interface is normal, and means nothing about the data plane forwarding through it.

The reply is generated a few layers below any process. A server whose application crashed, whose listener is bound to 127.0.0.1, whose certificate expired last night, or whose disk is full still returns pings in 12 ms. Ping proves "host up", and "host up" is the fourth rung of a nine-rung ladder. The remaining five — port, handshake, TLS, HTTP, application — need their own tests, and each of them can fail with a perfect ping.

This is why production health checks are HTTP requests to a real endpoint, not pings. A load balancer that pinged its backends would happily send traffic to a machine whose web server was dead.

Each reply line carries the sequence number, the TTL of the reply (which hints at hop count: 64 − 54 = about 10 hops if the far end started at 64), and the RTT. The summary gives sent, received, loss percentage, and min/avg/max/mdev. mdev (standard deviation of RTT) is jitter; a low average with a high mdev means an unstable path or a congested queue somewhere — bad for real-time traffic even if the average looks fine. Missing sequence numbers are loss; the summary percentage is the headline.

Calibrate the RTT against geography: ~1 ms on a LAN, ~10–30 ms within a region, ~80 ms across a continent, ~150 ms transatlantic, ~250 ms+ to the antipodes, 600 ms via geostationary satellite. An RTT far above the geographic floor means a detour or a queue — Latency: Same Machine to Cross-Continent lets you build the intuition. Loss above ~1% on a wired path is abnormal and will cripple TCP throughput (Packet Loss: Duplicate ACKs, Fast Retransmit and the RTO).

On IPv6 the tool is ping -6 or ping6 (macOS and older Linux), and the messages are ICMPv6 echo request (type 128) and reply (type 129). The important difference is what else ICMPv6 carries: neighbor discovery (the IPv6 replacement for ARP), router advertisements, and Packet Too Big — the message path-MTU discovery depends on, and which is mandatory in IPv6 because routers never fragment. A firewall that "blocks ICMP" on IPv6 the way it did on IPv4 breaks address resolution and MTU discovery, not just ping. RFC 4890 lists which ICMPv6 types must pass.

Practically: if a dual-stack host resolves to an AAAA record and IPv6 is half-configured on the client, the browser may spend seconds timing out on IPv6 before falling back (Happy Eyeballs limits this to a few hundred milliseconds in modern stacks, but curl and older clients may not). ping -6 and ping -4 separately tell you which family is actually broken.