MTR – Complete Guide to My Traceroute, Packet Loss and Latency per Hop

Packet loss that comes and goes is one of the hardest network problems to pin down. A single traceroute shows the path but sends only three probes per hop, and a ping shows loss to the destination but not where it starts. MTR combines both: it discovers the route and then keeps probing every hop, so you get loss and latency statistics for each router along the way.

The NetTools.tech MTR runs that measurement from our server and turns the raw probes into a report with findings, a sortable hop table, charts and exports. It is meant for the outside view: how a server or service is reached from the internet, independent of your own connection.

What is MTR?

In simple terms

MTR (originally "Matt's traceroute", now usually read as "My Traceroute") is a traceroute that does not stop. It finds each router on the way to a destination and then sends probes to all of them, round after round. For every hop it counts how many probes came back and how fast. Looking down the list shows where delay or loss begins and whether it carries on to the destination.

Technical background

MTR uses the same TTL mechanism as traceroute. A probe with TTL n expires at the n-th router, which answers with an ICMP Time Exceeded message (RFC 792). The destination itself answers with an Echo Reply (ICMP probes), Port Unreachable (UDP probes) or a SYN-ACK or reset (TCP probes).

What MTR adds is repetition and statistics. Per hop it tracks:

• Sent / received and from that loss %.
• Last, average, best (min) and worst (max) round-trip time.
• Standard deviation of the round-trip times, the classic StDev column.

Two router behaviors dominate interpretation:

1. Control-plane rate limiting. Routers forward packets in hardware but generate ICMP replies in software, often with a rate limit (ICMP rate limiting, control-plane policing). A router can therefore "lose" probes addressed to it while forwarding all traffic. This shows up as loss at one hop that does not continue to the next.
2. Slow replies. For the same reason, the reply from a router can be slow while transit traffic is not delayed. Latency that rises at one hop and falls again afterwards is the router, not the path.

Real problems are the patterns that carry forward: loss or added latency that starts at a hop and is present at every later hop, including the destination.

The protocol matters because networks treat ICMP, UDP and TCP differently. A firewall may drop ICMP and UDP but pass TCP to port 443, and load balancers may hash different protocols onto different links.

Why use MTR?

• Intermittent packet loss. Repeated probes reveal loss that a single traceroute misses.
• Separating noise from real problems. The per-hop view shows whether loss continues to the destination or only affects one router's replies.
• Latency steps. It shows where round-trip time increases and whether that increase persists, which is how long-distance links and congested segments look.
• Firewall-friendly testing. TCP mode reaches destinations that ignore ICMP and UDP.
• Evidence for providers. Providers routinely ask for MTR output; the text and CSV exports are ready to attach.

Who should use it?

• Network engineers analyzing loss, latency and routing changes.
• System administrators and hosting teams checking how their servers are reached from outside.
• SRE and DevOps teams investigating timeouts between regions or to third-party APIs.
• Support engineers who need a neutral measurement to compare with a customer's own MTR or WinMTR.

How MTR works

On NetTools.tech, a test goes through these steps:

1. Form validation in the browser. The target is cleaned (scheme, path, brackets and trailing dot are removed) and must be a hostname or public IP address. Probes per hop, interval, maximum hops and packet size are checked against their limits, and probes × interval must not exceed 120 seconds.
2. Validation again on the server. The server applies the same rules; nothing from the browser is trusted.
3. Resolution and address check. The hostname is resolved on the server, and the request is refused if any resolved address is private, loopback, link-local or reserved. IPv6 targets are refused because the probe server has no IPv6 connectivity yet.
4. Fixed binary, no shell. The server runs the mtr binary by absolute path with an argument array built from the validated values, roughly:

mtr --raw --no-dns -c 10 -i 1 -m 30 -s 64 -T -P 443 -- 203.0.113.10

-u is added for UDP and -T -P <port> for TCP; ICMP is the default. The process gets a hard time limit derived from the configuration, capped at 140 seconds.

5. Parsing and trimming. The raw output is converted into individual probes per hop. Hops after the first one where the destination answered are dropped.
6. Masking. Any responder address that is not public is replaced with (private address) — typically routers inside our hosting network.
7. Lookups. For up to 60 distinct public addresses, the server optionally looks up reverse DNS names and the originating network (ASN and AS name, from an IP-to-ASN DNS service).
8. Analysis in the browser. All statistics, findings, charts and exports are computed from the raw probes, so the table, the findings and the exports always agree.

Limits: at most 6 MTR tests per target address per 10 minutes across all users, per-client request limits, and no more than 4 probe processes on the server at a time. Results arrive when the test finishes; there is no streaming of partial rounds.

How to use the NetTools.tech MTR

1. Open MTR.
2. Enter the Target: a hostname or public IP address, such as example.com. You can also open /mtr?target=example.com, which prefills the field without starting a test.
3. Choose the Protocol: ICMP (default), UDP or TCP. For TCP, set TCP port (default 443).
4. Set Probes per hop (1–60, default 10), Interval in seconds (1–10, default 1) and Maximum hops (1–30, default 30). The estimated duration is shown below the fields.
5. Optionally open Advanced options: Packet size in bytes including headers (48–1500, default 64; larger packets can help reveal MTU problems), Address family (Automatic or IPv4 only; IPv6 only is shown but disabled until the probe server has IPv6) and the lookups Resolve hostnames (reverse DNS) and Look up network (ASN). Restore defaults resets everything.
6. Select Start. A progress bar shows the expected duration. Stop cancels the request; Reset clears the report.
7. When the report appears, use the filters (All hops, Highlighted, With loss, No reply) and the search box, click a hop number to see every probe, and export with CSV, JSON, Copy summary or Print.

