Ping is the first tool anyone reaches for when a host seems unreachable, and it is also one of the most over-interpreted. A reply feels like proof that “the server is up”; silence feels like proof that it is down. Neither conclusion is quite what the tool actually establishes. This guide walks through what ping really does, how the NetworkUtils.org Ping tool behaves, how to read the output of the three major operating-system implementations, and how to draw defensible conclusions from each.
Executive summary
Traditional ping sends an ICMP Echo Request and measures the time until the matching Echo Reply returns. It is useful for reachability, round-trip delay, packet-loss sampling, route isolation, and MTU investigation. It does not prove that a website, API, database, or other application is healthy.
There is no single universal ping program. Windows, Linux iputils, macOS/BSD, embedded systems, and web services have different syntax and behavior. Always state the protocol, source location, destination address, address family, probe count, and timeout when interpreting a result.
Critical NetworkUtils.org finding: the site describes its Ping tool as ICMP-based, but a live verification produced output labeled “via TCP/80.” Its results should therefore be read as ping-style remote reachability data; when TCP/80 is shown, the test is not equivalent to an operating-system ICMP ping.
Core rules
- A reply proves only that the tested probe received a matching response.
- Silence does not prove that a host is offline; filtering and rate limiting are common.
- RTT is round-trip latency, not one-way delay.
- The TTL shown in a reply is the remaining return-packet TTL, not an exact hop count.
- Four probes are a quick check, not a statistically strong loss study.
- Follow ping with DNS, route, port, TLS, and application tests.
How traditional ping works
For IPv4, an ICMP Echo Request is type 8 and its Echo Reply is type 0. For IPv6, ICMPv6 Echo Request and Reply are types 128 and 129. A request contains a checksum, identifier, sequence number, and payload. The reply normally returns the identifying fields and payload, allowing the sender to match replies and calculate elapsed time.
Client Target |---- ICMP Echo Request, seq=1 ---->| |<--- ICMP Echo Reply, seq=1 ------| |<--------- round-trip time ------>|
TTL and Hop Limit
Each IPv4 router decrements TTL; IPv6 uses the Hop Limit field. A router that reduces it to zero discards the packet and may return a Time Exceeded error. The received TTL belongs to the reply packet. Estimating hops requires guessing the responder’s initial TTL, and asymmetric routing can make the forward and return paths differ.
Packet size
A common Unix default is 56 bytes of payload. With an 8-byte ICMP header and a normal 20-byte IPv4 header, the resulting IP packet is 84 bytes before link-layer framing. Windows normally uses a 32-byte payload. Output such as “64 bytes from” commonly counts payload plus ICMP header, not the IP or Ethernet headers.
The NetworkUtils.org Ping tool
The web interface accepts a hostname or IP address and advertises IPv4/IPv6 probing, automatic hostname resolution, per-probe latency, loss, and minimum/average/maximum latency. It currently exposes no traditional command-line flags: count, payload size, TTL, interval, source interface, and timeout are not user-selectable.
PING example.org (104.20.26.136) via TCP/80 - 4 probes seq 0 2 ms seq 1 1 ms seq 2 1 ms seq 3 1 ms --- example.org ping statistics --- 4 probes, 4 received, 0% packet loss rtt min/avg/max = 1/1/2 ms
Reading every field
- PING example.org: the entered hostname.
- (104.20.26.136): the address selected after DNS resolution; another region or later query may select a different address.
- via TCP/80: TCP was tested on destination port 80. This is not an ICMP Echo exchange.
- 4 probes: four attempts were made by the service.
- seq 0: service-specific attempt number; a missing or timed-out sequence means no qualifying response arrived by the deadline.
- 2 ms: reported round-trip measurement for that probe, subject to service definition and display rounding.
- 4 received: four qualifying responses were recorded.
- 0% packet loss: (sent − received) / sent × 100. For TCP probes, this means failed probes rather than proof of individual IP-packet drops.
- min/avg/max: the lowest, arithmetic mean, and highest RTT among successful probes.
Probe-location caveat
The result describes NetworkUtils.org probe → destination → probe, not your computer’s path. It is valuable for outside-in comparison, but it cannot reproduce local Wi-Fi, ISP, VPN, firewall, or routing conditions.
Understanding operating-system output
A typical Unix ping line carries more information than it appears to at a glance:
PING example.org (93.184.216.34): 56 data bytes 64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=21.7 ms --- example.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss rtt min/avg/max/mdev = 20.9/21.3/21.7/0.4 ms
- 56 data bytes: ICMP payload, normally excluding ICMP, IP, and link headers.
- 64 bytes from: commonly the 56-byte payload plus the 8-byte ICMP header.
- icmp_seq: correlates requests and replies; gaps can indicate loss and changed ordering can indicate reordering.
- ttl=54: remaining TTL in the reply.
- time=21.7 ms: RTT for this request and reply.
- mdev/stddev: variation around average latency; smaller generally means more consistent delay.
Windows presents the same ideas with different labels:
Pinging example.org [93.184.216.34] with 32 bytes of data: Reply from 93.184.216.34: bytes=32 time=21ms TTL=54 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Windows bytes=32 is the payload size. time<1ms means below the displayed one-millisecond threshold, not zero latency.
Windows ping flags
Microsoft syntax:
ping [/t] [/a] [/n count] [/l size] [/f] [/i TTL] [/v TOS] [/r count] [/s count]
[{/j hostlist | /k hostlist}] [/w timeout] [/R] [/S source] [/4] [/6] target
| Flag | Meaning |
|---|---|
| /t | Continue until Ctrl+C; Ctrl+Break prints interim statistics. |
| /a | Reverse-resolve the destination address to a hostname. |
| /n count | Send count requests; default is four. |
| /l size | Set ICMP payload bytes; default 32. |
| /f | Set IPv4 Don’t Fragment. |
| /i TTL | Set outgoing IPv4 TTL. |
| /v TOS | Set IPv4 Type of Service. |
| /r count | IPv4 Record Route for 1–9 hops; frequently ignored. |
| /s count | IPv4 Internet Timestamp for 1–4 hops; poorly supported. |
| /j hostlist | Loose IPv4 source route, maximum nine; obsolete/usually blocked. |
| /k hostlist | Strict IPv4 source route, maximum nine; obsolete/usually blocked. |
| /w timeout | Per-reply timeout in milliseconds; default 4000. |
| /R | IPv6 round-trip path tracing. |
| /S source | Select IPv6 source address. |
| /4 | Force IPv4 for a hostname. |
| /6 | Force IPv6 for a hostname. |
| /? | Display help. |
ping /n 10 example.org ping /t 192.168.1.1 ping /l 1400 /f example.org ping /w 1000 /4 example.org
Linux iputils ping flags
The following applies to the mainstream iputils implementation. GNU Inetutils, BusyBox, and vendor builds differ.
Address family and basics
-4 IPv4 only; -6 IPv6 only; -c count stop after count requests; -h help; -V version; -v verbose; -q quiet.
Timing and rate
-i interval seconds between sends; -w deadline overall seconds; -W timeout response wait in seconds; -A adaptive; -f flood; -l preload initial burst; -O report outstanding replies; -U user-to-user latency; -3 preserve RTT precision.
Output and naming
-a audible; -D Unix timestamps; -H force reverse DNS; -n numeric only; -L suppress multicast loopback; -j JSON when supported.
Routing and sockets
-B keep initial source address; -C connect() socket; -I interface/address/VRF; -r bypass normal routing for directly attached host; -m mark packet mark; -S sndbuf; -e identifier; -b permit broadcast.
IPv6 controls
-F flowlabel sets IPv6 flow label; -N nodeinfo-option sends an IPv6 Node Information Query.
Packet and path controls
-s packetsize payload bytes; -p pattern hexadecimal payload; -t ttl sets IPv4 TTL/IPv6 Hop Limit; -Q tos sets DSCP/TOS or Traffic Class; -R IPv4 Record Route; -T timestamp-option uses IPv4 timestamp options; -d sets SO_DEBUG.
Path MTU discovery
-M do sets DF and applies kernel PMTU checks; want permits local fragmentation where applicable; dont disables PMTU discovery; probe sets DF while bypassing kernel PMTU checks; interface uses interface MTU; bypass bypasses PMTU discovery.
ping -c 5 example.org ping -6 -c 5 example.org ping -I eth0 -c 4 example.org ping -s 1400 -M do -c 4 example.org ping -D -O example.org
iputils exit status: 0 for success under the requested conditions; 1 for no replies or an unmet count/deadline condition; 2 for another error.
macOS / BSD ping flags
Audio and output
-a bell on reply; -A bell on missing reply; -n numeric; -q quiet; -Q suppress related ICMP errors; -v verbose; --apple-time reception time; --apple-print-id Echo ID; --apple-print-req request information.
Count and timing
-c count; -i wait seconds; -t timeout overall seconds; -W waittime per-packet milliseconds; -o exit after first reply; -f flood; -l preload.
Packet controls
-s payload size; -p hexadecimal pattern; -D Don’t Fragment; -m unicast TTL; -z TOS; -M mask sends Address Mask Request; -M time sends Timestamp Request.
Size sweep
-g starting payload; -G maximum payload; -h increment. On macOS, -h is sweep increment, not help.
Interfaces and policy
-b boundif binds interface; -C avoids cellular; -S source address; -P IPsec policy; -k traffic class; -K network service type; --apple-connect connects the socket.
Multicast
-I source interface address; -L suppress loopback; -T multicast TTL.
Legacy routing
-R Record Route is documented as deprecated/no-op; -r bypasses normal routing for directly attached targets.
ping -c 5 example.org ping -S 192.0.2.20 -c 5 example.org ping -D -s 1400 -c 4 example.org ping -g 100 -G 1500 -h 100 -c 1 example.org
Cross-platform traps
The same letter means different things on different systems. Always check the local manual before trusting a flag.
| Purpose | Windows | Linux iputils | macOS |
|---|---|---|---|
| Probe count | /n | -c | -c |
| Payload | /l | -s | -s |
| Outgoing TTL | /i | -t | -m |
| Per-reply timeout | /w ms | -W seconds | -W milliseconds |
| Overall deadline | — | -w seconds | -t seconds |
| Don’t Fragment | /f | -M do | -D |
| Output timestamp | — | -D | --apple-time |
| IPv4 / IPv6 | /4 / /6 | -4 / -6 | ping / ping6 |
A dangerous example: ping -W 1 means a one-second response timeout on Linux iputils but a one-millisecond wait on macOS. Likewise, -D prints timestamps on Linux and sets Don’t Fragment on macOS.
Failures and unusual output
Request timed out
No expected reply arrived before the deadline. Causes include an offline target, no route, filtering, ICMP rate limiting, a closed/filtered TCP port in TCP-based tests, return-path failure, or excessive delay.
Destination host unreachable
A host or router actively reported inability to deliver the probe. The address that generated the error is diagnostically important; it may be your gateway rather than the target.
General failure (Windows)
The local stack could not send or process the probe normally. Check local addresses, routes, adapters, VPNs, and security software.
TTL exceeded
A router discarded the packet when TTL/Hop Limit reached zero. This is expected with deliberately small TTLs; otherwise it can indicate a loop or unexpectedly long path.
Fragmentation needed / DF set
The packet exceeded a link MTU while IPv4 fragmentation was prohibited. This is evidence useful in Path MTU diagnosis.
DUP!, corruption, and changing TTL
Duplicate unicast replies can indicate unusual link retransmission, duplicate paths, or faulty equipment. Corrupted payloads are serious and can implicate hardware or drivers. Changing TTL may reflect different backends, routes, anycast nodes, or initial TTLs.
Practical scenarios
Separate DNS from reachability
Ping a hostname and then a known current address. If only the name fails, inspect DNS. Remember that a hostname can map to multiple addresses and virtual hosting makes a bare-IP application test incomplete.
Progressive isolation
- Test 127.0.0.1 and ::1 for the local stack.
- Test the local interface address.
- Test the default gateway.
- Test another LAN host.
- Test a known Internet IP.
- Test a hostname.
- Finally test the actual port, TLS, and application protocol.
Intermittent loss
Run simultaneous continuous tests to the gateway, an external IP, and the affected service. Gateway and Internet failures together point locally; a stable gateway with failing Internet suggests upstream trouble; stable ICMP while the application fails points above the IP layer.
IPv4 versus IPv6
Force each address family separately. IPv6-only failure can involve addressing, router advertisements, default routes, VPN support, AAAA records, or overbroad ICMPv6 filtering.
Path MTU
Windows: ping /f /l 1472 example.org Linux: ping -M do -s 1472 -c 4 example.org macOS: ping -D -s 1472 -c 4 example.org
For ordinary IPv4, 1472 payload + 8 ICMP + 20 IPv4 = 1500 bytes. Decrease the payload until probes succeed, but corroborate the result because ICMP filtering can imitate an MTU failure.
Outside-in comparison
Use NetworkUtils.org to ask whether a destination is reachable from its probe network. Local failure plus remote success suggests a local, ISP, route, regional, DNS, or filtering issue. Account for the site’s observed TCP/80 behavior.
Monitoring
Use ping as one signal, not the only signal. Production monitoring should combine ICMP, DNS, TCP, TLS, and application requests from suitable locations.
What conclusions are defensible?
Successful ICMP ping
At least one Echo Request traveled from this source to this selected address and a matching Echo Reply returned within the timeout. It does not prove that an application or port works.
Failed ICMP ping
No qualifying response was observed. It does not prove that the machine is off, the address unused, or application traffic blocked.
Successful NetworkUtils TCP/80 result
A TCP port 80 probe from the site’s probe to the selected address received the service-defined qualifying response. It does not prove that ICMP works or that an HTTP page is correct.
Recommended wording
Prefer: “Four ICMP Echo Requests from this host to this IPv4 address received four replies with RTTs of 21–24 ms.” Avoid: “The server is up.” Precise language preserves what the test actually established.
Diagnostic decision path
Resolve hostname -> Confirm selected IPv4/IPv6 address -> Test ICMP from the affected machine -> Test gateway and known external IP -> Compare with a remote probe -> Trace route when path matters -> Test the actual TCP/UDP port -> Test TLS and the application protocol
- Name resolution fails: inspect DNS.
- ICMP fails but TCP succeeds: suspect ICMP filtering or deprioritization.
- ICMP succeeds but TCP fails: inspect service listeners, ports, and firewalls.
- TCP succeeds but TLS fails: inspect certificates, SNI, trust, and protocol versions.
- TLS succeeds but the request fails: inspect application behavior, redirects, authentication, and content.
- Only large transfers fail: investigate Path MTU.
- Only one region fails: investigate routing, CDN selection, and regional filtering.
Sources and version scope
- NetworkUtils.org Ping
- Microsoft Learn: Windows ping
- Linux iputils ping(8)
- macOS ping(8)
- RFC 792: ICMP for IPv4
- RFC 4443: ICMPv6
Flags vary by operating-system release and installed package. The local help or manual on the tested host is the final authority. NetworkUtils.org behavior was verified in September 2026 and may change independently of this document.