ping command: options, output and why ping fails on Windows, Linux and macOS

Short answer: ping HOST sends ICMP echo requests to a host and prints one line for every reply, with the round-trip time in milliseconds. Windows stops after four; Linux and macOS keep going until you press Ctrl+C, so use ping -c 4 HOST there. A reply proves the host is reachable. No reply proves much less, because many servers and networks drop ping on purpose.

ping -c 4 1.1.1.1

ping 1.1.1.1

Put your server’s IP address or a host name in place of 1.1.1.1. Below: the options on each system, how to read every number in the output, and what to do when ping fails although the website or SSH works.

ping options on Windows, Linux and macOS

The same idea has different letters on each system, and some letters mean different things. -t is “ping forever” on Windows, “set the TTL” on Linux and “stop after N seconds” on macOS:

Windows takes the options with - or /, before or after the host. The Windows column follows Microsoft’s ping reference, the Linux column the iputils man page on Debian 12, the macOS column Apple’s ping man page. Very short intervals need root.

Payload size and don’t-fragment together find MTU problems, the kind behind a VPN or tunnel where small requests work and large transfers hang. A 1,472-byte payload plus the 8-byte ICMP header and the 20-byte IPv4 header is exactly 1,500 bytes, the usual Ethernet MTU:

ping -c 4 -M do -s 1472 SERVER_IP

ping -f -l 1472 SERVER_IP

If that fails while -s 1400 (Windows: -l 1400) gets replies, something on the path has a smaller MTU. Linux says ping: local error: message too long, mtu=1420 when your own interface is the limit (1420 is typical for a WireGuard tunnel) and Frag needed and DF set with the router’s MTU when a router on the way is; Windows prints Packet needs to be fragmented but DF set. On macOS the flags are -D -s 1472.

How to read ping output

This is a real run of ping -c 4 1.1.1.1 (with -4 -W 2 added), made from our looking glass in Amsterdam:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=4.21 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=5.03 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=15.8 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=4.28 ms

--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.206/7.337/15.841/4.920 ms

• 56(84) bytes: 56 bytes of payload, 84 with the 8-byte ICMP header and the 20-byte IPv4 header. Each reply carries 64 bytes of ICMP: header plus payload.
• icmp_seq numbers the requests. Linux prints nothing for a lost packet, so a gap in the sequence (1, 2, 4) is how a loss shows up. Add -O to get a no answer yet for icmp_seq=3 line instead.
• ttl=57 is the time-to-live left in the reply when it arrived; see what TTL tells you.
• time=4.21 ms is the round trip: there, the reply, and back. Halving it is only a rough one-way figure, because the two directions can take different routes.
• rtt min/avg/max/mdev: minimum, average, maximum and mdev, the standard deviation. The single 15.8 ms reply pulls the average to 7.3 ms while the minimum stays at 4.2 ms. Read min as what the path can do and mdev as how steady it is; a high mdev is what makes calls and remote desktops feel uneven.

On Windows the same four replies would read like this, in whole milliseconds and with 32 bytes of payload by default:

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=4ms TTL=57
Reply from 1.1.1.1: bytes=32 time=5ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57
Reply from 1.1.1.1: bytes=32 time=4ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 16ms, Average = 7ms

What the TTL value tells you

Every router on the way lowers a packet’s TTL by one. The reply starts with the default of the system that sends it, so the value you see is that default minus the routers on the way back. Common starting values are 64 on Linux and macOS (Linux keeps it in net.ipv4.ip_default_ttl), 128 on Windows (Microsoft documents DefaultTTL as 128) and often 255 on routers and other network gear. The ttl=57 above most likely started at 64: seven routers, which fits the seven routers in the mtr trace further down.

Do not lean on it harder than that. TTL counts the return path only, which can differ from the way there; any admin can change the default; and behind anycast, a CDN or a load balancer the reply may come from a different box than the one you meant. A TTL near 128 suggests Windows, nothing more.

