Run MTR on Linux, macOS and Windows, select the right destination and protocol, collect a useful sample and interpret hops without false network attribution.
Updated 7/30/20264 min read
Install MTR from your operating system repository and target the affected IP or hostname. Report mode produces output that is easy to attach to a support case.
mtr -4 -rwzc 100 destination.exampleRelated guide: Argentina VPS latency: how to measure it
Loss% reports missing MTR probe responses; Avg, Best, Wrst and StDev summarize latency. Routers may rate-limit ICMP to themselves while forwarding traffic normally.
| Read columns without jumping to conclusions | What it indicates | What it does not prove alone |
|---|---|---|
| Loss% | Unanswered probes at that hop | End-to-end loss when later hops are healthy |
| Avg/Wrst | Average and worst observed latency | Permanent congestion from a short sample |
| StDev | Variation in responses | Application jitter without its protocol |
Attach the report, IPs, timestamp, symptom and an application test. Loss or latency beginning at one point and persisting through every later hop including the destination is stronger evidence.
One hundred cycles is a useful starting sample, while intermittent faults may need longer. Always record duration and timing.
No. MTR observes route and probe responses; a PCAP records packets from a specific flow. They answer different questions.