ping is the first diagnostic for a reason: it answers the most basic question — can this machine reach that one? — with a round-trip time attached. It is ICMP echo: one packet out, one back, timed. Simple, and still the right first move.
The basic test #
$ ping -c 4 aospix.com
PING aospix.com (104.21.5.10): 56 data bytes
64 bytes from 104.21.5.10: icmp_seq=0 ttl=57 time=12.3 ms
...
--- aospix.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
round-trip min/avg/max = 11.9/12.4/13.1 msThe three numbers that matter: packet loss (should be 0%), avg time (your baseline), and spread (min≈max is healthy; wild swings mean congestion or Wi-Fi trouble). Run it against the gateway first, then outward — segmenting the path is the method:
$ ping -c 3 192.168.1.1 # the router: LAN works?
$ ping -c 3 1.1.1.1 # the internet: WAN works?
$ ping -c 3 aospix.com # names work too? (DNS layer)If the router answers and 1.1.1.1 does not, the problem is past your wall. If the IP answers but the name does not, it is DNS, not connectivity.
The flags that matter #
| Flag | Effect |
|---|---|
-c N | Stop after N packets (always use in scripts) |
-i S | Interval seconds |
-s N | Payload size — path MTU probing |
-M do | Forbid fragmentation — find the MTU ceiling |
-W S | Timeout per reply |
-4 / -6 | Force IPv4 / IPv6 |
The MTU probe is the subtle professional one — VPNs and PPPoE links with undersized MTUs cause the "small packets pass, HTTPS hangs" mystery, and this finds the ceiling mechanically:
$ ping -c 2 -M do -s 1472 10.0.0.9 # fails? lower until it passes, +28What ping cannot tell you #
Ping tests ICMP. Servers that block ICMP while serving HTTPS perfectly are common — a failed ping is not a failed service. The complements: ss shows what your side is doing, curl tests the actual service, and traceroute and mtr show where the path degrades.
For follow-the-path diagnosis, mtr is ping's smarter sibling. The network series continues.