"O Site Foi Abaixo!" — O Método de Diagnóstico de Rede no Linux em 5 Comandos (dig, curl -v, ss, nc e tcpdump)

O Caos de uma Avaria: Porque os Amadores Adivinham e os Engenheiros Diagnosticam

São 14:15 de uma terça-feira. Os canais de comunicação interna da empresa enchem-se de alertas com letras maiúsculas: “O SITE PRINCIPAL ESTÁ EM BAIXO! OS CLIENTES NÃO CONSEGUEM FINALIZAR COMPRAS!”

Em equipas sem rotinas de diagnóstico consolidadas, instala-se o desespero. Começa a roleta dos palpites:

• “Reinicia já o Nginx a ver se resolve!”
• “Será que alguém mudou a senha da base de dados?”
• “Vamos reiniciar o servidor virtual inteiro!”
• “A Cloudflare ou a Amazon devem estar com problemas mundiais!”

Reiniciar serviços às cegas e reiniciar máquinas sem critério não é engenharia; é adivinhação. Esse método destrói pistas cruciais na memória do kernel, apaga as filas de espera que explicavam a falha e quase sempre prolonga o tempo de paragem do teu negócio.

O MÉTODO DETERMINÍSTICO DE DIAGNÓSTICO EM 5 PASSOS

• “O SITE ESTÁ EM BAIXO!”
• PASSO 1: CAMADA DNS: dig +trace api.oteusite.com O domínio resolve para o IP correto?
• PASSO 2: APLICAÇÃO E TLS: curl -Iv https://api.oteusite.com/healthz
• O SSL fecha? Qual é o código HTTP devolvido?
• PASSO 3: SOCKETS LOCAIS: ss -tulpn | grep -E “80|443”
• O Nginx está mesmo à escuta na porta?
• PASSO 4: TESTE DE PORTA: nc -zv 192.168.1.50 443
• A firewall interna deixa passar pacotes TCP?
• PASSO 5: CAPTURA DE REDE: tcpdump -nn -i eth0 port 443
• Os pacotes chegam e recebem resposta?

Perante um incidente, precisas de um fluxo linear e disciplinado que te diga com rigor matemático onde está a falha em menos de 180 segundos.

No nosso serviço de alojamento gerido e nas intervenções de manutenção preventiva, aplicamos este protocolo com cinco ferramentas nativas em servidores com Debian GNU/Linux.

Passo 1: Validação do DNS com o Comando dig

A maior parte das “quebras de servidor” não são avarias de servidor—são falhas de DNS. Um domínio que expirou no registador, uma entrada de DNS apagada por engano ou uma assinatura de DNSSEC que caducou.

Faz um Rastreio Completo da Raiz

Não confies no DNS da tua ligação de casa ou escritório, que guarda respostas antigas em cache. Pergunta diretamente à hierarquia mundial com o dig:

# Percorre a cadeia de DNS desde os servidores raiz até aos teus nameservers
dig +trace api.oteusite.com

EXEMPLO DE RESPOSTA DO RASTREIO DO DIG

• . 518400 IN NS a.root-servers.net. com. oteusite.com.
• 172800 IN NS a.gtld-servers.net.: 172800 IN NS ns1.cloudflare.com. api.oteusite.com. 300 IN A 203.0.113.80
• ;; Resposta de 240 bytes recebida de ns1.cloudflare.com em 14 ms

O Que Procurar na Resposta:

• Se vires SERVFAIL, as chaves de assinatura do DNSSEC estão desfasadas ou corrompidas.
• Se vires NXDOMAIN, o subdomínio não existe ou foi apagado.
• Se vires um endereço IP antigo, alguém alterou a zona de DNS por engano.

Passo 2: Testar o Handshake e Cabeçalhos HTTP com o curl -v

Com a certeza de que o domínio aponta para o IP certo, testas o protocolo HTTP e a negociação TLS com o curl em modo detalhado:

# Inspeciona a troca de chaves TLS e os cabeçalhos sem descarregar o site todo
curl -Iv https://api.oteusite.com/healthz

ANÁLISE DETALHADA DA RESPOSTA DO CURL

• Connected to api.oteusite.com (203.0.113.80) port 443 → [TCP Aberto!]
• ALPN: server accepted h2
• HTTP/2 Ativo
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 → [TLS Válido]
• Server certificate: CN=api.oteusite.com, valid to 2026-12-15 → [Certificado OK]

• GET /healthz HTTP/2

• Host: api.oteusite.com < HTTP/2 502 Bad Gateway

• A PISTA REAL!
• < server: nginx/1.24.0

Como Ler o Diagnóstico:

Repara com atenção nas linhas:

1. O socket TCP abriu sem problemas na porta 443.
2. O certificado SSL foi validado e o TLS 1.3 negociou com sucesso.
3. O servidor Nginx devolveu 502 Bad Gateway.

