This content originally appeared on DEV Community and was authored by Marcos Vilela
Recentemente, enfrentei um incidente real em produção que afetou múltiplas aplicações hospedadas em um ambiente cloud. Entre os serviços fora do ar estavam aplicações web e um app de comunicação interna. Neste post, compartilho o processo de troubleshooting de rede realizado, com foco em comandos práticos e análise objetiva de sintomas para diagnosticar falhas externas.
Sintomas iniciais
Por volta das 18h17, começaram os relatos no grupo da equipe:
- Múltiplos sites fora do ar
- Erro 523 (indicando falha de conexão entre servidor e edge)
- App de comunicação interna inacessível
- Alguns sites funcionando via cache
Apesar disso, o SSH nos servidores seguia acessível normalmente.
Primeiros testes: conectividade externa
Assim que acessei o servidor, executei os comandos básicos de verificação:
ping google.com
Resultado:
❌ Hostname não resolve
ping 8.8.8.8
Resultado:
✅ Ping responde
Interpretação: O servidor está com conectividade externa por IP, mas não consegue resolver nomes DNS. O foco passa a ser DNS e conectividade para fora.
Testes adicionais
Teste de DNS
dig google.com
ou
nslookup google.com
Resultado:
❌ Timeout — sem resposta do servidor DNS
Traceroute
traceroute google.com
Resultado:
❌ Interrompido nos primeiros saltos
IPv6
ping6 google.com
Resultado:
❌ Sem resposta — sem saída para IPv6
Hipóteses levantadas
- Falha nos servidores DNS ou rota de saída para DNS
- Queda parcial de rota de saída IPv4/IPv6
- Acesso interno normal, mas tráfego externo bloqueado ou degradado
Diagnóstico resumido
- Servidores estão ativos (SSH acessível, CPU/memória ok)
- Aplicações fora do ar devido à falha de saída de rede
- DNS externo e IPv6 indisponíveis
- IPv4 direto funcional
- Sintomas indicam falha fora da stack local, com fortes indícios de problema na camada de rede do provedor
Ação imediata
Foi aberto um ticket com o suporte da infraestrutura cloud informando:
- Perda de resolução DNS
- Queda de IPv6
- Tráfego externo comprometido
- Logs dos testes com
ping,dig,tracerouteemtr
Lições aprendidas
✅ Sempre teste por IP e por nome (hostname)
✅ Verifique se o problema é local ou externo com comandos básicos
✅ Monitore IPv6, mesmo que a aplicação não o utilize diretamente
✅ Tenha logs rápidos para agilizar comunicação com o suporte técnico
Checklist de comandos para troubleshooting de rede
ping -c 4 8.8.8.8 # Teste de conectividade externa via IPv4
ping google.com # Teste de resolução DNS
dig google.com # Verifica resposta de DNS
traceroute google.com # Trajeto da rede até o destino
ping6 google.com # Teste de conectividade IPv6
curl -v https://site.com # Verifica conexão HTTPS com verbose
mtr -rwzbc100 google.com # Teste completo de rede com perda de pacotes
Conclusão
Problemas de rede em cloud nem sempre estão no seu servidor ou aplicação. Ter um processo claro de troubleshooting e saber diferenciar problemas internos de externos é fundamental para qualquer pessoa que atua com infraestrutura, DevOps ou SRE. A solução do provedor foi realizar a migração da VM para outro host com configurações de rede corretas.
Esse caso reforça a importância de:
- Observar padrões (IPv4 vs IPv6)
- Validar DNS isoladamente
- Ter evidências técnicas para dialogar com o suporte do provedor
This content originally appeared on DEV Community and was authored by Marcos Vilela
Marcos Vilela | Sciencx (2025-06-10T03:34:00+00:00) Troubleshooting de redes em servidores cloud: como identifiquei um problema externo na conectividade. Retrieved from https://www.scien.cx/2025/06/10/troubleshooting-de-redes-em-servidores-cloud-como-identifiquei-um-problema-externo-na-conectividade/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.