Why Ping Working Does Not Mean the Network Is Fine

"But I can ping it!" is one of the most misleading sentences in operations. Ping working tells you something real — just far less than people assume.

What ping actually proves

Ping sends ICMP echo packets. A reply proves:

• The name resolved (if you pinged a name).
• There's a working layer-3 path to the host and back.
• The host's stack is up enough to answer ICMP.

That's it. It says nothing about whether your application's TCP port is open, whether the service is healthy, or whether a firewall allows the traffic you actually care about.

What it doesn't prove

• The port is open. ICMP and your app use different paths through firewalls. A box can ping fine while :443 is blocked or nothing's listening.
• The service works. The OS answers ICMP even if your app has crashed.
• It's not asymmetric. Replies can take a different route than your real traffic.
• Anything about DNS if you pinged an IP.

Test the layer that matters

Want to know if you can reach the service? Test the TCP port:

nc -vz app.example.com 443
# Connection to app.example.com 443 port [tcp/https] succeeded!

curl -v https://app.example.com/health

A successful TCP connect proves L3 and L4 to that port — far more than ping. If curl gets a response, you've also tested the app.

Reading the failure

sudo tcpdump -ni any host app.example.com and port 443

• No SYN-ACK after your SYN → nothing listening, or a firewall silently dropping.
• RST immediately → the port is actively refused (no listener, or a reset by a device).
• SYNs retransmitting → packets are being lost or blackholed.

A better first question

Instead of "can I ping it?", ask: "can I reach the thing I actually need, the way the app reaches it?" Then test that — the right port, ideally the real protocol.

Ping is a flashlight, not an X-ray. Use it to confirm basic reachability, then immediately move up the stack.

Sharpen this with the Networking track and the reference on checking TCP connectivity.