Site Fora do Ar, mas o Servidor Está Acessível? Rastreie a Falha de DNS para App

“SSH Funciona, o Site Não” — Comece com a Pergunta Certa

Os alertas começam a disparar, os utilizadores dizem que o site está morto, e o seu primeiro teste lhe dá um tipo estranho de alívio: SSH ainda o deixa entrar. Esse momento parece reconfortante porque o servidor não desapareceu. Mas é também onde muita resolução de problemas ruim começa, porque “ainda consigo fazer login” não é a mesma coisa que “o website deveria estar funcionando.”

A pergunta útil não é “o que posso reiniciar primeiro?” É “qual camada falhou primeiro?” Uma sessão SSH funcionando prova que a máquina é alcançável na porta 22. Não prova que o domínio resolve corretamente. Não prova:

• as portas 80 e 443 são alcançáveis
• HTTPS está saudável
• a aplicação atrás do servidor web está respondendo

Este guia é construído em torno dessa distinção, e mantém o foco no diagnóstico em vez de tentar tornar-se um manual completo de nginx, DNS, TLS, Docker, ou base de dados.

⚠️ Aviso: Reiniciar cegamente nginx, Docker, PHP-FPM, ou todo o VPS nos primeiros minutos de um incidente pode apagar as pistas que precisa. Recolha uma ronda de evidência primeiro, depois mude apenas a camada que realmente falhou.

O Mapa de Triagem de Um Minuto

Antes de aprofundar, oriente-se. A forma da falha muitas vezes diz qual camada merece atenção primeiro, mesmo quando você ainda não conhece a causa raiz.

Trate a tabela seguinte como um atalho de triagem, não como um veredicto final.

O que importa é o primeiro estágio quebrado. Se DNS falhar, as camadas posteriores são ruído. Se 443 responder mas TLS quebrar, a app ainda não é sua primeira questão. O modelo mental abaixo é o que torna essa sequência lógica em vez de aleatória.

Por que SSH não prova que o site funciona

SSH e tráfego web são caminhos diferentes com trabalhos diferentes. SSH na porta 22 prova que você pode alcançar a máquina através de sua porta de gerenciamento remoto. Um site depende das portas 80 e 443, além das camadas por trás delas. Esses são testes separados, então “servidor alcançável” e “site alcançável” não são declarações intercambiáveis.

A forma mais fácil de visualizar é como um edifício de escritórios. DNS ajuda um visitante a encontrar o endereço do edifício. As portas 80 e 443 são a recepção para visitantes públicos. O servidor web é o recepcionista que aceita a solicitação e decide para onde ela vai a seguir. A aplicação é o escritório que faz o trabalho real. Um banco de dados ou outra dependência pode estar mais dentro do edifício. SSH é uma entrada completamente diferente. É útil para a equipe, mas não prova que a recepção está aberta ou que o encaminhamento do escritório funciona.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Quando as pessoas dizem que um serviço está “escutando”, elas querem dizer que ele está realmente aceitando conexões no endpoint esperado. Essa é a distinção que transforma um vago momento “o servidor está ativo” em um caminho de solicitação rastreável.

Isso importa porque HTTPS pode falhar antes da aplicação responder, e falhas de proxy ou aplicação podem acontecer depois que o frontend já está alcançável. Então o próximo passo é sempre o mesmo: olhe de fora primeiro e encontre o último estágio bem-sucedido da solicitação.

Passo 1: Reproduzir a Falha de Fora do Servidor

Comece pelo lado do cliente, não de dentro do VPS. Se possível, teste a partir de outra rede ou dispositivo primeiro para não confundir uma cache DNS local, uma entrada antiga em /etc/hosts, ou um problema de firewall/VPN local com uma verdadeira falha do servidor.

Use uma solicitação externa detalhada para que possa ver até onde a solicitação chega antes de falhar:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v não é uma ferramenta apenas para especialistas aqui. Leia-a como um rastreamento de progresso. Se nunca resolver o nome, você está no ramo DNS. Se conectar e depois disser Connection refused, o host respondeu mas nada útil está aceitando tráfego lá. Se ficar pendurado até o timeout, pense em filtragem, roteamento, ou um travamento mais profundo depois no caminho da solicitação. Se receber uma resposta HTTP, mesmo uma página de erro, você já passou da camada de conexão e entrou em um ramo superior.

