--- title: "How to use MTR to diagnose network problems | StreetHosting" description: "Learn to run MTR on Linux and WinMTR on Windows, read Loss, Avg, StDev and Worst, ignore false packet loss and build the right evidence for a ticket." url: "https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr" type: "page" language: "en-US" --- Infrastructure · 8 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # MTR in practice: run it, read every column and prove where the loss is MTR combines traceroute and ping and shows, hop by hop, where latency climbs and where packets get lost. The trick is knowing which loss is real and which is just a router rationing its replies. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20use%20MTR%20to%20diagnose%20network%20problems&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr "Share on LinkedIn") [](https://wa.me/?text=How%20to%20use%20MTR%20to%20diagnose%20network%20problems%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fhow-to-use-mtr "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr.md) In this guide 8 sections * [What MTR does](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#o-que-e-mtr) * [Install and run it](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#instalar-rodar) * [What each column means](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#colunas) * [How to read the report](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#como-ler) * [Run it in both directions](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#dois-sentidos) * [MTR on Windows with WinMTR](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#winmtr) * [How to build the ticket](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#chamado) * [MTR from the server side](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#onde-rodar) Quick answer To **use MTR**, run `mtr -rwzbc 100 IP_DO_DESTINO` on Linux or use WinMTR on Windows. Read the report from the bottom up: if the last hop shows 0% loss, the loss on the middle hops is just a router limiting ICMP replies. Real trouble is loss or latency that starts at one hop and continues on every hop after it, all the way to the destination. Because the return route can be different, run it in the opposite direction too. ## What MTR does[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#o-que-e-mtr) MTR discovers the route to the destination the same way traceroute does, raising the TTL one step at a time, and then keeps sending packets to every hop without stopping. On each cycle it updates, for every router on the path, how many packets were answered, plus the average, best and worst latency and the deviation. Instead of a snapshot, you get a movie of the route. That solves traceroute's biggest limitation: an intermittent problem that does not show up in the three packets it sends per hop. Traceroute is still useful for understanding the path, and how to read the names, the carriers and the segments is covered in [traceroute for finding routing problems](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute). MTR comes in when the question is how much and where the network is losing. ## Install and run it[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#instalar-rodar) On Ubuntu and Debian, the `mtr-tiny` package provides the terminal version, with no graphical interface, and it already comes installed on many server images. On a Mac, install it with Homebrew. `# Ubuntu and Debian sudo apt update && sudo apt install mtr-tiny # macOS brew install mtr # report with 100 packets per hop mtr -rwzbc 100 IP_DO_DESTINO` With no options, MTR opens an interactive screen that refreshes by itself, good for watching live. Report mode runs the requested number of cycles and prints text you can copy and attach to a ticket. Each letter in `-rwzbc` has a job: | Option | What it does | | ---------- | --------------------------------------------------- | | \-r | Report mode: runs the cycles and prints the result | | \-w | Wide report, without cutting off long router names | | \-z | Shows the autonomous system (AS) number of each hop | | \-b | Shows name and IP together | | \-c 100 | Number of packets per hop | | \-n | Does not resolve names, which makes the test faster | | \-T -P 443 | Uses TCP SYN on the given port instead of ICMP | | \-u | Uses UDP instead of ICMP | | \-4 or -6 | Forces IPv4 or IPv6 | TCP mode is useful when the destination or some router treats ICMP differently from real traffic. Pointing at the service port, as in `sudo mtr -rwzbc 100 -T -P 443 IP_DO_DESTINO`, measures the path your application traffic actually takes. ## What each column means[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#colunas) | Column | What it measures | How to read it | | ------ | ----------------------------------------------- | ---------------------------------------------------------------------- | | Loss% | Percentage of packets with no reply at that hop | Only matters if it continues to the destination | | Snt | Packets sent to the hop | Use at least 100 so the percentage means something | | Last | Latency of the last packet | Not very useful in the final report | | Avg | Average round-trip latency | Compare how it evolves from one hop to the next | | Best | Lowest latency observed | Approximates the physical limit of the route | | Wrst | Highest latency observed | Far above Avg means spikes and queuing | | StDev | Standard deviation of latency | This is jitter; if it climbs and stays high, that points to congestion | Latency, jitter and loss are different concepts, and each one points to a different cause. If you need a refresher, the guide on [ping, jitter and packet loss](https://streethosting.com.br/en/guides/infrastructure/ping-vs-jitter-vs-packet-loss) explains each one and the reference values. ## How to read the report[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#como-ler) Almost every misreading comes from looking first at the hop with the scariest number. Follow this order: 1. **Start with the last hop.** It is the destination. If loss there is 0% and latency is good, the route is healthy, no matter what shows up in the middle. 2. **Loss that does not continue is false.** Routers prioritize forwarding traffic and leave the work of answering ICMP for later. Many limit those replies per second. The hop shows 20%, 40%, even 100% loss, and the hops after it, which depend on it to receive packets, show 0%. 3. **Real loss starts at one hop and runs to the end.** If hop 7 shows 5% and every hop after it also shows around 5%, the problem is in the link that reaches hop 7, in hop 7 itself or in the return route from it. 4. **Latency follows the same rule.** A latency spike on a single hop, with the following ones normal, is a router taking its time to answer ICMP. A hop where the average rises and stays up on the following hops is real delay, whether from distance or from queuing. 5. **Not every increase is a defect.** A jump from 10 ms to 120 ms where the router name changes from a Brazilian city to Miami is the submarine cable. It is expected if the destination is abroad, and it is a problem if the destination is in Brazil. 6. **Lines with ??? are not loss.** Those are routers that never answer ICMP at all. If traffic passes through them and reaches the destination, everything is fine. Here are two illustrative reports, with documentation addresses. In the first, the loss on hop 4 is false: `HOST: notebook Loss% Snt Last Avg Best Wrst StDev 1. AS??? 192.168.0.1 0.0% 100 0.8 0.9 0.5 3.2 0.4 2. AS??? 100.72.0.1 0.0% 100 2.9 3.3 2.6 8.1 0.8 3. AS64500 bdr1.operadora.example (198.51.100.9) 0.0% 100 4.1 4.4 3.8 9.0 0.7 4. AS64500 core2.operadora.example (198.51.100.21) 42.0% 100 12.7 13.9 4.2 61.3 11.5 5. AS64501 ix.transito.example (192.0.2.33) 0.0% 100 17.2 17.6 16.9 22.4 0.9 6. AS64502 203.0.113.10 0.0% 100 17.9 18.1 17.5 23.2 0.8` Hop 4 shows 42% loss and unstable latency, but hops 5 and 6 answer 100% with deviation under 1 ms. The traffic went through hop 4 without any problem; it only answers ICMP when it has spare time. In the second report, the loss is real: `HOST: notebook Loss% Snt Last Avg Best Wrst StDev 1. AS??? 192.168.0.1 0.0% 100 0.7 0.8 0.5 2.9 0.3 2. AS??? 100.72.0.1 0.0% 100 3.0 3.2 2.7 7.5 0.6 3. AS64500 bdr1.operadora.example (198.51.100.9) 0.0% 100 4.3 4.5 3.9 8.7 0.6 4. AS64501 ix.transito.example (192.0.2.33) 6.0% 100 19.8 22.4 18.1 88.0 9.7 5. AS64501 core.transito.example (192.0.2.41) 7.0% 100 20.4 23.0 18.6 91.2 10.3 6. AS64502 203.0.113.10 6.0% 100 21.0 23.5 19.0 90.5 10.1` The loss appears on hop 4 and continues to the destination, and StDev jumps from 0.6 to nearly 10 ms at the same point. The suspect segment is the handoff from the carrier network (AS64500) to the transit network (AS64501). That is the kind of evidence support can actually use. Loss that starts at hop 1 is in your local network: Wi-Fi, cable or router. Loss that only appears at the destination, with every earlier hop clean, can mean an overloaded server or an attack saturating its link. The signs that separate an attack from a legitimate spike are in [how to identify a DDoS attack](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server). ## Run it in both directions[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#dois-sentidos) The outbound route and the return route are not necessarily the same. Each network chooses where to send the traffic leaving it, so packets can go out through one transit carrier and come back through another. The MTR you run from home measures the way out to each hop, but each hop's reply comes back along its own route. Loss that originates on the way back shows up in your report without the guilty router being listed. That is why a complete diagnosis has two reports: one from the client to the server and another from the server to the client's public IP. If you have access to the server, run `mtr -rwzbc 100 IP_PUBLICO_DO_CLIENTE` there. The client's home router may not answer ICMP, and in that case the last hop shows 100% loss; look at the previous hop, which is their carrier. To test the return path from the StreetHosting network without having a server, the [connectivity test](https://streethosting.com.br/en/tools/connectivity) measures latency from your browser to the São Paulo nodes and runs an MTR from the SP node to your public IP, limited to one test per minute per node. ## MTR on Windows with WinMTR[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#winmtr) Windows does not ship with MTR. The most widely used equivalent is WinMTR, a portable graphical program that does the same job: 1. Download WinMTR from the project's official page and extract the executable. 2. In the Host field, type the server's IP or domain. 3. Click Start and let it run until the Sent column passes 100. 4. Click Stop and use Export TEXT or Copy Text to clipboard. The columns are the same ideas under different names: Loss %, Sent, Recv, Best, Avrg, Wrst and Last. WinMTR does not show standard deviation, so compare Avrg and Wrst to spot jitter. The reading rule is the same: loss only counts if it continues to the destination. Without installing anything, Windows' own `pathping -n IP_DO_DESTINO` discovers the route and then measures each hop. It is much slower, because it collects statistics from each router for about 25 seconds, but the final result has loss per hop and per segment. ## How to build the ticket[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#chamado) Carrier and provider support teams respond much faster to well-put-together evidence. Gather this before opening the ticket: * MTR in report mode with at least 100 packets and the -b and -z options * The report in both directions, when possible * Date, time and time zone of each test * Your public IP and the destination IP * An MTR to another destination that works well, for comparison * The symptom in one sentence: what fails, since when and at what time of day * If possible, a TCP-mode test on the affected service port Run MTR while the problem is happening. A clean report taken two hours after the incident proves nothing and usually gets the ticket closed with no solution. ## MTR from the server side[](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#onde-rodar) Half of the diagnosis depends on running commands on the server: the MTR back to the player, TCP mode on the service port, the comparison with other destinations. On hosting without system access, you depend on someone running that for you. On a [StreetHosting VPS](https://streethosting.com.br/en/vps) you have root, install `mtr-tiny` and test from the São Paulo datacenter to any user whenever you want, with a 1 Gbps uplink and Anti-DDoS included. * **Measurement and monitoring point:** the R$ 26.00 [Xeon VPS](https://streethosting.com.br/en/vps/xeon), with 2 vCPU, 2 GB and 20 GB NVMe, is enough to run MTR, scheduled ping and a monitoring dashboard. * **Game server or application:** the Ryzen 9 9950X VPS goes from R$ 40.00 to R$ 846.00, and network diagnostics live on the same machine that serves your users. To turn MTR into a routine, with measurements from several origins and at different times, follow the guide on [how to test VPS latency](https://streethosting.com.br/en/guides/vps/test-vps-latency). In this guide * [What MTR does](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#o-que-e-mtr) * [Install and run it](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#instalar-rodar) * [What each column means](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#colunas) * [How to read the report](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#como-ler) * [Run it in both directions](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#dois-sentidos) * [MTR on Windows with WinMTR](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#winmtr) * [How to build the ticket](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#chamado) * [MTR from the server side](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr#onde-rodar) ## Frequently asked questions Is packet loss on a middle hop in MTR a problem? Only if the loss continues on the following hops all the way to the destination. Many routers limit how many ICMP replies they generate per second and treat those replies as low priority, so they show loss in MTR while forwarding all traffic normally. If the last hop shows 0%, you can ignore the loss in the middle. How many packets should I use in MTR? At least 100, with -c 100. With few packets, a single lost packet becomes 10% or 20% and skews the reading. For intermittent problems, run 300 or more, or leave interactive MTR open during the time of day when the problem happens. What is the difference between MTR and traceroute? Traceroute discovers the route once, with three packets per hop. MTR discovers the same route and keeps sending packets to every hop, accumulating loss, average, worst case and deviation. Traceroute shows the path; MTR shows the quality of each stretch of the path over time. How do I use MTR on Windows? Use WinMTR, a graphical version of MTR for Windows. Type the IP or domain, click Start, wait until more than 100 packets have been sent, click Stop and export the result as text. pathping, which already ships with Windows, is a slower alternative. Why does the last MTR hop show 100% loss? Usually because the destination server drops ICMP at the firewall, not because it is down. If the service works, there is no problem. To measure anyway, run MTR in TCP mode pointed at an open port, with -T and -P. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See Xeon VPS Xeon VPS for steady workloads, automation and long-running projects.](https://streethosting.com.br/en/vps/xeon) ## Related guides [Infrastructure Intermediate How to use traceroute to find routing problems Traceroute lists every router between you and the server and how long each one takes to answer. Read the right way, it shows whether the delay starts at your home, at your ISP, between networks or at the destination. 8 min Read guide](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute) [Infrastructure Beginner Ping, jitter and packet loss: the difference in practice Ping measures how long the network takes, jitter measures how much that time varies and packet loss measures what never arrives. Each one ruins the experience in a different way, and knowing which one is bad is what decides the fix. 9 min Read guide](https://streethosting.com.br/en/guides/infrastructure/ping-vs-jitter-vs-packet-loss) [VPS Beginner How to test VPS latency from Brazil Good latency is the latency your users measure, not what you see from your own computer. Learn how to test with ping, TCP and MTR, how to measure from other cities without owning a machine there, and how to compare the numbers fairly. 9 min Read guide](https://streethosting.com.br/en/guides/vps/test-vps-latency) [← Back to the Guide Center](https://streethosting.com.br/en/guides)