---
title: Packet loss at one hop: is it a problem? How to run a traceroute online with Traceroute
description: Someone sends you a traceroute with a red 33% next to one router and asks why your network is dropping packets. To run a traceroute online and read it correctly, trace the path from a server outside your network and look at what happens at the destination, not at one hop in the middle. Here's how with the free Traceroute tool, how to read loss and latency per hop, and the mtr command that confirms it.
canonical: https://watchfor.io/blog/how-to-run-a-traceroute-online
---

# Packet loss at one hop: is it a problem? How to run a traceroute online with Traceroute

2026-10-04 · WatchFor Team · Guides · guides, networking, performance

Someone sends you a traceroute with a red 33% next to one router and asks why your network is dropping packets. To run a traceroute online and read it correctly, trace the path from a server outside your network and look at what happens at the destination, not at one hop in the middle. Here's how with the free Traceroute tool, how to read loss and latency per hop, and the mtr command that confirms it.

To run a traceroute online, enter a host in a web-based traceroute and it
traces the route from a server on the internet to that host, listing every
router on the way with its loss and round-trip time. Read it from the end:
if the last hop, the destination, shows no loss and a normal time, the path
works. Loss or a gap at one hop in the middle, with clean hops after it, is
a router that deprioritises answering traceroute probes, not lost traffic.

The free [Traceroute](/traceroute-online) runs an MTR-style trace from a
WatchFor location: three probes per hop by default, loss and average time
for each hop, and a bar that shows where the latency builds up. No signup.

## What this tool answers

*Which way do packets go to this host, and where do the delay and the loss
start?* Reach for it when a site is slow from one place but not another,
when ping shows loss and you want to know where it starts, when a customer
sends you their traceroute and you want one from a neutral vantage point, or
after a provider changes routing and you want to see the new path.

## A real example

### Running a traceroute online to find where latency and loss start

A common message to any hosting support desk: a screenshot of a traceroute
with one hop in red and the question "why is your network losing a third of
my packets?" We reproduced exactly that picture with a public target.

In [Traceroute](/traceroute-online) we entered `wikipedia.org` and kept the
default of 3 pings per hop. Logged out, it runs from the location nearest
the visitor, Vilnius for us:

![The Traceroute result for wikipedia.org: REACHED, 10 of 11 hops answered, 0% loss at the destination, 29 ms destination round trip; hops from _gateway at 0.2 ms through telecom.lt and twelve99.net routers in Warsaw, Hamburg and Amsterdam to text-lb.esams.wikimedia.org at 29.3 ms, with 33% loss at the Hamburg hop and hop 10 shown as ??? with 100% loss](/blog/how-to-run-a-traceroute-online-result.webp)

The trace took 8.8 seconds and reached the destination in 11 hops. Reading
it from the end:

- **Hop 11, the destination** `text-lb.esams.wikimedia.org`, Wikimedia's
  Amsterdam load balancer: **0% loss, 29.3 ms**. The traffic that matters
  arrived, all of it.
