O que é o MTR? Como executar e ler um relatório mtr

O MTR (My Traceroute, originalmente Matt's traceroute) junta o traceroute e o ping. Descobre todos os routers entre a sua máquina e um destino; depois, continua a enviar sondas a cada um deles e a registar estatísticas. Um traceroute é uma única fotografia do caminho; um relatório mtr reúne cem, resumidas por salto. Este guia aborda a instalação, as opções que importam e um relatório real dos nossos servidores, lido coluna a coluna.

Instalar o mtr

Sistema	Instalação	Execução
Debian, Ubuntu	sudo apt install mtr-tiny (só texto) ou mtr	mtr example.com
Fedora, RHEL, Rocky	sudo dnf install mtr	mtr example.com
macOS	brew install mtr	sudo mtr example.com
Windows	WinMTR, um programa à parte com colunas semelhantes, ou o mtr dentro do WSL 2	Abra o WinMTR e introduza o host

No macOS, o Homebrew instala o mtr na sua própria pasta sbin, que nem sempre está no PATH, e o mtr precisa de sudo para enviar as sondas. Sem opções, o mtr abre um ecrã em tempo real, atualizado a cada segundo (prima q para sair). Para tudo o que quiser guardar ou enviar, use o modo de relatório, que executa um número fixo de ciclos e imprime o resultado uma única vez:

mtr -rwz -c 100 example.com

As opções que vale a pena conhecer

Opção	O que faz
-r	Modo de relatório: executa e depois imprime uma tabela que pode colar onde quiser
-w	Relatório largo: nomes de host completos em vez de truncados
-c 100	Número de sondas por salto. 10 chegam para uma vista rápida; 100 é o que se envia a um fornecedor
-z	Mostra o número de AS de cada salto, para ver onde uma rede passa o tráfego à seguinte
-n	Sem DNS inverso: mais rápido, mas perde os nomes dos routers, que muitas vezes contêm um código de cidade
-b	Mostra o nome e o endereço IP de cada salto
-T -P 443	Sondas TCP para a porta 443, para redes que descartam o ICMP
-u	Sondas UDP em vez de ICMP
-4, -6	Força IPv4 ou IPv6
-i 0.5	Segundos entre sondas (1 por predefinição; só o root pode descer abaixo de 1)
--json	Saída legível por máquina

Um relatório real, lido coluna a coluna

Lançámos este teste a 7 de outubro de 2026, às 12:26 UTC, a partir do nosso servidor em Falkenstein, na Alemanha (Hetzner), para um host de teste da Vultr em Nova Jérsia, com 100 sondas por salto. Só o nome da nossa máquina foi encurtado:

$ mtr -rwz -c 100 nj-us-ping.vultr.com
HOST: falkenstein                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.0.1                           73.0%   100    0.2   0.1   0.0   0.2   0.0
  2. AS24940  ex9k1.dc11.fsn1.hetzner.com           0.0%   100    4.7   1.0   0.3  15.1   1.7
  3. AS24940  core22.fsn1.hetzner.com               0.0%   100    0.8   0.7   0.3   1.7   0.2
  4. AS24940  juniper5.dc2.nbg1.hetzner.com         0.0%   100    3.0   5.2   2.8  65.6   9.2
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
  7. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  8. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  9. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
 10. AS20473  66.55.138.149.vultrusercontent.com    2.0%   100   85.7  85.9  85.6  87.3   0.2
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

• Loss%: a percentagem de sondas para esse salto que ficaram sem resposta. Aqui indica 73% no salto 1 e 2% no salto 10, mas 0% no destino. Nada disto é perda real (ver abaixo).
• Snt: sondas enviadas a cada salto, aqui 100.
• Last, Avg, Best, Wrst: tempo de ida e volta da última sonda, tempo médio, o mais rápido e o mais lento, em milissegundos. Best é o valor mais próximo do que o caminho permite fisicamente: 85,9 ms até Nova Jérsia.
• StDev: quanto variam os tempos, ou seja, o jitter. Entre 0,1 e 0,2 ms na maioria dos saltos: um caminho tranquilo.
• AS (com -z): a rede a que pertence cada endereço. Os saltos 2 a 4 são da Hetzner (AS24940), os saltos 5 e 6 da Core-Backbone (AS201011) e os saltos 10 e 11 da Vultr (AS20473). É nas transições entre elas que o congestionamento costuma aparecer, quando existe.
• Nomes: os nomes dos routers trazem muitas vezes uma cidade. O salto 5 é nbg40 (Nuremberga), a 3 ms, e o salto 6 é nyk10 (Nova Iorque), a 86,7 ms: a travessia do Atlântico, numa só linha.

Três coisas neste relatório que parecem erradas, mas não são

1. Perda num salto que não se prolonga. O salto 1 (o gateway do contentor onde o teste corre) deixa 73% das sondas sem resposta, o salto 10 deixa 2%, e todos os saltos depois deles respondem a tudo. Os routers respondem às sondas em software, com baixa prioridade, e muitos limitam o número de respostas que enviam por segundo. O tráfego que passa através deles não é afetado.
2. Um salto lento seguido de saltos rápidos. O salto 4 tem uma média de 5,2 ms e um pior caso de 65,6 ms, enquanto o salto 5, logo a seguir, nunca passa dos 3,3 ms. O router demorou a responder a algumas sondas; não atrasou os pacotes que encaminhou.
3. Saltos silenciosos. Os saltos 7 a 9 nunca respondem (???, 100%). São routers configurados para não responder. Como os saltos 10 e 11 respondem, é evidente que os pacotes passam por eles.

A regra que daqui decorre: a perda ou a latência só contam se começarem num salto e continuarem até ao destino. Se o salto 6 mostrasse 15% de perda e os saltos 7 a 11 mostrassem o mesmo, o problema começaria no salto 6 ou na ligação imediatamente anterior. Um pico que desaparece no salto seguinte é do router, não do caminho.

O mesmo relatório, feito no mesmo minuto para Singapura, mostra estes efeitos de forma ainda mais clara: um router da Arelion em Hamburgo respondeu apenas a 47% das sondas, outro em Singapura a 18%, com um pior tempo de 381,6 ms, e o destino respondeu a 100% delas, em 165,5 ms de média.

Quantas sondas, de onde e quando

• 10 sondas chegam para ver o caminho. São precisas 100 para medir a perda: com 10 sondas, uma perda de 1% aparece como 0% na maior parte das vezes.
• Execute-o enquanto o problema está a acontecer. Um mtr feito uma hora depois mostra um caminho saudável e não prova nada.
• Execute-o a partir de mais de um local. O mesmo host de Nova Jérsia, medido no mesmo minuto a partir do nosso servidor em Gravelines, em França (OVHcloud), respondeu em 71,7 ms em vez de 86,4 ms: a OVH transporta o tráfego na sua própria rede até Nova Iorque e entrega-o à Vultr no ponto de troca de tráfego NYIIX, enquanto a partir de Falkenstein passa pela Core-Backbone. Mesmo destino, duas rotas, 15 ms de diferença.
• Lembre-se do caminho de regresso. Cada tempo do relatório é uma ida e volta, e o regresso pode seguir outra rota, que o mtr não consegue ver. Se puder, execute também o mtr a partir da outra ponta.

Enviar um relatório mtr ao seu fornecedor

• Use mtr -rwzb -c 100: o relatório, os nomes completos, os números de AS e os endereços IP.
• Anote a data, a hora com o fuso horário, o seu IP público e o destino.
• Se o ICMP estiver filtrado algures no caminho, acrescente -T -P 443 e mencione-o.
• Indique o primeiro salto onde a perda ou a latência começa e se mantém até ao fim, não o salto com o número mais alto.

mtr, traceroute e ping

Ferramenta	O que mede	Sonda predefinida	Ideal para
ping	Ida e volta e perda, só até ao destino	ICMP echo	Saber se responde, com que rapidez e com que estabilidade
traceroute	O caminho, três sondas por salto, uma só vez	UDP no Linux e no macOS, ICMP no Windows (tracert)	Ver a rota
mtr	O caminho, com estatísticas de perda e latência para cada salto	ICMP (UDP ou TCP a pedido)	Problemas intermitentes, provas para um fornecedor

No Windows, sem o WinMTR, o pathping integrado faz algo semelhante em duas passagens: um rastreio e depois cerca de 25 segundos de sondas por salto. Para as diferenças entre as duas primeiras ferramentas, veja traceroute vs ping; para o comando traceroute de cada sistema, veja o comando traceroute no Windows, Mac e Linux.

Quando não o pode executar

As redes de escritório bloqueiam muitas vezes as sondas, os telemóveis não executam o mtr e um teste feito a partir da sua própria ligação não diz nada sobre o caminho a partir de outros locais. O TraceMapper faz a mesma medição a partir dos nossos servidores e de mais de 30 locais, coloca cada salto num mapa com a respetiva latência, perda e rede, e guarda o resultado num link que pode enviar. Para descobrir onde um caminho se degrada realmente, veja como identificar gargalos de rede.