To learn the report layout without sending probes, use Preview with sample data and choose a scenario. Sample reports are clearly labelled, use documentation addresses and are not measurements.

Understanding the results

The report starts with summary metrics, then findings, the hop table and charts.

The findings use fixed rules: a latency step is highlighted when the fastest reply rises by at least 30 ms and by at least half of the previous hop's value; variation is flagged when the standard deviation is at least 20 ms and at least a quarter of the average, with at least 3 replies. A hop that answers from two addresses with one switch is reported as a possible route change; more alternation is reported as load balancing. With fewer than 5 rounds, the report reminds you that one lost probe is a large percentage.

Example: loss that does not matter, and loss that does

The following tables are illustrative, using documentation addresses.

Case 1 — rate-limited router. ICMP, 20 probes:

Hop 4 drops almost half the probes and is slow, but hops 5 and 6 are clean. The report lists this as "Loss at intermediate hops only" (Info): hop 4 limits its own replies; traffic through it is fine.

Case 2 — loss continuing to the destination. TCP port 443, 30 probes:

Loss starts at hop 6 and every later hop, including the destination, shows it, together with large variation. The report raises "Loss continues to the destination" as a Warning. That is consistent with congestion or a fault at or after hop 6 — worth reporting to the network that owns 203.0.113.33, ideally with the CSV export and a test in the reverse direction.

Common use cases

• Investigating intermittent timeouts to a server or API from outside your network.
• Checking whether loss reported by customers is visible from a neutral location.
• Comparing ICMP and TCP results to see whether a firewall treats protocols differently.
• Testing with larger packets when you suspect MTU or fragmentation problems.
• Producing a provider-ready report (text, CSV or JSON) before opening a ticket.

Troubleshooting

Destination "Not reached" with ICMP

Many hosts and firewalls drop ICMP. Run again with TCP and the port the service listens on, typically 443 for HTTPS. If TCP reaches the destination, the earlier result was filtering, not a fault.

All hops show "Recv 0" after a certain point

If the last hops never answer and the hop count equals your maximum, the path may be longer than the limit. Raise Maximum hops to 30. Otherwise the probes are filtered from that point, which TCP mode often avoids.

"This test would take N s; the maximum is 120 s"

Probes per hop multiplied by the interval exceeds 120 seconds. Reduce the probes or the interval, for example 60 probes at 2 seconds.

Test stopped and nothing is shown

Stopping cancels the request. The server returns measurements only when a test finishes, so there are no partial results. Use fewer probes if you need a quicker answer.

"IPv6 targets cannot be tested"

The probe server has no IPv6 connectivity yet. Use the IPv4 address or a hostname with an A record and keep Address family on Automatic or IPv4 only.

"This target has been tested many times"

Each target address can be tested 6 times per 10 minutes across all users. Wait a few minutes.

Common mistakes

• Reporting loss at a single intermediate hop as an outage. Check the destination first.
• Reading high latency at one router as delay for traffic. Only latency that persists at later hops counts.
• Running only 3 or 5 probes. One lost probe out of five is 20%; use at least 10, preferably more for intermittent issues.
• Giving up after an ICMP test fails. Try TCP to the real service port.
• Comparing our route with your own MTR as if they were the same path. They start in different networks.

Limitations

• Measured from the NetTools server in Latvia, not from your device. Your own route to the destination is different.
• Only the forward path is visible. Replies can return over another 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 test of at most 120 seconds is a snapshot. Intermittent problems may need repeated tests at different times.
• IPv4 only for now; IPv6 targets are refused and the IPv6 only option is disabled.
• Names and networks come from reverse DNS and IP-to-ASN data. They describe who holds an address, not exactly where a router is. The location column is not populated.
• Hops inside our own hosting network are masked as (private address).

Security & privacy

• What is sent: the target and the test settings. Probes come from the NetTools server; the routers and the target see our address, not yours.
• Scope: private, loopback, link-local and reserved addresses are refused, and hostnames are re-checked after resolution on the server.
• Controlled execution: no shell, no user-supplied command-line options; probe count, interval, hop limit and packet size are capped.
• Rate limits: per-client, per-target and global limits.
• Exports stay with you: CSV, JSON, summary text and print output are generated in your browser.
• What not to enter: nothing sensitive is required; do not test networks you are not allowed to probe.

Related tools

• Traceroute — a quick single pass over the path. Guide: Traceroute guide.
• Ping — reachability and RTT to the destination only. Guide: Ping guide.
• Network Jitter Test — longer stability test, from your browser or our server. Guide: jitter test guide.
• ASN Lookup — details on a network seen in the path. Guide: ASN lookup guide.
• IP Lookup — registry and routing data for a single hop address. Guide: IP lookup guide.
• Category overview: Network diagnostics guide.

Summary

MTR repeatedly probes every hop on a route and reports loss, latency and variation per hop. The NetTools.tech MTR runs ICMP, UDP or TCP tests of up to 120 seconds from our server in Latvia, masks internal hops, adds names and ASNs, and separates what was observed from what it might mean. Judge the result by the destination and by patterns that carry forward, not by individual noisy routers.