routing.pl

Why will a website not load? Ping and traceroute step by step

15.04.20266 min readServer-side diagnostics

How to read ping and traceroute output, what asterisks and latency spikes mean, and how to tell whether the problem is on your side, at your provider or at the server.

A website will not load, a game lags, a VPN keeps dropping. Before you call your provider or start restarting the server, it is worth finding out where the traffic stops. Two old, simple tools do exactly that: ping and traceroute. You just need to know how to read them, because half of the “alarming” symptoms are completely harmless.

Check DNS first

If the browser shows an error such as DNS_PROBE_FINISHED_NXDOMAIN or “server IP address could not be found”, the problem is not the network but the name. Look the domain up in DNS lookup: if there is no A or AAAA record, or it points to an old server, ping and traceroute will not help. More on records in Basic DNS records.

Ping: does the host answer at all

Ping sends ICMP Echo packets and measures how long the reply takes. Look at two things:

  • time (time=): within one country it is usually a few to a dozen or so milliseconds, across Europe 20–40 ms, from Europe to the US around 100–150 ms,
  • loss (packet loss): a few per cent of loss on a wired connection is already a problem you will notice in games and video calls.

Note: no reply to ping does not mean the host is down. Many servers and firewalls block ICMP. If the website opens in a browser and ping stays silent, everything is fine.

How traceroute works

Every IP packet has a TTL field (in IPv6: hop limit) that each router on the way decreases by one. When it reaches zero, the router drops the packet and sends back a “time exceeded” message. Traceroute uses this on purpose: it sends packets with TTL 1, 2, 3 and so on, and builds a list of routers on the way to the target from the replies. It usually sends three probes per hop, hence three times on each line.

 1  192.168.1.1      0.6 ms   0.5 ms   0.5 ms
 2  10.20.0.1        8.1 ms   7.9 ms   8.4 ms
 3  198.51.100.17    9.0 ms   *        9.2 ms
 4  *                *        *
 5  203.0.113.5     31.7 ms  31.2 ms  31.9 ms
 6  203.0.113.80    32.4 ms  32.0 ms  32.1 ms

Hop 1 is your router, the next ones belong to your provider and then to the networks your traffic passes through. An asterisk means no reply arrived for that probe.

How to read the output

The key rule: what matters is what happens all the way to the end of the path. Routers answer traceroute as a side job, at low priority, so a single odd hop usually means nothing.

What you see What it usually means
asterisks on one hop, normal times after it the router does not answer traceroute or rate limits replies. Harmless
asterisks from some hop all the way to the end traffic stops there, or the target (or its firewall) blocks the probes. Look at the last hop that answers
high time on one hop, low again on the following ones the router is slow to answer probes but forwards traffic normally. Harmless
a jump in time that lasts until the end of the path a long link (crossing the Atlantic adds about 70–90 ms) or congestion at that point
loss in the middle of the path but not at the target the router rate limits replies. Harmless
loss that starts at some hop and lasts until the target a real problem on that segment or just before it

Also remember that the way there and the way back are often different. Traceroute only shows the path in one direction, while the latency of each hop also includes the return path, which you cannot see.

Look from both sides

One traceroute is one point of view. Compare two:

  • from your computer: on Windows tracert example.com, on Linux and macOS traceroute example.com. Even better is mtr example.com, which repeats the measurement and shows the loss percentage on every hop,
  • from the routing.pl server: the Traceroute tool traces the path from our server to the target, so from a completely different network than yours.

How to interpret it:

  • works from the server but not from you: the problem is closer to you, in your network or at your provider,
  • the path breaks near the target from both places: the problem is on the server side, its firewall or its hosting,
  • the site fails only for you, but traceroute reaches the target: check DNS, the firewall on your computer, browser extensions, and whether the problem affects only IPv4 or only IPv6 (ping -4 and ping -6).

What to send your provider

A ticket saying “the internet does not work” goes to the end of the queue. A ticket with data usually reaches someone who can act on it. Include:

  • the output of mtr or traceroute (as text, not a screenshot),
  • the date and time when the problem occurred,
  • your public IP address (check it in What is my IP) and the target address,
  • whether the problem affects all websites or just one.
Before reporting a problem, connect your computer to the router with a cable. Weak Wi-Fi causes loss and latency spikes right at the first hop, and no provider can fix that.