MTR
AvailableRun MTR (My Traceroute) from our servers: repeated probes to every hop on the route, with packet loss, latency and jitter per router.
Test configuration
Ready to startMTR report
No results yet
Results appear here: a summary, findings, the hop-by-hop table and charts.
- Destination
- Status
- Avg latency
- to destination
- Min / Max
- milliseconds
- Packet loss
- at destination
- Hops
- Probes
Findings
Observed measurements are separated from possible explanations. Highlights mark patterns worth a look; they do not prove a fault.
Hop-by-hop results
Latency in milliseconds. * means the hop did not reply. Select a hop number to see every probe.
No hops match.
Visualizations
Limitations
- Measured from the NetTools server, not from your device. Your own route to the destination is different.
- Only the forward path is visible. Replies can return over a different route, which affects the latency shown for every hop.
- Routers answer probes with low priority and may rate-limit them, so loss or delay at a single hop is often not real traffic loss.
- A short test is a snapshot. Intermittent problems may need longer or repeated tests at different times.
- Network names and locations come from reverse DNS and registry data. They describe who holds an address, not exactly where a router is.
How it works
MTR discovers the route like traceroute, by sending probes with increasing TTL values, and then keeps probing every hop at a fixed interval. Each hop gets its own statistics: how many probes it answered (packet loss) and how long the answers took (latency and variation). Comparing hops along the route shows where loss or delay begins and whether it carries on to the destination.
Reading an MTR report
- Look at the destination first. If the last line shows no loss and steady latency, the path works, whatever the hops in between show.
- Loss that continues matters. Loss that starts at one hop and carries through every later hop to the destination affects real traffic.
- Loss at a single hop usually doesn’t. Routers rate-limit replies to probes (ICMP rate limiting, control-plane policing). If later hops answer normally, traffic passes through that router without loss.
- Latency steps that carry forward usually come from distance, like an ocean crossing, or a slow or busy link. A single slow hop followed by faster ones is the router answering slowly, not a delay for traffic.
- Asterisks (*) are hops that never reply. They are common and harmless when later hops respond.
- The return path is invisible. Replies may come back over a different route, which affects every hop’s numbers.
Safeguards & responsible use
- Server-side input validation: only syntactically valid hostnames and IP addresses are accepted.
- Private, loopback, link-local and reserved address ranges are blocked to protect internal infrastructure.
- Per-client rate limiting and request timeouts.
- Hostnames are resolved on the server and the resulting address is checked again, so a name cannot point a test at an internal network.
- Probe count, interval, hop limit and packet size are capped; one test runs at most 120 seconds.
- Tests run as a controlled server-side measurement: no shell, no user-supplied options passed to a command line.
Frequently asked questions
What is the difference between MTR and traceroute?
Traceroute probes each hop a few times once. MTR keeps probing every hop repeatedly, so it shows packet loss and latency variation per hop over time, which makes intermittent problems visible.
A hop shows 50% packet loss. Is that router broken?
Usually not. Routers limit how fast they answer probes addressed to themselves (ICMP rate limiting) while still forwarding traffic normally. If the hops after it show no loss, there is no end-to-end loss. Loss that starts at a hop and continues all the way to the destination is the pattern that matters.
Why does one hop have higher latency than the hops after it?
Answering probes is low priority for a router, so its own replies can be slow even when traffic passes through quickly. Only latency that carries forward to later hops affects the connection.
Which protocol should I use?
ICMP is the classic default. If the destination or a firewall filters ICMP, try TCP to a port the host serves (for example 443 for websites). It follows the path real application traffic takes. UDP behaves like Unix traceroute.
Why does the route look different from my own MTR?
The test runs from the NetTools server, so it follows that network’s route. To diagnose your own connection, run mtr or WinMTR on your device and compare.