Why ping fails while the website works

Ping uses ICMP, a protocol of its own. A firewall can drop ICMP echo requests and still let TCP through on ports 80, 443 or 22, and then you get this while the site loads fine:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3056ms

That run came from a host whose network filters ICMP, against the same address that answered above. So test the port you care about before you decide a server is down:

nc -zv -w 5 SERVER_IP 443

Test-NetConnection SERVER_IP -Port 443

Replace SERVER_IP with the server’s address and 443 with the port of the service. The open port checker runs the same TCP test from our server in Amsterdam, which tells you whether the port answers from the internet and not only from your own network. Who usually drops the ping:

• Windows Server. Its firewall blocks unsolicited inbound traffic by default, and the built-in echo-request rules are not enabled on a fresh install. Microsoft’s image-preparation guide for Azure has a step that switches one on so the VM answers ping inside its virtual network.
• A cloud or provider firewall in front of the server, or a home router, which drops pings from the internet by default.
• A hand-written nftables or iptables policy that drops everything not explicitly allowed. ufw is not the usual culprit: its default rules in /etc/ufw/before.rules and before6.rules accept echo requests even when incoming traffic is set to deny.

Allow ping on Windows Server

This adds an inbound rule for ICMPv4 echo requests (type 8) and nothing else. Run it in PowerShell as Administrator, for example in a Remote Desktop session:

New-NetFirewallRule -DisplayName "Allow ICMPv4 echo request" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow

For IPv6 the same command with -Protocol ICMPv6 -IcmpType 128 does the job. To answer only your own address, add -RemoteAddress YOUR_IP. Microsoft’s guide uses the built-in rule instead, Set-NetFirewallRule -Name FPS-ICMP4-ERQ-In -Enabled True; built-in rules can be tied to certain profiles or to the local subnet, so if pings still fail after enabling it, look at its Scope tab in wf.msc, or use the explicit rule above. Adding an allow rule cannot lock you out of RDP. Rules for TCP and UDP ports work the same way; see how to open a port in Windows Firewall.

Stop a Linux server answering ping

If you want the opposite, change ACCEPT to DROP at the end of the line -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT in /etc/ufw/before.rules (for IPv6, the ufw6-before-input echo-request line in before6.rules), then run sudo ufw reload while your SSH session stays open. If the reload reports an error, put the line back before you log out. Drop the echo requests only, never ICMP as a whole: path MTU discovery depends on “fragmentation needed” messages in IPv4 and on “packet too big” in IPv6, and IPv6 even finds its neighbours over ICMPv6. Without them, large transfers stall while small requests still work. RFC 4890, the guide to ICMPv6 filtering, puts “packet too big” on its must-not-drop list and IPv6 echo requests there too, so hiding from ping is mostly an IPv4 habit. The rest of the ufw setup is in UFW firewall setup.

Request timed out, Destination host unreachable and other messages

Two traps hide in that table. Windows counts a Destination host unreachable line as a reply, so the summary can read Lost = 0 (0% loss) although nothing reached the target; read the lines, not the summary. And an unknown host is a DNS problem, not a network one: if ping 1.1.1.1 works and ping example.com does not, the resolver is the problem: on Linux work through Temporary failure in name resolution, on Windows check which DNS servers the adapter uses with ipconfig /all.

To find where a connection breaks, ping in steps: your router or default gateway first (ip route or ipconfig shows its address), then 1.1.1.1, then a name. The first step that fails points at your own network, the route out of it or DNS, unless that network simply filters ICMP, as in the run above.

Continuous ping (ping -t) with timestamps

ping -t SERVER_IP on Windows and plain ping SERVER_IP on Linux run until you stop them, and so does plain ping on macOS. Ctrl+C ends the run and prints the summary. To see the figures so far without stopping, press Ctrl+Break on Windows, Ctrl+\ on Linux or Ctrl+T on macOS. For an outage that comes and goes, log every line with the time:

ping -O SERVER_IP | while read -r line; do printf '%s %s\n' "$(date '+%F %T')" "$line"; done | tee -a ping.log

ping.exe -t SERVER_IP | ForEach-Object { "{0} {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $_ } | Tee-Object -FilePath ping.log -Append

-O makes Linux write a line for every missing reply, so drops show up in the log with their time. ping -D adds a Unix timestamp to each line instead, if you prefer to process the log with a script. Both commands append to ping.log in the current folder.

When ping is not enough: traceroute and mtr

ping tells you whether and how fast, not where. mtr combines traceroute and ping: it sends probes with rising TTL values, so every router on the path answers in turn, and keeps statistics per hop.

mtr -r -w -b -c 10 SERVER_IP

-r prints a report instead of the live screen, -w makes it wide enough for long host names, -b shows names and IPs, -c 10 sends ten probes per hop. Install it with sudo apt install mtr-tiny. Here is a run from our looking glass to 1.1.1.1, which sends five probes per hop; the first two hops, right next to our test server, are replaced with documentation addresses:

HOST: vps                                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 198.51.100.1                                                      0.0%     5    5.7  12.6   0.7  40.5  16.4
  2.|-- 203.0.113.1                                                       0.0%     5    0.6   6.7   0.4  13.6   6.5
  3.|-- 195.219.89.16                                                     0.0%     5   11.2   5.4   3.6  11.2   3.3
  4.|-- if-bundle-3-2.qcore1.ad1-amsterdam.as6453.net (195.219.150.167)   0.0%     5    5.1   4.7   4.1   5.2   0.5
  5.|-- if-bundle-51-2.qcore1.av2-amsterdam.as6453.net (195.219.150.159) 60.0%     5    3.9   5.4   3.9   7.0   2.2
  6.|-- 141.101.65.184                                                    0.0%     5    4.0   8.0   3.8  20.4   7.1
  7.|-- 141.101.65.211                                                    0.0%     5    4.5   8.4   4.2  15.5   5.3
  8.|-- one.one.one.one (1.1.1.1)                                         0.0%     5    9.2   9.9   4.3  24.2   8.3

Hop 5 shows 60% loss, yet every hop after it shows none. That router rate-limits the replies it sends about itself while forwarding traffic normally, so it is not a problem. Real loss starts at one hop and carries on to the last line. The same goes for a high Wrst on a single router: what counts is the destination row.

When ICMP is filtered on the way, probe with TCP to a port the server answers: sudo mtr -T -P 443 -r -c 10 SERVER_IP. On Windows, tracert shows the path and pathping adds per-hop loss after a measuring phase: by default 100 pings per hop, 25 seconds per hop, so a 10-hop path takes about four minutes.

Ping your server from outside

Testing from your own computer only shows the path from your network. The free tools on this site give you a second vantage point:

• The looking glass runs ping, traceroute and MTR from our Amsterdam network to any public address, such as your server, which shows whether it answers from another network.
• The ping test measures the round trip from your browser to Amsterdam. Browsers cannot send ICMP, so it times 25 small HTTPS requests and reports the minimum, median, 90th percentile and jitter; it also sends a real ICMP ping from Amsterdam back to your address.

What is a good ping time?

Distance sets the floor. Light in optical fibre covers roughly 200 km per millisecond, so a server 1,000 km away cannot answer in much under 10 ms, and real cable routes are longer than a straight line. Wi-Fi and mobile networks add their own delay and jitter on top. For a shell or a remote desktop, steadiness (a low mdev, no loss) matters more than the last few milliseconds; why latency and bandwidth are different problems is in bandwidth vs latency.

So the best thing you can do for ping is to put the server near its users. For Europe, the trade-offs between a VPS in Amsterdam and one in Frankfurt are compared in Frankfurt vs Amsterdam. The ping test shows what your own connection gets to Amsterdam before you order.

Frequently asked