- **Hop 6** `hbg-bb3-link.ip.twelve99.net` (Arelion's backbone in Hamburg):
  **33% loss**, one of three probes unanswered. But hops 7 to 11 lost
  nothing. If hop 6 really dropped a third of the traffic passing through
  it, every hop after it would show at least that much loss. It doesn't.
  The router forwarded all three probes and simply didn't bother to *reply*
  to one: routers answer traceroute in their control plane, at low priority
  and with rate limits.
- **Hop 10**, no reply (`mtr` writes it as `???`): a router that never
  answers traceroute probes at all. The destination after it is fine, so it forwards traffic
  normally.
- **Latency:** 0.2 ms at the probe's own gateway, 8.0 ms at Warsaw, 21.4 ms
  at Hamburg, about 27.5 ms in Amsterdam, 29.3 ms at the destination. The
  big step is the long-haul leg to Hamburg; after Amsterdam the time hardly
  changes, so nothing near Wikipedia adds delay.

The first hops (`_gateway`, a `zebra.lt` address, `198.18.255.1`,
`telecom.lt`) are the probe location's own network and its upstream in
Lithuania. `198.18.0.0/15` is a block reserved for benchmarking (RFC 2544),
which some networks use on internal links, so a hop there is not a leak or a
misconfiguration.

**The answer:** no problem. The path is clean end to end; the red 33% is a
busy backbone router declining to answer one probe. When you get such a
screenshot, ask for the destination row. Real loss starts at one hop and
continues **all the way to the last line**.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Dest RTT (hero)** | Average round trip to the final hop. Green under 50 ms, amber under 200 ms, red above. |
| **REACHED / INCOMPLETE** | Whether the destination itself answered. Incomplete means the trace stopped before it, often a firewall in front of the host that drops traceroute probes. |
| **10 / 11 hops** | Hops that answered out of the total path length. Silent hops are common and usually harmless. |
| **% loss** (header) | Loss at the destination: the number that reflects what your traffic experiences. |
| **# and Host** | Hop number and the router's reverse DNS name, or its IP without one. Names often encode the city (`war`, `hbg`, `adm` here) and the operator. |
| **Loss** (per hop) | Share of that hop's probes without a reply. Only meaningful if it continues on the hops after it. |
| **Avg** | Average round trip to that hop. A jump that persists on every later hop marks where delay is added; a spike on one hop alone is that router answering slowly. |
| **Bar** | The hop's time relative to the slowest hop, so the step where latency grows stands out. |
| **No reply** (`???`) | A hop that answered none of its probes, so there is no loss or time to show. Ignore it if the trace continues after it. |

## More ways to use it

- **Slow from one region.** Compare a trace from a nearby location with the
  customer's own `mtr` or `tracert`. If the paths diverge at one network,
  that's where to look, and who to talk to.
- **Before and after a provider change.** Save the path today; after the
  change, run it again and compare the networks and the destination time.
- **Real loss.** If loss starts at hop *N* and stays to the end, the problem
  is at that hop or the link into it. Send the trace, with times, to the
  operator named in the hostname, or to your host if it's their network.
- **A host that won't answer.** If the trace stops early, ping and the
  [port checker](/port-checker) tell you whether the host is down or just
  filters traceroute.
- **Basic latency first.** If you only need reachability and round trip, the
  [ping test](/ping-test) is faster; the
  [ping guide](/blog/how-to-ping-a-server-online) shows how to compare it
  with your own connection.

## Tips and gotchas

- **Only the destination's loss counts.** Middle-hop loss that doesn't carry
  on to the end is ICMP rate limiting. It's the most common misreading of
  traceroutes.
- **The return path is invisible.** Traceroute shows the way *there*.
  Replies can come back by a different route, so a slow hop may be slow on
  its return path, which you can't see from this side.
- **Times aren't additive.** Each row is a separate round trip to that
  router, not the time "spent" at it. A hop slower than the next one is just
  slow at answering.
- **Few probes, coarse percentages.** With 3 probes, one lost reply shows as
  33%. Raise **Pings / hop** (up to 10) for a finer picture.
- **One location, IPv4.** Logged out, the trace runs from the location
  nearest you, over ICMP and IPv4. Paths from other continents are entirely
  different.
- **Hostnames come from reverse DNS.** They're labels set by the operator,
  usually accurate but not guaranteed.

## Check it from the command line too

`mtr` combines traceroute and ping; `-r` prints a report, `-w` uses wide
names, `-c 10` sends 10 probes per hop. From our office to the same target,
with the first three hops (our router and ISP) trimmed:

```bash
mtr -rwc 10 wikipedia.org | tail -8
```

```text
  4.|-- war-b4-link.ip.twelve99.net              10.0%    10    8.8  20.6   8.3  52.5  15.0
  5.|-- war-b8-link.ip.twelve99.net               0.0%    10    9.3  16.9   7.7  32.1   9.7
  6.|-- hbg-bb2-link.ip.twelve99.net              0.0%    10   21.3  21.8  19.9  35.3   4.8
  7.|-- adm-bb2-link.ip.twelve99.net             10.0%    10   27.0  27.3  26.8  29.7   0.9
  8.|-- adm-b3-link.ip.twelve99.net               0.0%    10   27.4  27.2  27.1  27.4   0.1
  9.|-- wikimedia-ic-381309.ip.twelve99-cust.net  0.0%    10   27.1  28.2  26.8  30.9   1.7
 10.|-- ???                                      100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- text-lb.esams.wikimedia.org               0.0%    10   28.4  31.5  28.3  44.1   6.5
```

The columns are loss, sent, last, average, best, worst and standard
deviation. The same pattern: Warsaw, Hamburg and Amsterdam on Arelion's
backbone, a silent hop 10, scattered 10% "loss" at hops 4 and 7 that
vanishes on the next hop, and 0% at the destination. On Windows, `tracert
wikipedia.org` lists the hops and `pathping wikipedia.org` adds per-hop loss
after a few minutes of sampling.

## Keep watching it

Routing problems come and go; a trace taken after the complaint often looks
clean. An [MTR monitor](/mtr-monitoring) traces the path to your host on a
schedule from several locations and keeps a path history you can replay hop
by hop. Its **Destination Unreachable** rule is on by default, and you can
add **Destination Packet Loss**, **Destination RTT** or **Loss At Any Hop**
thresholds. Because traces are slow, confirmation re-checks run every 2
minutes for up to 10 minutes before an incident opens.

## FAQ

**What does `* * *` or `???` mean in a traceroute?**
That hop didn't reply within the timeout. Many routers don't answer
traceroute probes, or rate-limit them. If later hops and the destination
answer, ignore it.

**Why does traceroute show packet loss at one hop but not the destination?**
That router deprioritises or rate-limits its own ICMP replies while still
forwarding traffic. Real loss appears at a hop and every hop after it.
[What is packet loss?](/blog/what-is-packet-loss) explains more.

**What is the difference between traceroute and MTR?**
Traceroute walks the path once; MTR repeats it and keeps per-hop loss and
latency statistics, which makes intermittent problems visible.
[Ping, traceroute and MTR](/blog/ping-traceroute-mtr) compares all three.

---

Canonical page: https://watchfor.io/blog/how-to-run-a-traceroute-online · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt