Traceroute vs ping: o que cada um revela, com exemplos

Tanto o ping como o traceroute enviam pacotes e cronometram as respostas, mas não respondem às mesmas perguntas. O ping diz-lhe se um host responde e quanto tempo demora uma ida e volta. O traceroute diz-lhe que routers estão entre a sua máquina e esse host, e em que ponto do caminho se gasta o tempo. Mais abaixo, as duas ferramentas são executadas contra o mesmo host, a partir do mesmo servidor, com um minuto de intervalo, seguindo-se uma tabela para escolher qual executar primeiro.

A diferença numa tabela

	Ping	Traceroute
Pergunta a que responde	O host responde, e com que rapidez?	Que routers estão no caminho, e onde se acumula o atraso?
O que envia	ICMP Echo Request	Pacotes com um TTL crescente: UDP no Linux e no macOS, ICMP no Windows (tracert)
Quem responde	Só o destino	Cada router pelo caminho (ICMP Time Exceeded) e depois o destino
Saída	Um tempo por pacote e, no fim, a perda e min/avg/max	Uma linha por salto, três tempos por linha
Duração	No Linux e no macOS, até o interromper; no Windows, 4 pacotes	De alguns segundos a um minuto
Ponto cego	Não diz nada sobre onde surge um atraso	Uma única fotografia; os saltos intermédios podem parecer lentos ou com perdas sem o serem

Ping: um só número, bem medido

Do nosso servidor em Falkenstein, na Alemanha, para um host de teste da Vultr em Nova Jérsia, a 7 de outubro de 2026, às 12:27 UTC:

$ ping -c 10 nj-us-ping.vultr.com
PING nj-us-ping.vultr.com (108.61.149.182) 56(84) bytes of data.
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=1 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=2 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=3 ttl=50 time=86.4 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=4 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=5 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=6 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=7 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=8 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=9 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=10 ttl=50 time=86.2 ms

--- nj-us-ping.vultr.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9410ms
rtt min/avg/max/mdev = 86.113/86.212/86.360/0.081 ms

• time= é o tempo de ida e volta de cada pacote: cerca de 86 ms, somando a ida e o regresso.
• 0% packet loss e mdev 0,081 ms (a dispersão dos tempos): o caminho é estável. Um caminho saudável dentro de um continente mostra muitas vezes um mdev abaixo de 1 ms; valores de dezenas de milissegundos apontam para congestionamento ou Wi-Fi.
• ttl=50 é o que restava do time-to-live da resposta à chegada. Se o host começou em 64, o valor predefinido habitual no Linux, a resposta atravessou 14 routers no regresso, mais três do que os 11 saltos que o traceroute conta na ida (ver abaixo). O regresso segue muitas vezes outra rota, e nenhuma ferramenta executada do seu lado a consegue mostrar.

O que o ping não consegue dizer é porque é que demora 86 ms. Isso é trabalho do traceroute.

Traceroute: de onde vêm os 86 ms

O mesmo host, a partir do mesmo servidor, um minuto depois, com as sondas UDP predefinidas:

$ traceroute nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  * * *
 2  ex9k1.dc11.fsn1.hetzner.com (213.133.117.208)  0.517 ms  0.318 ms  0.291 ms
 3  core23.fsn1.hetzner.com (213.133.126.23)  3.999 ms  3.920 ms  3.834 ms
 4  juniper4.dc2.nbg1.hetzner.com (213.239.252.233)  2.806 ms juniper5.dc2.nbg1.hetzner.com (213.239.252.245)  2.854 ms juniper5.dc2.nbg1.hetzner.com (213.239.254.218)  2.959 ms
 5  ae12-498.nbg40.core-backbone.com (5.56.20.253)  2.763 ms  2.687 ms  2.666 ms
 6  ae7-2093.nyk10.core-backbone.com (81.95.9.195)  86.557 ms  86.413 ms  86.437 ms
 7  * * *
 8  * * *
 9  * * *
10  66.55.138.149.vultrusercontent.com (66.55.138.149)  85.763 ms  85.862 ms  85.692 ms
11  * * *
12  * * *
[o mesmo * * * em todas as linhas até à 30]
30  * * *

