When a server feels slow or unreachable, three tools answer the first questions: Is it reachable? How long do packets take? Where along the path do things go wrong? ping measures, traceroute maps the path, and mtr does both continuously.

ping: reachability and latency

ping -c 10 203.0.113.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=168 ms
…
--- 203.0.113.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 166.912/168.405/171.220/1.193 ms
  • time — round-trip time (RTT) in milliseconds.
  • packet loss — sustained loss above ~1% hurts TCP performance noticeably.
  • mdev — variation (jitter). Low jitter matters for VoIP, games and trading.

Useful options:

ping -c 100 -i 0.2 host     # 100 pings, 5 per second (intervals under 0.2 s need root)
ping -4 host / ping -6 host # force IPv4 / IPv6
ping -s 1400 -M do host     # test path MTU: 1400-byte packets, don't fragment

On Windows: ping -n 10 host, and ping -t host to run continuously.

No reply doesn’t always mean down. Many servers and firewalls block ICMP echo. Test the actual service port instead: nc -zv host 443 or curl -I https://host.

traceroute: the path

sudo apt install traceroute
traceroute example.com
traceroute -n example.com        # numeric only, faster
sudo traceroute -T -p 443 example.com   # TCP to port 443 — gets through more firewalls

Each line is a hop (router) with three timing samples. * * * means that hop didn’t reply — very common and usually harmless; routers often deprioritise or block these probes.

Windows: tracert example.com.

mtr: traceroute + ping, continuously

mtr sends probes repeatedly and shows per-hop loss and latency statistics — far more useful than a single traceroute.

sudo apt install mtr-tiny          # or mtr
mtr example.com                    # interactive
mtr -rwzc 100 example.com          # report mode: 100 cycles, wide, with AS numbers
mtr -T -P 443 -rwc 100 example.com # TCP probes to port 443

Example report:

HOST: web1                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???  10.0.0.1                0.0%   100    0.4   0.5   0.3   1.2   0.1
  2. AS6939 core1.lax.example.net   0.0%   100    1.1   1.3   0.9   4.5   0.5
  3. AS4134 202.97.x.x             12.0%   100  155.2 158.1 152.0 190.3   6.2
  4. AS4134 202.97.y.y              0.0%   100  160.4 161.0 158.8 170.1   2.1
  …
  9. AS…    target                  0.0%   100  171.3 172.0 169.9 180.4   1.8

Reading mtr correctly

The most common mistake is blaming a hop that shows loss.

  • Loss at an intermediate hop that doesn’t continue to later hops (hop 3 above shows 12%, but hop 4 and the destination show 0%) — that router just rate-limits ICMP replies to itself. Not a problem.
  • Loss that starts at a hop and continues all the way to the destination — real loss, introduced at or just before that hop.
  • Latency jumps — a large step between two hops usually reflects physical distance (crossing an ocean adds 100+ ms) or congestion if it varies wildly.
  • Only the destination matters for the final verdict. If the last line shows 0% loss and stable latency, the path is fine.

Testing both directions

Routes on the internet are often asymmetric: the path from you to the server can differ from the path back. For a full picture, run mtr from your location to the server and from the server back to your IP. When reporting a network problem to a provider, include both reports with 100+ cycles.

What’s a “good” latency?

Physics sets a floor: light in fibre covers about 200 km per millisecond, so RTT is at least ~1 ms per 100 km of cable route, plus routing overhead. Typical values:

Path Typical RTT
Same city 1–5 ms
US coast to coast 60–80 ms
US West Coast ↔ Tokyo / Hong Kong 100–160 ms
Hong Kong ↔ mainland China (good routes) 10–40 ms
Europe ↔ East Asia 180–280 ms

If your users are in a region, a server in or near that region is the only way to get low latency. See choosing a VPS location and latency vs bandwidth.

Test before you buy

Our location pages list test IPs for each data center, so you can ping and mtr from where your users are before ordering — see USA, Hong Kong and Japan.

Related: packet loss troubleshooting, iperf3 bandwidth tests and network troubleshooting on Linux.

  • Networking
  • Troubleshooting
  • Latency