Quando a rede não funciona, saber isolar o problema rapidamente faz toda a diferença. Neste post vamos usar ping, traceroute e mtr para diagnosticar problemas de conectividade de forma metódica.
ping -c
O ping envia pacotes ICMP Echo Request e mede o tempo de resposta. Use -c para limitar a quantidade de pacotes:
ping -c 4 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=11.9 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 11.800/12.025/12.300/0.187 msO que observar:
- ttl=118 - Time To Live. Cada roteador decrementa em 1. O TTL inicial costuma ser 64 (Linux) ou 128 (Windows). Com ttl=118, o pacote passou por ~10 saltos (128-118).
- time=12.3 ms - latência (round-trip). Abaixo de 50ms é bom para a maioria das aplicações.
- packet loss - perda acima de 0% indica problema na rede.
ping -c 4 -W 2 para definir um timeout de 2 segundos. Útil em scripts para evitar espera infinita.traceroute
O traceroute mostra cada salto (roteador) entre você e o destino:
traceroute 8.8.8.8traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 gateway (192.168.1.1) 1.234 ms 1.102 ms 1.056 ms
2 10.0.0.1 (10.0.0.1) 5.678 ms 5.432 ms 5.321 ms
3 isp-router.example.net (203.0.113.1) 8.901 ms 8.765 ms 8.654 ms
4 * * *
5 72.14.236.208 (72.14.236.208) 11.234 ms 11.123 ms 11.012 ms
6 dns.google (8.8.8.8) 12.345 ms 12.234 ms 12.123 msCada linha mostra um salto com 3 medições de latência. Asteriscos (* * *) significam que o roteador não respondeu (pode estar configurado para ignorar ICMP, não necessariamente indica problema).
mtr (My Traceroute)
O mtr combina ping e traceroute em uma ferramenta interativa que atualiza em tempo real:
# Modo relatório (não interativo)
mtr -r -c 10 8.8.8.8Start: 2026-03-27T10:30:00-0300
HOST: meuservidor Loss% Snt Last Avg Best Wrst StDev
1.|-- gateway 0.0% 10 1.1 1.2 0.9 1.5 0.2
2.|-- 10.0.0.1 0.0% 10 5.4 5.6 5.1 6.2 0.3
3.|-- isp-router 0.0% 10 8.7 8.9 8.3 9.5 0.4
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- 72.14.236.208 0.0% 10 11.1 11.3 10.8 11.9 0.3
6.|-- dns.google 0.0% 10 12.2 12.4 11.9 13.1 0.4Colunas importantes:
- Loss% - percentual de perda em cada salto.
- Avg - latência média.
- StDev - desvio padrão. Valores altos indicam jitter (instabilidade).
Interpretando TTL e latência
O TTL ajuda a identificar o sistema operacional do destino e a distância em saltos:
# TTL inicial por sistema operacional
# Linux: 64
# Windows: 128
# Cisco: 255
# Calcular saltos: TTL_inicial - TTL_recebido
# Exemplo: recebeu ttl=52 → 64-52 = 12 saltos (provavelmente Linux)Latência normal varia conforme a distância:
- < 1 ms - rede local
- 1-20 ms - mesma cidade/região
- 20-100 ms - mesmo continente
- 100-300 ms - intercontinental
Troubleshooting passo a passo
Quando a rede falha, siga esta ordem:
# 1. Interface está UP?
ip link show
# 2. Tem IP?
ip addr show
# 3. Gateway responde?
ping -c 2 $(ip route show default | awk '{print $3}')
# 4. DNS funciona?
ping -c 2 8.8.8.8 # testa IP direto
ping -c 2 google.com # testa resolução DNS
# 5. Onde está o problema?
mtr -r -c 5 google.comSe o passo 3 falha, o problema é local (cabo, IP, gateway). Se o passo 4 funciona com IP mas falha com nome, o problema é DNS. Se o passo 5 mostra perda a partir de um salto, o problema está naquele ponto da rede.
mtr antes e durante o problema. Comparar os dois relatórios facilita muito a identificação do ponto de falha junto ao provedor ou equipe de infra.