💡 Dica: Compare IPv4 e IPv6 cedo. Um registro AAAA esquecido pode fazer a falha parecer inconsistente porque alguns clientes preferem IPv6 primeiro e outros não.

Execute o mesmo teste uma vez por família de protocolo quando dual stack estiver em jogo:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Se IPv4 funciona e IPv6 falha, ou o contrário, você já estreitou o incidente mais rápido do que um reinício de serviço jamais faria. Se a falha começar na resolução de nome ou na escolha de destino, DNS é o próximo ramo limpo a verificar.

Passo 2: Verificar DNS e Confirmar o Destino Correto

Antes de depurar nginx, confirme que o domínio está realmente enviando visitantes para o servidor que você acha que é. Isso é especialmente importante após migrações, mudanças de IP, ajustes de CDN ou edições parciais de registos.

Verifique primeiro os registos públicos:

dig +short A example.com
dig +short AAAA example.com

Estas duas linhas respondem a uma questão muito prática: onde a internet acredita que example.com está agora? Uma forma comum de falha é que SSH por IP alcança o novo VPS, mas o domínio ainda aponta para o endereço antigo. Outra é que o registo A foi atualizado, mas o registo AAAA ainda aponta para algo desatualizado. Nesse caso, apenas parte do seu tráfego falha.

📝 Nota: curl --resolve é mais seguro do que alterar DNS público durante um incidente. Permite-lhe testar a origem que pretende utilizar mantendo o nome de anfitrião e SNI intactos.

Use curl --resolve para forçar um teste contra o IP que espera sem tocar nos registos públicos:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Se isso funcionar enquanto o domínio público ainda falha, o servidor pode estar bem e DNS pode ainda ser a camada quebrada. Uma nota de CDN limitado vale a pena manter em mente aqui. Se a sua origem está bloqueada para aceitar tráfego apenas de intervalos de IP de CDN, um teste de origem direta pode falhar simplesmente porque a origem espera tráfego de borda, não pedidos públicos arbitrários. Uma vez que o destino é confirmado, a próxima questão é se algo útil está a responder em 80 ou 443 aí.

Passo 3: Verificar O Que Está À Escuta nas Portas 80/443

Agora mude para o servidor e faça uma pergunta específica: algo está realmente a aceitar ligações web nas portas esperadas? A máquina pode estar ativa, SSH pode funcionar e nginx pode até estar instalado. Ainda assim, as portas web públicas podem não ter nenhum listener útil.

Verifique os listeners primeiro:

sudo ss -ltnp

Saída vazia para :80 ou :443 significa que nada útil está à escuta. Um listener em 127.0.0.1 significa que o serviço está a aceitar ligações apenas da máquina local. Um listener em 0.0.0.0 significa que está vinculado nas interfaces IPv4. [::] geralmente significa interfaces IPv6. Não assuma que a vinculação IPv6 garante automaticamente o caminho IPv4 que precisa.

Depois use um pequeno pacote de verificação de saúde nginx antes de alterar nada:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Se systemctl diz active (running), isso apenas prova que o processo do serviço existe
• nginx -t diz-lhe se a configuração é válida
• journalctl mostra se um recarregamento recente falhou, um ficheiro de certificado desapareceu ou um vhost quebrou no arranque.

Para leitores Apache, a sintaxe de verificação equivalente é apachectl configtest. Depois de saber que algo está à escuta, a próxima prova é mais específica: o site correto responde localmente quando remove a rede externa da equação?

💡 Dica: Teste a configuração primeiro, depois prefira reload em vez de um reinício cego quando apropriado. Um recarregamento valida a nova configuração e mantém os workers antigos se a nova configuração for má; um reinício cego é muito mais agressivo no meio de um incidente.

Passo 4: Teste o Site Localmente com o Host e SNI Corretos