A Conclusão: O teu servidor físico está impecável, a rede está rápida e o Nginx está a funcionar. O problema é que a tua aplicação em Node.js ou PHP caiu ou deixou de responder na porta interna 3000. Não mexas no Nginx; vai investigar o serviço da aplicação!

Passo 3: Inspecionar as Portas Locais com o Comando ss

Entra por SSH no teu servidor. O processo da tua aplicação está mesmo a correr ou morreu com um erro de código?

Não uses o comando antigo netstat. Usa o ss (Socket Statistics):

# Lista todos os processos em escuta em portas TCP com o respetivo PID
ss -tulpn

EXEMPLO DO ESTADO DE SOCKETS COM O COMANDO SS

• Netid Estado Recv-Q Send-Q Endereço Local:Porta Endereço Remoto Processo tcp LISTEN 0 511 0.0.0.0:80 tcp LISTEN 0 511 0.0.0.0:443
• 0.0.0.0:* users:((“nginx”,pid=1420)): 0.0.0.0:* users:((“nginx”,pid=1420)) tcp LISTEN 128 128 127.0.0.1:3000 0.0.0.0:* users:((“node”,pid=89412))

O Que Deves Analisar com Cuidado:

• Endereço Local:Porta: Repara em 127.0.0.1:3000. O Node.js está amarrado apenas à interface local. Se o Nginx tentar reencaminhar pedidos para o IP da rede privada 192.168.1.50, a ligação é recusada!
• Recv-Q (Fila de Receção): Se o valor de Recv-Q estiver colado ao Send-Q (ex: 128 128), a fila de espera do processo está totalmente cheia. O teu programa entrou num ciclo infinito ou bloqueou a thread principal e não consegue aceitar mais clientes!

Passo 4: Validar a Passagem de Firewall com o netcat (nc)

Se o teu serviço está ativo na máquina de backend, mas o servidor web diz que não consegue falar com ele pela rede interna, deves testar a porta com o nc (Netcat):

# Testa se a porta 3000 aceita ligações TCP com timeout de 2 segundos
nc -zv -w 2 10.0.0.15 3000

O Que Cada Resposta Te Diz:

• Connection to 10.0.0.15 3000 port [tcp/*] succeeded!
  A rota de rede está aberta e o serviço respondeu imediatamente.
• nc: connect to 10.0.0.15 port 3000 (tcp) failed: Connection refused
  O pacote chegou à máquina de destino, mas não há nenhum programa à escuta naquela porta.
• nc: connect to 10.0.0.15 port 3000 (tcp) timed out
  Bloqueio de firewall! O pacote foi descartado silenciosamente por regras de nftables, UFW ou grupos de segurança na nuvem.

Passo 5: A Prova dos Factos: Captura de Pacotes com tcpdump

Quando todas as outras ferramentas deixam dúvidas, a verdade indiscutível está nos pacotes que viajam pelo cabo de rede. O tcpdump mostra-te o que realmente passa na placa:

# Captura 20 pacotes na interface eth0 na porta 443 sem resolver nomes
tcpdump -nn -c 20 -i eth0 port 443

A CAPTURA DO THREE-WAY HANDSHAKE NO CABO

• 14:20:01.102 IP 198.51.100.12.54210 > 203.0.113.80.443: Flags [S], seq 1000
• 14:20:01.102 IP 203.0.113.80.443 > 198.51.100.12.54210: Flags [S.], seq 5000, ack 1001
• 14:20:01.144 IP 198.51.100.12.54210 > 203.0.113.80.443: Flags [.], ack 5001

Os Três Cenários Típicos:

1. Comportamento Normal: Vês Flags [S] (SYN do cliente), logo a seguir Flags [S.] (SYN-ACK do teu servidor) e depois Flags [.] (ACK final). A ligação abriu com sucesso.
2. Porta Fechada: O cliente envia Flags [S] e o teu servidor responde de imediato com Flags [R.] (RST/ACK). O kernel rejeita a ligação porque a porta não está aberta.
3. Buraco Negro: O cliente repete Flags [S] a cada 3 segundos e o teu servidor nunca responde com SYN-ACK. Uma firewall descartou o pacote ou a tabela de rotas do servidor está a enviar a resposta pelo gateway errado.

Cartão de Consulta Rápida: Resolução em 3 Minutos

Guarda este resumo na tua pasta de procedimentos operacionais:

Ao seguires este fluxo disciplinado de 5 passos, transformas incidentes caóticos em diagnósticos frios e rigorosos. Apoiando a tua equipa na nossa consultoria técnica e no princípio de anti-over-engineering, resolves falhas com as ferramentas padrão que já existem em qualquer distribuição Linux. Podes ainda consultar ferramentas comunitárias de automação no GitHub para acelerar o processo de resposta a incidentes.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.