Linux / Comando ping: verificar respostas, RTT e perda de pacotes
O comando ping envia solicitações Echo do ICMP (Internet Control Message Protocol, protocolo de mensagens de controle da Internet) para verificar respostas e medir o tempo de ida e volta, ou RTT (round-trip time). Ele ajuda a investigar a conectividade, mas a ausência de resposta não prova que o servidor ou seus serviços estejam indisponíveis.
O RTT varia com o caminho de rede, congestionamento e políticas de tratamento dos pacotes. Alguns hosts e firewalls bloqueiam ou limitam ICMP. Ao usar um nome, também há resolução de nomes, normalmente pelo DNS (Domain Name System); comparar com o endereço IP correto do mesmo destino ajuda a separar problemas de resolução de problemas de comunicação.
Sintaxe básica
ping [opções] destino
Os colchetes indicam opções facultativas; não são caracteres para digitar. O destino pode ser um nome ou endereço IP. Este texto descreve o ping do iputils para Linux. Consulte man ping e ping -V na máquina em uso: implementações como BusyBox e o programa do Windows têm diferenças de opções e unidades.
Sem limite, o ping do iputils normalmente continua até ser interrompido com Ctrl+C, quando apresenta um resumo. Para uma verificação pontual, prefira poucas solicitações e um destino que você tenha autorização para testar.
Exemplos de uso
Limitar a quantidade de solicitações
O exemplo envia quatro solicitações Echo e mostra as estatísticas ao terminar. -c 4 limita os envios; não garante quatro respostas:
ping -c 4 example.com
O domínio example.com foi mantido como exemplo de sintaxe. Segundo a IANA, esses domínios são reservados para documentação; não constituem um serviço de monitoramento com disponibilidade garantida. Para diagnosticar sua rede, substitua-o por um destino autorizado e conhecido, sem pressupor que ele responderá a ICMP.
Selecionar IPv4
A opção -4 força IPv4; -6 seleciona IPv6. Isso permite investigar cada família de endereços separadamente, mas não lista os roteadores percorridos:
ping -4 -c 4 example.com
Se uma família funciona e a outra falha, compare os endereços resolvidos, as rotas e as políticas daquela família. Para consultar interfaces e a decisão de encaminhamento, use o comando ip para endereços e rotas; uma consulta de rota também não prova que um serviço remoto responde.
Configurar a espera por respostas
O exemplo usa -W 2 no iputils, em segundos. O endereço abaixo é apenas um marcador de documentação: substitua-o pelo endereço real autorizado antes de usá-lo em um diagnóstico.
ping -c 4 -W 2 192.0.2.1
A faixa 192.0.2.0/24, à qual pertence 192.0.2.1, é a TEST-NET-1 da RFC 5737 sobre endereços para documentação. Ela não é um destino público de teste do qual se deva esperar resposta.
No iputils, -W controla a espera quando não há nenhuma resposta; quando há respostas, o programa usa uma espera de dois RTTs. Portanto, -W 2 não significa que toda a execução termina em dois segundos nem que cada pacote tem sempre uma espera independente e fixa de dois segundos. Para estabelecer um prazo de execução, use -w, com valor em segundos; -c, -W e -w têm funções diferentes.
Ler o RTT e a perda de pacotes
Para começar pelo próprio computador, este comando envia duas solicitações ao endereço de loopback IPv4, 127.0.0.1:
ping -c 2 127.0.0.1
Trecho ilustrativo do resumo de uma execução Linux em que ambas as respostas chegaram:
2 packets transmitted, 2 received, 0% packet loss
Nesse trecho, foram enviados dois pacotes e recebidas duas respostas, com perda de 0% nessa amostra. Isso verifica uma comunicação local de loopback; não testa o cabo, a interface física, o gateway ou o acesso à Internet. Uma amostra de dois ou quatro pacotes também não demonstra a estabilidade da rede durante um período longo.
O campo time= nas linhas de resposta indica o RTT em milissegundos. Ele mede a ida e a volta, não apenas um sentido, a velocidade de transferência ou o tempo completo de resposta de uma aplicação. Os valores mudam entre execuções; compare amostras equivalentes antes de atribuir uma variação a uma causa específica.
No ambiente de verificação, Windows 11 build 28000, o Bash 5.3.9 encontrou o executável nativo do Windows, e não o iputils. Um teste separado, limitado a duas solicitações ao próprio loopback, recebeu duas respostas e perda de 0%. As opções Linux deste artigo não foram executadas nesse programa; o trecho acima continua sendo uma ilustração do formato Linux, não uma transcrição desse teste Windows. A documentação do ping no Windows descreve sua contagem e seu tempo de espera em milissegundos.
Opções principais
| Opção ou formato | Função no iputils |
|---|---|
-c quantidade |
Limita a quantidade de solicitações enviadas; respostas podem ser menos numerosas. Com um prazo definido por -w, considera também esse prazo e a contagem de respostas. |
-4 / -6 |
Seleciona IPv4 ou IPv6. Não é um rastreamento de saltos da rota. |
-W segundos |
Ajusta a espera na ausência de respostas; com respostas, aplica-se a espera de dois RTTs descrita no manual. O valor 0 significa espera infinita. |
-w segundos |
Define um prazo para encerrar a execução, independentemente da quantidade enviada ou recebida; pode terminar antes ao satisfazer a contagem ou ocorrer um erro. |
-i segundos |
Ajusta o intervalo entre solicitações. Evite intervalos reduzidos sem necessidade e autorização. |
Maiúsculas e minúsculas fazem diferença: -W e -w não são intercambiáveis. Confira as condições exatas no manual do ping do iputils, sobretudo antes de usar essas opções em scripts.
Investigar uma falha sem tirar conclusões precipitadas
Uma perda de 100% significa que as solicitações transmitidas naquela amostra não tiveram respostas contabilizadas. Pode haver bloqueio ou limitação de ICMP, problema no caminho ou indisponibilidade do destino. Se o nome nem foi resolvido e nenhum pacote foi enviado, a falha de DNS é anterior a essa medição: não é evidência de perda de todos os pacotes na rede.
- Leia a mensagem inicial e o resumo. Diferencie falha de resolução de nome, erro local de envio e ausência de respostas depois dos envios. Confirme que o destino e a família IP são os pretendidos.
- Compare o nome com o endereço IP correto do mesmo destino. Se apenas a consulta por nome falha, investigue a resolução; se ambos falham, examine também interfaces, rotas e políticas de ICMP.
- Quando apropriado, teste poucos pacotes primeiro no loopback, depois em um gateway e em um destino remoto conhecido que aceite esses testes. Registre em qual etapa o comportamento muda, sem presumir que todo roteador responde a ping.
- Verifique o serviço com seu cliente e protocolo reais. No servidor, o comando ss ajuda a consultar sockets e portas em escuta; uma porta em escuta localmente ainda não comprova acesso do cliente através de firewalls, redirecionamentos e rotas.
O código de saída também exige contexto. No iputils, 1 indica que nenhuma resposta chegou ou, quando há contagem e prazo juntos, que chegaram menos respostas do que a contagem até o prazo; outros erros usam 2. Fora dessas condições, o código é 0: ele pode acompanhar perda parcial e não é um certificado de perda zero nem de funcionamento de uma aplicação. No Bash, consulte echo $? imediatamente após o comando para não ler o resultado de outro programa.
Solicitações contínuas em alta frequência podem sobrecarregar o destino ou a rede. Limite a duração e a quantidade ao necessário; não transforme uma verificação simples em flood nem altere regras de segurança apenas para obter uma resposta.
Pergunta frequente
Se o ping não responder, o servidor está desligado?
Não é possível concluir isso apenas com ping. Uma política pode bloquear ICMP enquanto web e SSH continuam funcionando; também pode haver um erro de rota ou resolução de nomes. Confirme o endereço, leia a mensagem de erro e teste o serviço pelo protocolo apropriado antes de diagnosticar indisponibilidade do servidor.