Este é o fork mais importante em toda a investigação. Um simples curl 127.0.0.1 pode ser enganoso. Muitos servidores alojam múltiplos sites e escolhem a resposta com base no cabeçalho Host ou, para HTTPS, SNI. Você não está perguntando se algo responde localmente. Você está perguntando se o caminho correto do site responde localmente.

Use testes locais que preservem a lógica do hostname:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Um sucesso significativo é a página esperada, redirecionamento esperado ou resposta de aplicação esperada do site correto. Não é o host padrão nginx, o certificado errado ou um “retornou HTML” genérico. A partir daqui há três resultados limpos: sucesso local, comportamento de site errado ou certificado padrão local, ou falha/timeout local. Um bom resultado local aponta para fora para verificações de firewall, provedor, CDN ou roteamento. Um resultado local ruim mantém você dentro da stack, nos ramos upstream ou TLS.

Passo 5: Se Funcionar Localmente mas Não Externamente, Rastreie o Caminho da Rede

Assim que o teste local funcionar bem, pare de questionar nginx por um momento. A pilha do site provavelmente está viva no servidor, e a peça que falta geralmente fica em algum lugar entre o visitante e esse serviço local funcionando. Comece com o firewall do host porque é o limite externo mais próximo que você controla.

Inspecione as regras do lado do host com a ferramenta que seu sistema realmente usa, e faça uma verificação rápida de sanidade para bloqueio auto-infligido enquanto estiver lá:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Essa saída mostra apenas a camada do SO convidado. Ela não mostra filtragem do lado do provedor, grupos de segurança ou regras de firewall em nível de painel que vivem fora do VPS em si. Em um VPS AlexHost, por exemplo, o firewall da máquina e quaisquer controles de rede em nível de painel são questões separadas. Ambos importam quando testes locais funcionam mas visitantes públicos ainda falham.

⚠️ Aviso: Se Docker publica portas no host, não assuma que a saída UFW conta toda a história. Docker pode rotear tráfego de contêiner publicado através de NAT antes das cadeias usuais do UFW. Isso significa que “UFW parece bem” nem sempre significa que o caminho do pacote está bem.

CDNs e balanceadores de carga merecem seu próprio ramo aqui também. A origem pode estar saudável e ainda ser inacessível diretamente porque apenas intervalos de IP de borda podem se comunicar com ela. Quando você precisa de prova de se os pacotes chegam, use tcpdump como uma ferramenta sim-ou-não:

📝 Nota: Um teste de origem direta falhado atrás de uma lista de permissões de CDN geralmente aponta para a política de borda, não para uma origem morta. Nessa configuração, a origem é projetada para confiar no caminho da CDN, não em cada visitante direto.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Se você não vir pacotes SYN em absoluto, o tráfego não está chegando ao servidor. Se SYNs chegam e nenhum SYN-ACK sai, o servidor ou o caminho do firewall ainda está bloqueando a transferência. Se nenhum padrão parecer ser o bloqueador, as falhas restantes geralmente ficam atrás do frontend na transferência upstream.

Passo 6: Se o Frontend Responde mas o Site Ainda Está Quebrado, Siga o Upstream

Neste ramo, o servidor web é alcançável, mas o próximo salto atrás dele não está saudável o suficiente para completar a solicitação. Aqui, “upstream” significa o serviço para o qual nginx passa a solicitação em seguida: um processo de aplicação, um runtime apoiado por socket, um container, ou outra dependência interna.

Páginas estáticas funcionando enquanto login, busca, checkout, ou rotas de API falham é um forte indício de que o frontend está presente e a falha começa no handoff atrás dele.

📝 Nota: Trate 502 como “o próximo salto respondeu mal” e 504 como “o próximo salto respondeu muito lentamente.” Ambos são sinais para seguir o caminho upstream em vez de parar no frontend.

Inspecione o handoff ativo, depois teste o upstream diretamente:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