• Os 86 ms surgem de uma vez, no salto 6. O salto 5 é nbg40, em Nuremberga, a 2,7 ms; o salto 6 é nyk10, em Nova Iorque, a 86,4 ms. Tudo o que está antes é a travessia da Alemanha, tudo o que vem depois fica ao mesmo nível: o tempo é o Atlântico. O ping não lhe podia ter dito isso.
• Os tempos não se somam de salto em salto. O salto 3 responde em 3,9 ms e o salto 4, mais longe, em 2,8 ms. Cada linha é uma ida e volta independente, respondida por um router diferente, que leva o seu próprio tempo a responder.
• Linhas silenciosas não são interrupções. O salto 1 e os saltos 7 a 9 nunca respondem, mas o salto 10 responde: esses routers simplesmente não respondem a sondas.
• A última linha nunca chega. Depois do salto 10, só asteriscos até ao salto 30, embora o ping tenha mostrado o host a responder perfeitamente. Este host não responde a sondas UDP. Com sondas ICMP, como as do ping, o mesmo rastreio chega lá:

$ traceroute -I -n -q 1 nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  *
 2  213.133.117.208  0.372 ms
 3  213.133.126.22  0.357 ms
 4  213.239.254.238  2.813 ms
 5  81.95.15.5  2.710 ms
 6  81.95.9.195  86.418 ms
 7  *
 8  *
 9  *
10  66.55.138.149  85.749 ms
11  108.61.149.182  85.975 ms

É o erro de leitura mais comum num traceroute: um rastreio que termina em asteriscos não significa que o host esteja em baixo. Confirme com o ping e repita o rastreio com outro protocolo (-I para ICMP, ou -T -p 443 para TCP no Linux, como root).

Qual executar primeiro

Sintoma	Comece por	Depois
«O site está em baixo»	Ping ao host e a um host que funciona de certeza (1.1.1.1)	Se o ping falhar, traceroute para ver onde se interrompe. Muitos hosts bloqueiam o ping: teste o próprio serviço (um pedido HTTP ou um teste de porta) antes de tirar conclusões
«Está lento»	Ping durante 30 a 60 segundos: a média e a dispersão	Traceroute ou mtr para encontrar o salto onde o tempo sobe de repente e se mantém
«De vez em quando cai»	Um ping longo (ping -c 300) para a taxa de perda	mtr -c 100 para ver a partir de que salto começa a perda
«É a minha rede ou a deles?»	Traceroute a partir da sua máquina	O mesmo rastreio a partir de outro local, para comparar
As transferências grandes ou a VPN encravam, as pequenas funcionam	Ping com um pacote de tamanho completo que não pode ser fragmentado	Reduza o tamanho até passar: esse é o MTU do caminho

O teste de tamanho completo envia 1.472 bytes de dados, que, com 28 bytes de cabeçalhos, perfazem um pacote de 1.500 bytes: ping -M do -s 1472 host no Linux, ping -D -s 1472 host no macOS, ping -f -l 1472 host no Windows.

Opções que mudam a resposta

• ping -c 20: termina ao fim de 20 pacotes (no Windows: -n 20). -i 0.2 envia um pacote a cada 0,2 segundos em vez de um por segundo.
• ping -W: a espera por cada resposta é em segundos no Linux e em milissegundos no macOS, uma armadilha clássica quando um script passa de um sistema para o outro.
• -4 ou -6 no Linux e no Windows: força IPv4 ou IPv6 (o macOS tem comandos à parte, ping6 e traceroute6). Um host pode ser rápido num e lento no outro.
• traceroute -n: dispensa as consultas de DNS inverso, o que é muito mais rápido, mas perde os nomes dos routers, que são muitas vezes a melhor pista para saber onde fica um salto.

Onde ambos ficam aquém

• Um só sentido. Ambos mostram o caminho a partir do local onde são executados. O caminho de regresso, que a pista do TTL acima mostra ser diferente, fica invisível.
• Para os routers, as sondas vêm em último lugar. Um salto que parece lento ou com perdas só conta se todos os saltos seguintes, até ao destino, tiverem o mesmo aspeto. Está explicado com exemplos reais em como identificar gargalos de rede.
• Um só momento. Uma única execução pode não apanhar um problema intermitente. O mtr junta as duas ferramentas e repete a medição em cada salto.

Para ver a mesma comparação sem terminal, o ping do TraceMapper e o traceroute são executados a partir dos nossos servidores e de mais de 30 locais, com cada salto colocado num mapa. Para os comandos de cada sistema, veja o comando traceroute no Windows, Mac e Linux.