Diagnóstico de Rede: 5 Comandos Que Resolvem

# Diagnóstico de Rede: 5 Comandos Que Resolvem  Todo profissional de suporte já viveu essa cena clássica: o usuário diz que “a internet caiu”. Você senta na máquina e começa a testar algo meio no chute. Abre o navegador, tenta um site, reinicia o roteador, verifica o cabo. Funciona? Às vezes. Mas leva o triplo do tempo e você termina sem entender o que era o problema. A diferença entre um chute e um diagnóstico real não está nos comandos em si — quase todo mundo conhece o ping. Está na ordem. Cada comando responde uma pergunta específica. Cada resposta elimina metade das possibilidades. Em cinco passos você evolui de “não funciona” para “o problema está exatamente aqui, nesta camada”. ## ipconfig: Confirmando a Identidade da Máquina Antes de testar qualquer conexão, confirme a identidade da máquina na rede. Este é o ponto de partida fundamental. Sem uma configuração básica correta, qualquer outro teste será inútil. “` ipconfig /all # Windows ip a && ip route # Linux “` Busque quatro números críticos: endereço IP, máscara de sub-rede, gateway padrão e servidores DNS. Cada um precisa fazer sentido para o ambiente onde a máquina está. Portanto, não pule essa validação inicial. Um sinal que resolve o chamado imediatamente: IP começando com 169.254. Isso é APIPA (Automatic Private IP Addressing). O Windows não conseguiu comunicar com o servidor DHCP e inventou um endereço sozinho. Não é problema de internet. É problema de rede local: cabo solto, porta do switch problemática, VLAN errada ou DHCP fora do ar. Nem adianta pingar nada neste ponto. Além disso, máquina com IP certo e máscara errada enxerga metade da rede. Falha com a outra metade. Esse é o defeito que faz você perder a tarde inteira, porque “às vezes funciona”. Quando você conecta a um servidor no mesmo segmento e depois tenta outro que não está, a máscara incorreta parece aleatória. Por isso conferir ipconfig é fundamental e economiza horas de diagnóstico. ## ping: Os Três Passos Que Eliminam Dúvidas Pingar o Google e concluir que “está tudo bem” desperdiça completamente esse comando. O valor real está em usá-lo três vezes. Aumente o alcance a cada rodada, criando um funil de diagnóstico estruturado. “` ping 192.168.1.1 # 1. o gateway — a rede local funciona? ping 1.1.1.1 # 2. um IP externo — o roteamento funciona? ping google.com # 3. um nome — a resolução de nomes funciona? “` A leitura é direta e elimina completamente ambiguidades. Falhou no primeiro? O problema é local. Pode ser cabo, Wi-Fi, switch ou firewall da própria máquina. Passou no primeiro e falhou no segundo? Sua rede local funciona, mas a saída não. O link para o provedor caiu ou o roteamento está quebrado. Passou nos dois e falhou no terceiro? É o DNS. Sempre foi o DNS. Avance para o próximo passo. Um cuidado importante que evita diagnóstico errado: muita coisa bloqueia ICMP propositalmente. Servidor que não responde ping pode estar perfeitamente operacional. Vários provedores e firewalls corporativos descartam esse tráfego por política de segurança. Ping que falha em host externo específico não prova quase nada. Porém, ping que falha no seu próprio gateway prova bastante. ## nslookup: Confirmando Que é o DNS Quando você chega aqui, já sabe que a conectividade IP funciona corretamente. O problema agora é traduzir nomes de domínio para números. Isso é tarefa do servidor DNS. “` nslookup empresa.com.br # usa o DNS configurado nslookup empresa.com.br 1.1.1.1 # força um DNS público, para comparar “` Rodar as duas versões é o pulo do gato que separa amadores de profissionais. Se a segunda responde e a primeira não, o problema não é o domínio. É o servidor DNS que sua rede está entregando. Pode ser DNS fora do ar, filtro ativo ou configuração incorreta. Se ambas respondem com endereços diferentes, você achou algo mais complexo: cache obsoleto, registro que mudou recentemente ou um DNS interno respondendo por domínio externo. Quando o registro mudou há pouco, limpe o cache antes de acusar o servidor DNS: “` ipconfig /flushdns # Windows resolvectl flush-caches # Linux com systemd-resolved “` No Linux, o comando `dig` devolve a mesma informação com muito mais detalhe. Vale aprender depois, mas o `nslookup` resolve o dia a dia e existe em ambos os sistemas operacionais. Portanto, foque nele para rotina rápida e diagnóstico ágil. ## tracert: Localizando Exatamente Onde o Caminho Quebra Você já confirmou que pode chegar a um IP externo. Agora descubra onde exatamente a conexão quebra no caminho entre você e o destino final. “` tracert empresa.com.br # Windows traceroute empresa.com.br # Linux “` O traceroute mostra cada salto entre você e o destino final. Serve para responder a pergunta que decide de quem é o problema: quebra dentro de sua casa ou fora dela? Se para no primeiro salto, é seu gateway. Se atravessa sua rede e trava no segundo ou terceiro, já está no provedor. Aí a conversa é outra, com print na mão para suporte técnico. Se chega quase no fim e morre, costuma ser filtro do lado do destino. Dois avisos para não interpretar errado. Saltos com asterisco no meio do caminho não significam falha. Muito roteador simplesmente não responde a esse tipo de sonda e repassa o pacote normalmente. Além disso, latência alta em um salto intermediário também não quer dizer nada sozinha. O que importa é a latência do salto final. Um roteador tratando sonda com baixa prioridade é rotina na internet pública. ## netstat: Confirmando a Porta e o Processo Este é o comando que separa “a rede não funciona” de “esse sistema não funciona”. Se você chegou aqui, a rede está funcionando corretamente. O problema agora é que a aplicação ou serviço não está respondendo. “` netstat -ano | findstr :443 # Windows — mostra o PID na última coluna ss -tulpn | grep :443 # Linux — já mostra o processo “` No Windows, pegue o PID da última coluna e descubra o culpado imediatamente: “` tasklist | findstr 4812 “` Dessa forma você resolve o clássico “a porta 80 já está em uso” quando vai subir um serviço. Quase sempre é outro serviço que ninguém lembrava que estava ligado. Você já tem prova, já sabe qual processo está usando, e pode tomar a decisão correta sem especulação. Para testar uma porta remota sem instalar nada, o PowerShell moderno substitui o velho telnet: “` Test-NetConnection servidor -Port 3389 “` Ele responde separadamente se o host respondeu ao ping e se a porta TCP abriu. Isso mata a ambiguidade de uma vez. Host de pé com porta fechada é firewall ou serviço parado, nunca é rede. ## O Fluxo Completo de Diagnóstico Juntando tudo em sequência, o roteiro é imutável e eficiente. Primeiro, rode ipconfig /all para validar a identidade da máquina na rede. Segundo, execute os três pings em progressão para localizar em qual camada o problema aparece. Terceiro, use nslookup em duas versões para confirmar se o DNS é o culpado. Quarto, rode tracert para determinar se o problema está dentro ou fora de sua infraestrutura. Quinto e final, execute netstat ou Test-NetConnection para isolar se é a aplicação que não funciona. Cinco comandos, três minutos no máximo, e você troca “acho que é a internet” por uma frase técnica precisa. Essa sistemática resolve o chamado ou fecha a conversa com o provedor sem enrolação. Economiza horas por semana em ambientes corporativos e demonstra competência ao usuário final. ## Ferramentas do PratiqueTech Para Aprofundar o Diagnóstico Ao executar o primeiro passo e conferir se a máscara de sub-rede está correta, você pode aproveitar a [Calculadora de Sub-rede](https://pratiquetech.com.br/calculadora-de-subrede/) para visualizar melhor qual faixa de IPs aquele endereço e prefixo cobrem. A ferramenta mostra a visualização em binário, o que facilita entender por que uma máscara incorreta causa os sintomas que você está vendo. Além disso, quando precisar comparar o IP que a máquina acha que tem com o IP que o mundo enxerga externamente, o [Verificador de IP](https://pratiquetech.com.br/verificador-de-ip/) resolve em um clique. A diferença entre os dois confirma se há NAT funcionando ou proxy no meio do caminho. ## Fontes: [Microsoft Learn — ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) [Microsoft Learn — netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) [Microsoft Learn — Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) [man7.org — ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) [RFC 792 — ICMP Specification](https://tools.ietf.org/html/rfc792) —