Na saída do nginx, procure por diretivas como proxy_pass, fastcgi_pass, ou uwsgi_pass. Você está verificando se nginx está apontando para o alvo correto, sobre o protocolo correto, na porta ou socket correto. Se containers estiverem envolvidos, adicione uma verificação curta de saúde do container em vez de adivinhar:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Se o teste direto da aplicação falhar, o problema está atrás do servidor web. Se funcionar diretamente mas falhar através do nginx, a configuração do handoff é o ramo a inspecionar. A acessibilidade do banco de dados importa apenas como uma verificação de dependência aqui, não como um deep-dive separado. Se este padrão de falha upstream continuar se repetindo, esse é o momento certo para mudar para um guia de troubleshooting dedicado em vez de estender um incidente em adivinhação.

Passo 7: Isolar Falhas de TLS e Certificados

Este ramo é mais estreito: algo está respondendo na porta 443, mas o navegador ainda não consegue completar uma sessão HTTPS limpa e confiável. Uma conexão TCP bem-sucedida à porta 443 não prova que o certificado, correspondência de hostname ou caminho de handshake estejam saudáveis.

Inspecione qual certificado está sendo servido:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

É aqui que você captura as formas de falha comuns: hostname errado, certificado expirado, cadeia incompleta ou renovação que nunca terminou corretamente. Em linguagem simples, SNI diz ao servidor qual hostname você pretendia. -verify_hostname verifica se o certificado que serviu corresponde a esse hostname. Após a recuperação, valide o caminho de renovação para que isso não se torne o próximo incidente:

⚠️ Aviso: Se você depender da validação HTTP-01 para renovação de certificado, a porta de entrada 80 deve estar acessível. Uma regra de firewall ou provedor bloqueando 80 pode quebrar silenciosamente renovações muito antes de os utilizadores reportarem que HTTPS parece morto.

sudo certbot renew --dry-run

Passo 8: Verificar Pressão de Recursos Antes de Chamar Aleatório

Alguns incidentes não são falhas de alcançabilidade. O caminho está tecnicamente intacto, mas o servidor está muito faminto, bloqueado ou sobrecarregado para responder a tempo. É quando um site pode parecer “parcialmente vivo” de um ângulo e ainda parecer morto para os utilizadores.

Execute um pequeno pacote de primeira passagem de recursos:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Leia os resultados em padrões, não isoladamente.

• df -h mostra esgotamento ordinário de disco.
• df -i detecta esgotamento de inode, onde o espaço parece existir mas o sistema de ficheiros não consegue criar mais entradas.
• free -h importa mais quando a memória disponível colapsa e a atividade de swap aumenta.
• uptime pode mostrar carga alta mesmo quando a CPU não está no máximo, o que muitas vezes significa que as tarefas estão à espera de pressão de disco ou memória em vez de computação ativa.
• Linhas de registo do kernel sobre eventos OOM dizem-lhe se o sistema começou a matar processos para sobreviver.

Os gráficos do fornecedor podem confirmar a cronologia. Num VPS AlexHost, podem ser úteis para verificar se picos em RAM, disco ou I/O se alinham com a indisponibilidade. Mas a evidência do terminal deve ainda liderar o diagnóstico. Esta secção não é um guia de otimização; é o ramo que lhe diz que o site pode estar a falhar sob pressão em vez de falhar ao encaminhar.

Pense em Camadas, Não em Pânico

Quando SSH funciona mas o website não abre, mantenha a cadeia curta e repetível:

1. reproduza a falha externamente
2. identifique o último estágio bem-sucedido
3. confirme DNS e destino
4. verifique um listener real em 80/443
5. teste o site correto localmente
6. ramifique para caminho de rede, upstream, TLS ou recursos

💡 Dica: Não feche sua última sessão SSH funcionando até ter confirmado que um login recente ainda funciona e que ainda tem um caminho de acesso de backup, como acesso à consola do fornecedor. Durante um incidente em direto, preservar o controlo é tão importante quanto corrigir o primeiro sintoma.

Mantenha hábitos leves: monitorize externamente, guarde registos e teste certificados com certbot renew –dry-run. Proteja o acesso com backups e um caminho de consola. As ferramentas do fornecedor — firewall, gráficos, consola (incluindo AlexHost) — devem apoiar a resolução de problemas, não substituí-la. Concentre-se em corrigir a primeira camada quebrada para que cada incidente seja tratado com evidência mais clara e menos pânico.