Why ping succeeds and the application still fails

“But I can ping it.” This sentence has probably wasted more engineering hours than any other in networking. A successful ping proves one specific thing: an ICMP echo request reached the destination and an echo reply came back. That is all.

What ping does not test

It does not test that the application is listening. It does not test that the port is permitted. It does not test that a firewall allows the session in the direction the application needs. It does not test MTU beyond 84 bytes. It does not test that the return path for TCP is the same as for ICMP, and on networks with multiple exits it often is not.

Test the thing you actually care about

If the application uses TCP 443, test TCP 443:

nc -zv host 443
curl -sv --connect-timeout 5 https://host/ 2>&1 | head

A refused connection and a timed-out connection mean different things and should be read differently. Refused means something answered and said no: the host is up, the port is closed. Timed out means nothing answered at all: a firewall dropping silently, a routing problem, or a host that is not there.

The MTU case

The most frustrating version of this is when ping works, small requests work, and large ones hang. A default ping is tiny and fits anywhere. Test the real size:

ping -M do -s 1472 host

If that fails while a normal ping succeeds, you have a path MTU problem, and no amount of staring at the application will reveal it.

Devices that deprioritise ICMP

Many routers and firewalls handle ICMP in software while forwarding real traffic in hardware. High ping latency on such a device can be entirely normal while throughput is fine. The reverse also happens: ICMP permitted, application ports not.

Ping is a useful first question. Treat it as a question, not an answer.