--- title: "Como usar MTR para diagnosticar problemas de rede" description: "Aprenda a rodar o MTR no Linux e o WinMTR no Windows, ler Loss, Avg, StDev e Worst, ignorar perda falsa e montar a prova certa para abrir chamado." url: "https://streethosting.com.br/guias/infraestrutura/usar-mtr-diagnosticar-rede" category: "infraestrutura" slug: "usar-mtr-diagnosticar-rede" datePublished: "2026-09-28" dateModified: "2026-09-28" author: "Equipe StreetHosting" difficulty: "intermediario" language: "pt-BR" keywords: - "como usar mtr" - "mtr linux comando" - "winmtr" - "interpretar resultado mtr" - "mtr perda de pacotes" --- # MTR na prática: rodar, ler cada coluna e provar onde está a perda O MTR junta traceroute e ping e mostra, salto por salto, onde a latência sobe e onde os pacotes se perdem. O segredo está em saber qual perda é real e qual é só um roteador economizando respostas. > **Resposta rápida** > > Para **usar o MTR**, rode `mtr -rwzbc 100 IP_DO_DESTINO` no Linux ou use o WinMTR no Windows. Leia o relatório de baixo para cima: se o último salto tem 0% de perda, a perda nos saltos do meio é só roteador limitando respostas ICMP. Problema real é perda ou latência que começa em um salto e continua em todos os seguintes até o destino. Como a rota de volta pode ser outra, rode também no sentido contrário. ## O que o MTR faz O MTR descobre a rota até o destino do mesmo jeito que o traceroute, aumentando o TTL de um em um, e depois fica mandando pacotes para cada salto sem parar. A cada ciclo ele atualiza, para cada roteador do caminho, quantos pacotes foram respondidos, a latência média, a melhor, a pior e o desvio. Em vez de uma fotografia, você ganha um filme da rota. Isso resolve a maior limitação do traceroute: um problema intermitente que não aparece nos três pacotes que ele manda por salto. O traceroute continua útil para entender o caminho, e a leitura dos nomes, das operadoras e dos trechos está em [traceroute para descobrir problemas de rota](https://streethosting.com.br/guias/infraestrutura/traceroute-diagnosticar-rota). O MTR entra quando a pergunta é quanto e onde a rede está perdendo. ## Instalar e rodar No Ubuntu e no Debian, o pacote `mtr-tiny` traz a versão de terminal, sem interface gráfica, e já vem instalado em muitas imagens de servidor. No Mac, instale pelo Homebrew. ``` # Ubuntu e Debian sudo apt update && sudo apt install mtr-tiny # macOS brew install mtr # relatório com 100 pacotes por salto mtr -rwzbc 100 IP_DO_DESTINO ``` Sem opções, o MTR abre uma tela interativa que se atualiza sozinha, boa para acompanhar ao vivo. O modo relatório roda a quantidade de ciclos pedida e imprime um texto que dá para copiar e anexar em chamado. Cada letra de `-rwzbc` tem uma função: | Opção | O que faz | | --- | --- | | -r | Modo relatório: roda os ciclos e imprime o resultado | | -w | Relatório largo, sem cortar nomes longos de roteadores | | -z | Mostra o número do sistema autônomo (AS) de cada salto | | -b | Mostra nome e IP juntos | | -c 100 | Quantidade de pacotes por salto | | -n | Não resolve nomes, o que deixa o teste mais rápido | | -T -P 443 | Usa TCP SYN na porta informada em vez de ICMP | | -u | Usa UDP em vez de ICMP | | -4 ou -6 | Força IPv4 ou IPv6 | O modo TCP é útil quando o destino ou algum roteador trata ICMP de forma diferente do tráfego real. Apontar para a porta do serviço, como `sudo mtr -rwzbc 100 -T -P 443 IP_DO_DESTINO`, mede o caminho que o tráfego da aplicação faz de verdade. ## O que cada coluna significa | Coluna | O que mede | Como ler | | --- | --- | --- | | Loss% | Porcentagem de pacotes sem resposta naquele salto | Só importa se continuar até o destino | | Snt | Pacotes enviados ao salto | Use pelo menos 100 para a porcentagem ter sentido | | Last | Latência do último pacote | Pouco útil no relatório final | | Avg | Latência média de ida e volta | Compare como evolui de um salto para o outro | | Best | Menor latência observada | Aproxima o limite físico da rota | | Wrst | Maior latência observada | Muito acima do Avg indica picos e fila | | StDev | Desvio padrão da latência | É o jitter; subir e continuar alto indica congestionamento | Latência, jitter e perda são conceitos diferentes e cada um aponta para uma causa diferente. Se precisar revisar, o guia de [ping, jitter e packet loss](https://streethosting.com.br/guias/infraestrutura/ping-jitter-packet-loss-diferenca) explica cada um e os valores de referência. ## Como ler o relatório Quase todo erro de leitura vem de olhar primeiro para o salto com o número mais assustador. Siga esta ordem: 1. **Comece pelo último salto.** Ele é o destino. Se a perda ali é 0% e a latência está boa, a rota está saudável, não importa o que apareça no meio. 2. **Perda que não continua é falsa.** Roteadores priorizam encaminhar tráfego e deixam para depois o trabalho de responder ICMP. Muitos limitam essas respostas por segundo. O salto aparece com 20%, 40%, até 100% de perda, e os saltos seguintes, que dependem dele para receber pacotes, mostram 0%. 3. **Perda real começa em um salto e segue até o fim.** Se o salto 7 mostra 5% e todos os seguintes também mostram por volta de 5%, o problema está no link que chega ao salto 7, no próprio salto 7 ou na rota de volta a partir dele. 4. **Latência vale pela mesma regra.** Pico de latência em um salto só, com os seguintes normais, é roteador demorando para responder ICMP. Salto em que a média sobe e se mantém nos seguintes é atraso real, seja por distância, seja por fila. 5. **Nem todo aumento é defeito.** Um salto de 10 ms para 120 ms em que o nome do roteador muda de cidade brasileira para Miami é o cabo submarino. É esperado se o destino está lá fora, e é problema se o destino está no Brasil. 6. **Linhas com ??? não são perda.** São roteadores que não respondem ICMP de jeito nenhum. Se o trânsito passa por eles e chega ao destino, está tudo certo. Veja dois relatórios ilustrativos, com endereços de documentação. No primeiro, a perda do salto 4 é falsa: ``` 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 ``` O salto 4 mostra 42% de perda e latência instável, mas os saltos 5 e 6 respondem 100% com desvio abaixo de 1 ms. O tráfego passou pelo salto 4 sem problema; ele só responde ICMP quando sobra tempo. No segundo relatório, a perda é 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 ``` A perda aparece no salto 4 e continua até o destino, e o StDev pula de 0,6 para perto de 10 ms no mesmo ponto. O trecho suspeito é a passagem da rede da operadora (AS64500) para a rede de trânsito (AS64501). É esse o tipo de evidência que o suporte consegue usar. > **Dica** > > Perda que começa no salto 1 é da sua rede local: wifi, cabo ou roteador. Perda que só aparece no destino, com todos os saltos anteriores limpos, pode ser o servidor sobrecarregado ou um ataque saturando o link dele. Os sinais que separam ataque de pico legítimo estão em [como identificar um ataque DDoS](https://streethosting.com.br/guias/infraestrutura/identificar-ataque-ddos-servidor). ## Rodar nos dois sentidos A rota de ida e a rota de volta não são necessariamente a mesma. Cada rede escolhe por onde mandar o tráfego que sai dela, então os pacotes podem ir por uma operadora de trânsito e voltar por outra. O MTR que você roda de casa mede a ida até cada salto, mas a resposta de cada salto volta pela rota dele. Uma perda que nasce na volta aparece no seu relatório sem que o roteador culpado esteja listado. Por isso o diagnóstico completo tem dois relatórios: um do cliente até o servidor e outro do servidor até o IP público do cliente. Se você tem acesso ao servidor, rode lá `mtr -rwzbc 100 IP_PUBLICO_DO_CLIENTE`. O roteador doméstico do cliente pode não responder ICMP, e nesse caso o último salto mostra 100% de perda; olhe o salto anterior, que é a operadora dele. Para testar a volta a partir da rede da StreetHosting sem ter servidor, o [teste de conectividade](https://streethosting.com.br/tools/connectivity) mede a latência do seu navegador até os nós de São Paulo e roda um MTR do nó de SP até o seu IP público, com limite de um teste por minuto por nó. ## MTR no Windows com WinMTR O Windows não traz o MTR. O equivalente mais usado é o WinMTR, um programa gráfico e portátil que faz o mesmo trabalho: 1. Baixe o WinMTR da página oficial do projeto e extraia o executável. 2. No campo Host, digite o IP ou o domínio do servidor. 3. Clique em Start e deixe rodar até a coluna Sent passar de 100. 4. Clique em Stop e use Export TEXT ou Copy Text to clipboard. As colunas são as mesmas ideias com nomes diferentes: Loss %, Sent, Recv, Best, Avrg, Wrst e Last. O WinMTR não mostra desvio padrão, então compare Avrg e Wrst para enxergar jitter. A regra de leitura é a mesma: perda só conta se continuar até o destino. Sem instalar nada, o `pathping -n IP_DO_DESTINO` do próprio Windows descobre a rota e depois mede cada salto. É bem mais lento, porque coleta estatística de cada roteador por cerca de 25 segundos, mas o resultado final tem perda por salto e por trecho. ## Como montar o chamado Suporte de operadora e de provedor responde muito mais rápido a evidência bem montada. Junte isto antes de abrir o chamado: - [ ] MTR em modo relatório com pelo menos 100 pacotes e as opções -b e -z - [ ] O relatório nos dois sentidos, quando possível - [ ] Data, hora e fuso horário de cada teste - [ ] Seu IP público e o IP de destino - [ ] Um MTR para outro destino que funciona bem, como comparação - [ ] O sintoma em uma frase: o que falha, desde quando e em que horário - [ ] Se possível, um teste em modo TCP na porta do serviço afetado > **Atenção** > > Rode o MTR enquanto o problema está acontecendo. Um relatório limpo tirado duas horas depois do incidente não prova nada e costuma encerrar o chamado sem solução. ## MTR do lado do servidor Metade do diagnóstico depende de rodar comandos no servidor: o MTR de volta até o jogador, o modo TCP na porta do serviço, a comparação com outros destinos. Em hospedagem sem acesso ao sistema, você depende de alguém rodar isso para você. Numa [VPS da StreetHosting](https://streethosting.com.br/vps) você tem root, instala o `mtr-tiny` e testa do datacenter em São Paulo até qualquer usuário quando quiser, com uplink de 1 Gbps e AntiDDoS incluso. - **Ponto de medição e monitoramento:** a [VPS Xeon](https://streethosting.com.br/vps/xeon) de R$ 23,00, com 2 vCPU, 2 GB e 20 GB NVMe, basta para rodar MTR, ping agendado e um painel de monitoramento. - **Servidor de jogo ou aplicação:** a VPS Ryzen 9 9950X vai de R$ 39,00 a R$ 814,00, e o diagnóstico de rede fica na mesma máquina que atende os usuários. Para transformar o MTR em rotina, com medições de várias origens e em horários diferentes, siga o guia de [como testar a latência de uma VPS](https://streethosting.com.br/guias/vps/testar-latencia-vps). ## Perguntas frequentes ### Perda de pacotes em um salto do meio do MTR é problema? Só se a perda continuar nos saltos seguintes até o destino. Muitos roteadores limitam quantas respostas ICMP geram por segundo e tratam essas respostas com prioridade baixa, então aparecem com perda no MTR mesmo encaminhando todo o tráfego normalmente. Se o último salto mostra 0%, a perda do meio pode ser ignorada. ### Quantos pacotes devo usar no MTR? Pelo menos 100, com -c 100. Com poucos pacotes, uma única perda vira 10% ou 20% e engana a leitura. Para problemas intermitentes, rode 300 ou mais, ou deixe o MTR interativo aberto durante o horário em que o problema acontece. ### Qual a diferença entre MTR e traceroute? O traceroute descobre a rota uma vez, com três pacotes por salto. O MTR descobre a mesma rota e continua mandando pacotes para todos os saltos, acumulando perda, média, pior caso e desvio. Traceroute mostra o caminho; MTR mostra a qualidade de cada trecho do caminho ao longo do tempo. ### Como usar MTR no Windows? Use o WinMTR, que é uma versão gráfica do MTR para Windows. Digite o IP ou domínio, clique em Start, espere passar de 100 pacotes enviados, clique em Stop e exporte o resultado em texto. O pathping, que já vem no Windows, é uma alternativa mais lenta. ### Por que o último salto do MTR mostra 100% de perda? Normalmente porque o servidor de destino descarta ICMP no firewall, e não porque está fora do ar. Se o serviço funciona, não há problema. Para medir mesmo assim, rode o MTR em modo TCP apontando para uma porta aberta, com -T e -P. ## Guias relacionados - [Como usar traceroute para achar problemas de rota](https://streethosting.com.br/guias/infraestrutura/traceroute-diagnosticar-rota.md) - [Ping, jitter e packet loss: a diferença na prática](https://streethosting.com.br/guias/infraestrutura/ping-jitter-packet-loss-diferenca.md) - [Como testar a latência de uma VPS a partir do Brasil](https://streethosting.com.br/guias/vps/testar-latencia-vps.md) - [Identificar ataque DDoS: sintomas e diagnóstico no Linux](https://streethosting.com.br/guias/infraestrutura/identificar-ataque-ddos-servidor.md) - [O que é MTU e como um valor errado trava a conexão](https://streethosting.com.br/guias/infraestrutura/o-que-e-mtu-rede.md) ## Produtos citados - https://streethosting.com.br/vps - https://streethosting.com.br/vps/xeon ## Dados estruturados ```json [ { "@context": "https://schema.org", "@type": [ "Article", "TechArticle" ], "headline": "MTR na prática: rodar, ler cada coluna e provar onde está a perda", "name": "Como usar MTR para diagnosticar problemas de rede", "abstract": "O MTR junta traceroute e ping e mostra, salto por salto, onde a latência sobe e onde os pacotes se perdem. O segredo está em saber qual perda é real e qual é só um roteador economizando respostas.", "description": "Aprenda a rodar o MTR no Linux e o WinMTR no Windows, ler Loss, Avg, StDev e Worst, ignorar perda falsa e montar a prova certa para abrir chamado.", "datePublished": "2026-09-28", "dateModified": "2026-09-28", "author": { "@type": "Organization", "name": "Equipe StreetHosting" }, "publisher": { "@type": "Organization", "name": "StreetHosting", "url": "https://streethosting.com.br" }, "inLanguage": "pt-BR", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://streethosting.com.br/guias/infraestrutura/usar-mtr-diagnosticar-rede" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Perda de pacotes em um salto do meio do MTR é problema?", "acceptedAnswer": { "@type": "Answer", "text": "Só se a perda continuar nos saltos seguintes até o destino. Muitos roteadores limitam quantas respostas ICMP geram por segundo e tratam essas respostas com prioridade baixa, então aparecem com perda no MTR mesmo encaminhando todo o tráfego normalmente. Se o último salto mostra 0%, a perda do meio pode ser ignorada." } }, { "@type": "Question", "name": "Quantos pacotes devo usar no MTR?", "acceptedAnswer": { "@type": "Answer", "text": "Pelo menos 100, com -c 100. Com poucos pacotes, uma única perda vira 10% ou 20% e engana a leitura. Para problemas intermitentes, rode 300 ou mais, ou deixe o MTR interativo aberto durante o horário em que o problema acontece." } }, { "@type": "Question", "name": "Qual a diferença entre MTR e traceroute?", "acceptedAnswer": { "@type": "Answer", "text": "O traceroute descobre a rota uma vez, com três pacotes por salto. O MTR descobre a mesma rota e continua mandando pacotes para todos os saltos, acumulando perda, média, pior caso e desvio. Traceroute mostra o caminho; MTR mostra a qualidade de cada trecho do caminho ao longo do tempo." } }, { "@type": "Question", "name": "Como usar MTR no Windows?", "acceptedAnswer": { "@type": "Answer", "text": "Use o WinMTR, que é uma versão gráfica do MTR para Windows. Digite o IP ou domínio, clique em Start, espere passar de 100 pacotes enviados, clique em Stop e exporte o resultado em texto. O pathping, que já vem no Windows, é uma alternativa mais lenta." } }, { "@type": "Question", "name": "Por que o último salto do MTR mostra 100% de perda?", "acceptedAnswer": { "@type": "Answer", "text": "Normalmente porque o servidor de destino descarta ICMP no firewall, e não porque está fora do ar. Se o serviço funciona, não há problema. Para medir mesmo assim, rode o MTR em modo TCP apontando para uma porta aberta, com -T e -P." } } ] } ] ```