Traceroute e tracert: como ler a saída e separar falso alarme de problema real na rota
Autor: Pedro Tebaldi PM do KeepGreenQuando o usuário reclama de lentidão num sistema hospedado fora da empresa, o traceroute costuma ser o segundo comando do plantão, logo depois do ping. Em segundos, a saída devolve uma lista de saltos, tempos em milissegundos e, quase sempre, alguns asteriscos que parecem apontar o culpado.
Ler essa saída exige mais cuidado do que parece. Um salto com 300 ms no meio da rota pode ser só um roteador que responde ICMP sem pressa, enquanto o tráfego segue normal. Linhas inteiras de * * * também aparecem em redes que entregam todos os pacotes. Quem abre chamado com a operadora a partir dessa leitura costuma voltar sem resposta, com o incidente ainda aberto.
Todas as saídas deste artigo vieram de um laboratório montado em 15 de setembro de 2026, com um cliente, três roteadores Linux e um servidor. Cada equipamento ocupa um namespace de rede próprio, com atraso e perda injetados por tc netem e iptables. Uma vez que cada defeito foi colocado de propósito, dá para comparar a causa conhecida com o que o comando mostra.
Como o traceroute descobre cada salto da rota
Para descobrir a rota, o traceroute envia sondas com o campo TTL crescente: a primeira sai com TTL 1, a segunda com TTL 2. Cada roteador decrementa o TTL antes de encaminhar o pacote. Quem recebe a sonda com o TTL esgotado descarta o pacote e, em seguida, devolve uma mensagem ICMP Time Exceeded à origem.
Cada mensagem dessas vira uma linha da saída, com o endereço de quem respondeu e o tempo entre o envio da sonda e a resposta. A execução termina quando a sonda alcança o destino ou quando o limite de 30 saltos se esgota.
No Linux, o traceroute usa UDP por padrão, com porta de destino a partir de 33434. Nesse modo, o destino se revela quando devolve Port Unreachable, já que nenhum serviço escuta naquela porta. Já o tracert do Windows envia só ICMP Echo Request e reconhece o destino pelo Echo Reply.
Essa diferença decide o que um firewall no caminho deixa passar, como mostra o teste com TCP mais adiante. Ainda assim, os dois comandos enviam três sondas por salto e param em 30 saltos. No Windows, a espera por resposta é de 4 segundos e muda com /w.
Como ler cada coluna da saída
Na linha de base do laboratório, com os quatro enlaces funcionando, a saída ficou assim:
Cada linha traz o número do salto, o endereço que respondeu e três tempos de ida e volta, um por sonda. Mais do que o valor absoluto, interessa a diferença entre saltos consecutivos, porque ela isola o custo de cada enlace. Do salto 2 para o salto 3, o tempo passou de 9 para 27 ms. Esses 18 ms correspondem ao enlace entre r2 e r3, configurado com 9 ms em cada sentido.
Na saída aparece o endereço da interface por onde a sonda entrou no roteador, que nem sempre é o endereço de gerência. A referência oficial do comando no Windows descreve esse endereço como a interface mais próxima de quem envia.
Sem a opção -n (no Windows, /d), cada endereço passa por DNS reverso. Operadoras costumam codificar cidade e interface no hostname, o que ajuda a achar a fronteira entre a sua rede e a do provedor.
Por outro lado, cada consulta que expira acrescenta segundos à execução. Durante um incidente, rode primeiro com -n e resolva depois só os endereços que interessam.
Tempo de ida e volta inclui um caminho que a saída não mostra
Cada tempo soma a ida até o roteador com a volta da resposta, que pode seguir outro caminho. Com roteamento assimétrico, a mensagem de um salto intermediário atravessa enlaces que nunca aparecem na lista. Medir a rota de volta só é possível a partir do outro lado.
Esse efeito apareceu no teste que comparou o TTL do ping com o tracert. Ali, a contagem de roteadores feita pelo TTL ficou abaixo da contagem do tracert, porque o TTL da resposta decrementa no caminho de volta.
Três sinais na saída que parecem falha e não são
Nos três testes abaixo, a topologia da linha de base recebeu um único defeito de cada vez. Em nenhum deles o tráfego entre cliente e servidor sofreu perda ou atraso, embora a saída sugira o contrário.
Asterisco num salto intermediário com o destino respondendo
Primeiro, o roteador r2 passou a descartar as mensagens Time Exceeded que ele mesmo gera, sem mexer no encaminhamento. Daqui em diante, as saídas omitem o prefixo ip netns exec cli:
Mesmo com o salto 2 em * * *, o salto 3 e o destino responderam com os tempos da linha de base. Sempre que um salto posterior responde, o pacote passou pelo anterior. Nesse caso, o asterisco indica só que aquele roteador não devolveu a mensagem dentro do tempo de espera. Filtro de ICMP na borda da operadora costuma produzir exatamente esse desenho.
Latência alta num salto que desaparece no salto seguinte
No teste seguinte, o r2 passou a atrasar em 80 ms só as respostas ICMP que ele gera, preservando o encaminhamento. Esse é o comportamento de um roteador que processa o Time Exceeded na CPU, com prioridade baixa, enquanto encaminha o tráfego em hardware:
Pela saída, o salto 2 marcou 89 ms e o salto 3, que fica depois dele, marcou 27 ms. Toda sonda que chega ao salto 3 atravessa o r2; por isso, um atraso real no r2 apareceria em todos os saltos seguintes. Latência que não se propaga até o destino mede a pressa do roteador em responder, não o caminho.
Destino que muda de distância entre duas execuções
Para o terceiro teste, o limite padrão de ICMP do kernel voltou a valer nos roteadores e no servidor. Duas execuções seguidas do mesmo comando produziram esta saída:
Na primeira execução, assim como na linha de base, o servidor apareceu no salto 4. Na segunda, os saltos de 4 a 8 viraram asterisco e o servidor surgiu no salto 9, embora continuasse a quatro saltos do cliente.
Por trás disso está o icmp_ratelimit, que a documentação do kernel Linux fixa em 1.000 ms como intervalo mínimo entre respostas ao mesmo destino. Esse limite vale tanto para Destination Unreachable quanto para Time Exceeded, conforme a máscara padrão icmp_ratemask.
Como o comando dispara várias sondas em paralelo, a primeira execução consome a margem de respostas do servidor. Durante a espera pelos saltos 4 a 8, o limitador recuperou margem para responder à sonda do salto 9. Roteadores e firewalls aplicam limites parecidos, de modo que execuções repetidas em sequência medem o limitador em vez da rota.
Como a latência real aparece na saída
Sem nenhum filtro ativo, o enlace entre r2 e r3 ganhou 30 ms em cada sentido. Dessa vez, o atraso aconteceu no caminho do tráfego:
Do salto 3 em diante, tudo subiu 60 ms: 87 ms no salto 3 e 89 ms no destino. Esse degrau surge no primeiro salto depois do enlace afetado e se mantém até o fim da rota, que é a assinatura de latência real. Para localizar o problema, olhe o par formado pelo último salto normal e pelo primeiro com degrau.
Localizado o enlace, falta separar propagação, fila e processamento, componentes da latência de rede que pedem correções diferentes.
Quando a rota parece dar voltas
Em redes com balanceamento de carga por fluxo, cada sonda do traceroute clássico pode seguir um caminho diferente. Isso acontece porque a porta UDP de destino muda a cada sonda, enquanto o roteador distribui os fluxos pelos campos do cabeçalho.
Na saída surgem saltos alternando entre dois endereços, ligações inexistentes e o mesmo roteador repetido em sequência.
Num estudo apresentado na IMC 2006, com medições feitas a partir de Paris contra 5.000 destinos, 5,3% das rotas tinham ao menos um loop. Os autores atribuíram 84,7% desses loops ao balanceamento por fluxo.
Trata-se de uma medição antiga, feita de um só ponto de origem, como os próprios autores ressalvam. Ainda assim, o mecanismo pode aparecer em qualquer rede com ECMP por fluxo. Como correção, o mesmo trabalho propõe manter constantes os campos que definem o fluxo, para que todas as sondas sigam um só caminho.
Qual protocolo usar quando o firewall esconde o destino
Neste teste, o servidor passou a descartar UDP e ICMP Echo Request, mantendo aberta a porta TCP 443. É uma configuração comum em servidor exposto à internet. Todas as execuções saíram do mesmo cliente, com limite de 7 saltos para que a saída ficasse curta:
Com UDP e com ICMP, a saída parou no salto 3 e seguiu com asteriscos até o limite, sugerindo um servidor fora do ar. Com -T -p 443, porém, o traceroute envia SYN na porta do serviço e alcança o servidor no salto 4. O tempo ficou nos mesmos 29 ms da linha de base.
Para diagnosticar um serviço web, a sonda precisa usar o protocolo e a porta que o firewall trata como tráfego legítimo. O que cada equipamento descarta depende de como o firewall decide o que passa. Nesse ponto o tracert do Windows não ajuda, porque não tem modo TCP.
Significado de !H, !N e !X depois do tempo
Asterisco significa silêncio, enquanto as anotações depois do tempo são respostas explícitas. Com uma regra de rejeição no r3, o tráfego para o servidor passou a receber a mensagem de proibição administrativa:
No salto 4 aparece o próprio r3, com !X nas três sondas, encerrando a execução ali. Pela página de manual, !H, !N e !P indicam host, rede ou protocolo inalcançável, enquanto !X indica comunicação proibida por política. Diante de !X, a investigação sai da latência e vai para a regra de ACL ou firewall daquele equipamento.
MTR para medir perda por salto ao longo do tempo
Três sondas por salto não medem perda, já que um asterisco isolado pode ser só uma resposta atrasada. Para isso existe o MTR, que repete o traceroute em ciclo e acumula perda e latência por salto. No Windows, o equivalente nativo é o pathping, citado na mesma referência do tracert.
Nos dois relatórios abaixo, cada execução somou 200 ciclos com intervalo de 0,1 s. No primeiro, o enlace entre r2 e r3 descartou um em cada dez pacotes no sentido da ida. No segundo, o r2 passou a limitar a 5 por segundo as mensagens Time Exceeded que gera:
Com perda real, a coluna Loss% marcou 7,0 no salto 3 e 10,5 no destino, perto da taxa injetada. Com o limitador, o salto 2 chegou a 48,0 enquanto o salto 3 e o destino ficaram em 0,0.
Toda leitura de MTR começa pelo destino. Quando a perda para num salto intermediário, o roteador está só economizando respostas. Já a perda que continua até o fim começa no primeiro salto em que aparece. Desse salto em diante vale o diagnóstico de perda de pacotes.
Tabela de leitura: sinal, o que o laboratório mostrou e próximo passo
Cada sinal dos testes acima aparece na tabela na ordem em que costuma surgir durante um incidente.
| Sinal na saída | O que o laboratório mostrou | Próximo passo |
|---|---|---|
* * * num salto, com os seguintes respondendo |
r2 descartando só o Time Exceeded; destino com o tempo da linha de base | seguir a leitura pelo salto seguinte, sem abrir chamado por aquele salto |
| Pico de latência num salto que some no seguinte | 89 ms no salto 2 e 27 ms no salto 3 | tratar como resposta lenta do roteador, não como gargalo do caminho |
| Degrau de latência que se mantém até o destino | 60 ms a mais do salto 3 até o destino | investigar o enlace entre o último salto normal e o primeiro com degrau |
| Destino que muda de salto entre execuções | salto 4 na primeira execução e salto 9 na segunda | esperar alguns segundos entre execuções antes de comparar |
| Asteriscos até o limite com UDP e ICMP | -T -p 443 alcançou o destino no salto 4 |
repetir com TCP na porta do serviço antes de declarar o destino fora do ar |
!X depois do tempo |
r3 rejeitando o tráfego por política | revisar ACL e firewall do equipamento que respondeu |
| Perda no MTR só num salto intermediário | 48,0% no salto 2 e 0,0% no destino | descartar como limitação de ICMP daquele roteador |
| Perda no MTR que segue até o destino | 7,0% no salto 3 e 10,5% no destino | investigar a partir do primeiro salto em que a perda aparece |
Do traceroute pontual ao caminho monitorado
Traceroute responde sobre um instante e uma direção. Sem histórico, ninguém sabe se os 40 ms de um salto são novidade ou o valor de todo dia. Além disso, não dá para saber se a rota mudou horas antes de alguém rodar o comando.
Medição contínua fecha essas lacunas ao coletar latência e perda até os destinos críticos, a partir do datacenter, das filiais e da nuvem. Registrar a sequência de saltos também permite alertar quando a rota muda. Mudança de rota fora da sua rede costuma ser decisão de roteamento BGP da operadora, que você não controla mas precisa conseguir provar.
Para cobrar o provedor, a evidência que se sustenta é o MTR com centenas de ciclos no horário do problema. Essa medição ganha peso quando comparada à linha de base que o monitoramento do link de internet já registrou.
Numa das maiores redes de varejo do Brasil, o MTTR alto gerava salas de guerra frequentes, com várias equipes mobilizadas. Infraestrutura, aplicação e operação não enxergavam o processo de ponta a ponta.
Mapeamos os processos críticos e suas dependências (rede, Wi-Fi, pagamento e PIX, entre outras) para monitorar cada processo inteiro. O resultado foi a redução de MTTR e o fim das salas de guerra.
Identificamos gargalos de rede antes que virem incidentes críticos.
Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.
Evidência para levar ao chamado com a operadora
Antes de escalar para o provedor, junte a evidência que resiste à primeira resposta padrão do suporte. Rode o MTR com -n e centenas de ciclos no horário em que o problema acontece. Sempre que UDP ou ICMP pararem no meio do caminho, repita com TCP na porta do serviço.
Leia perda e latência pelo destino, localize o primeiro salto com degrau e descarte asterisco e pico que não se propagam. Se puder, meça também a partir de um segundo ponto, porque o caminho de volta pode ser outro. Entre uma execução e outra, espere alguns segundos para não medir o limitador de ICMP.
Quando essa rotina precisa rodar o tempo todo, em dezenas de links, ela deixa de ser comando de plantão. Nesse ponto, o trabalho pede monitoramento com histórico, alerta de mudança de rota e relatório por enlace. Fale com um especialista da OpServices para estruturar a medição contínua de latência, perda e rota dos seus links.
Perguntas Frequentes
Qual é o comando para traceroute no Windows?
tracert, executado no Prompt de Comando ou no PowerShell, como em tracert 8.8.8.8. Ele envia ICMP Echo Request com TTL crescente, testa até 30 saltos e espera 4 segundos por resposta, valores que mudam com /h e /w. A opção /d desliga a resolução de nomes e acelera a execução, enquanto /4 força IPv4 quando o destino também tem endereço IPv6. O tracert não tem modo TCP: para testar a porta de um serviço web, rode o traceroute -T a partir de um host Linux.Como fazer tracert para um IP?
tracert /d 203.0.113.10 no Windows ou traceroute -n 203.0.113.10 no Linux. Passar o IP direto evita que a consulta DNS atrase a execução ou resolva o nome para outro endereço, como acontece com nomes atendidos por CDN. Leia a saída pela diferença de tempo entre saltos consecutivos e confira se o último salto é o IP informado. Se a lista terminar em asteriscos, repita com outro protocolo antes de concluir que o destino está fora do ar.Como descobrir a rota de um IP?
-A do traceroute consulta os registros de roteamento e mostra o sistema autônomo de cada salto, o que ajuda a identificar em que operadora o tráfego está. Em rede com balanceamento de carga, execuções diferentes podem mostrar saltos diferentes para o mesmo IP.
