Monitoramento de sites por tipo de erro: DNS, TCP, TLS e HTTP

Quando um site fica fora do ar, a falha muitas vezes parece uma caixa preta. Os visitantes veem um ícone de carregamento, um código de erro críptico ou uma página em branco. Para as pessoas responsáveis por manter esse site online, a primeira pergunta é sempre a mesma: o que quebrou?

A verdade é que não existe uma única maneira de um site “cair”. Em vez disso, uma requisição de um navegador passa por vários passos—resolução DNS, conexão TCP, negociação TLS e resposta HTTP. Cada etapa depende das anteriores. E em cada etapa, coisas diferentes podem falhar.

Por isso a monitoração inteligente de disponibilidade não apenas diz que o site está “offline”. Ela diz onde na cadeia a falha ocorreu. Erros de DNS apontam para uma coisa. Erros de TCP para outra. Erros de TLS/SSL indicam uma causa raiz diferente dos 5xx de HTTP. Se você souber qual camada falhou, sabe qual equipe ou provedor contatar, e pode reduzir dramaticamente o tempo de resolução.

Este artigo percorre cada tipo de erro na ordem em que um navegador realmente carrega um site: DNS, TCP, TLS e HTTP. Para cada um, explicaremos o que a etapa faz, o que pode dar errado e como a monitoração pode detectar problemas antes dos seus clientes.

Erros de DNS

O DNS é onde toda requisição web começa. Quando um usuário digita seu domínio em um navegador, a primeira coisa que acontece é uma consulta para resolver esse domínio em um endereço IP. Se essa etapa falhar, nada mais importa—nenhuma conexão pode ser estabelecida, nenhum certificado pode ser verificado e nenhuma resposta HTTP chegará. É por isso que erros de DNS costumam ser os sinais mais precoces e críticos de uma interrupção.

Erros comuns de DNS

Abaixo estão algumas falhas comuns de DNS:

• NXDOMAIN — Isso significa que o nome de domínio simplesmente não existe. Na prática, geralmente decorre de registros expirados, zonas mal configuradas ou erros de digitação nas entradas de registro. Um domínio expirado pode tirar todo o seu site do ar instantaneamente, enquanto um registro digitado incorretamente pode impactar apenas um subdomínio ou serviço.
• SERVFAIL — Um erro de servidor que indica que o servidor DNS autoritativo não conseguiu processar a solicitação. Isso frequentemente aponta para arquivos de zona corrompidos, registros glue ausentes ou problemas de validação DNSSEC. SERVFAILs tendem a aparecer de repente após mudanças de configuração, tornando-os um sinal de aviso útil sobre implantações problemáticas.
• Timeouts — Quando nenhuma resposta retorna dentro dos limites esperados, o cliente eventualmente desiste. Timeouts são frequentemente causados por servidores de nomes sobrecarregados, interrupções de rede ou ataques DDoS que saturam o resolvedor. Porque as consultas DNS ocorrem antes do cache entrar em ação, até pequenos picos de latência aqui podem se espalhar e tornar mais lentos os carregamentos de página para sua base de usuários.

Como monitorar DNS

Monitorar a saúde do DNS vai além de verificar se o seu domínio resolve uma vez. Requer testar os caminhos de resolução da forma como os usuários reais os experimentam:

• Verificações globais: Agentes de monitoramento sintético devem executar consultas DNS a partir de múltiplas geografias e redes. Um registro pode resolver normalmente do seu escritório, mas falhar na Ásia ou na América do Sul devido a problemas de roteamento anycast ou a interrupções regionais no seu provedor.
• Consciência do TTL: Cada registro carrega um valor de time-to-live (TTL) que controla o cache. TTLs longos tornam a navegação normal mais rápida, mas podem atrasar a propagação após mudanças. A monitoração deve validar que novos valores realmente se refletem em consultas ao vivo e que não há cache obsoleto persistindo.
• Alertas por anomalias: Os sinais mais acionáveis vêm de tendências. Um aumento repentino nas respostas NXDOMAIN ou SERVFAIL, ou um pico na latência de resolução, costuma ser a primeira pista de que algo está errado—mesmo antes dos clientes começarem a reclamar.

Quando a monitoração de DNS falha, ela também te dá confiança sobre o que não é o problema. Se as consultas não resolvem, então as verificações de TCP, TLS e HTTP nunca foram tentadas. Isso reduz rapidamente o escopo do triagem. Na maioria dos casos, as correções envolvem seu provedor de hospedagem DNS, registrador ou quem gerencia o arquivo de zona. Equipes maduras constroem relações e caminhos de escalonamento com esses fornecedores para que problemas possam ser reportados e resolvidos rapidamente.

Falhas de conexão TCP

Uma vez que o DNS tenha resolvido um endereço IP, o próximo passo é o handshake TCP. Isso é o equivalente digital de um aperto de mãos: o cliente envia um SYN, o servidor responde com SYN-ACK e o cliente reconhece com ACK. Só após esse intercâmbio um canal de comunicação é estabelecido.

Se o TCP falhar, o navegador sabe onde o servidor deveria estar, mas não consegue realmente falar com ele. O resultado parece um buraco negro—páginas travam, sockets nunca abrem e os usuários veem rodas de carregamento intermináveis. Ao contrário dos erros de DNS, que costumam ser rápidos e óbvios, falhas de TCP muitas vezes criam interrupções parciais confusas onde o site está disponível para algumas pessoas, mas não para outras.

Erros comuns de TCP

• Conexão recusada — O cliente alcançou o host, mas nada estava escutando na porta esperada. Isso frequentemente acontece quando serviços caem, contêineres morrem ou balanceadores de carga estão mal configurados. Um servidor web que esqueceu de bindar na porta 443 é invisível mesmo se a máquina em si estiver ok.
• Tempo de conexão esgotado (timed out) — Pacotes estão sendo descartados em algum ponto do caminho. Isso pode ser um firewall bloqueando o tráfego silenciosamente, uma má configuração de roteamento ou congestão upstream. Timeouts são especialmente frustrantes porque não fornecem feedback—apenas silêncio até o cliente desistir.
• Reinício de conexão — Aqui o handshake é completado mas é encerrado quase que imediatamente. Reinícios geralmente apontam para proxies sobrecarregados, timeouts de inatividade agressivos ou middleboxes (como WAFs) terminando o que consideram sessões suspeitas.

Como monitorar TCP

Checagens básicas de disponibilidade não são suficientes aqui. Pings ICMP podem ter sucesso enquanto handshakes TCP falham, dando uma falsa sensação de saúde. Monitoramento TCP adequado foca no comportamento da conexão:

• Validação do handshake: As ferramentas devem tentar explicitamente um intercâmbio SYN/SYN-ACK/ACK na porta real do serviço. Isso garante que o listener é alcançável e responde.
• Análise de caminho: Traceroutes ou MTRs de diferentes regiões podem revelar onde as conexões estão travando—se dentro do seu data center, na borda do seu CDN ou em um ISP upstream.
• Paridade de protocolo: Se você suporta tanto IPv4 quanto IPv6, monitore ambos. Muitos incidentes do mundo real afetam apenas um deles, criando problemas visíveis aos clientes que passam despercebidos se você testar apenas o outro.

O monitoramento TCP fornece confiança de que os servidores não estão apenas vivos, mas prontos para aceitar tráfego. E reduz o escopo do triagem: se o TCP falhar, a resolução DNS já funcionou, então o problema está no host ou no caminho de rede. Essa clareza evita que as equipes persigam pistas erradas na camada de aplicação quando o problema real é uma regra de firewall ou um pool de balanceador que silenciosamente perdeu seu último nó saudável.

Erros de TLS/SSL

Hoje em dia, quase todo site roda em HTTPS (comparado a anos anteriores, quando SSL não era tão comum). Isso significa que, após o handshake TCP, o navegador e o servidor precisam negociar uma sessão TLS (Transport Layer Security). O TLS faz dois trabalhos ao mesmo tempo: cifra os dados em trânsito e prova que o servidor é quem afirma ser por meio de certificados digitais.

Essa confiança traz complexidade. Se certificados expiram, não correspondem ao hostname ou não podem ser validados, os usuários verão avisos do navegador—ou a página se recusará a carregar totalmente. Na prática, erros de TLS são alguns dos incidentes mais visíveis e embaraçosos que um site pode ter, porque impedem os usuários na porta com um alerta que não podem contornar com segurança.

Erros comuns de TLS/SSL:

• Certificado expirado — A janela de validade do certificado expirou. Esse é um dos desligamentos mais comuns porque não há automação na renovação ou a renovação não foi propagada para todos os pontos.
• Incompatibilidade de hostname — O certificado foi emitido para www.example.com, mas o usuário visitou api.example.com. Isso costuma ocorrer após adicionar novos subdomínios ou mover serviços para trás de um CDN.
• Autoridade certificadora não confiável — O navegador não reconhece a CA emissora, normalmente porque o certificado foi autoassinado ou encadeado a uma raiz privada não instalada nos dispositivos clientes.
• Falha no handshake — A própria negociação criptográfica falha. As causas variam desde suítes de cifra não suportadas, versões de protocolo obsoletas ou uma cadeia de certificados corrompida.

Como monitorar TLS:

O monitoramento de TLS precisa ser proativo e contínuo. Certificados não falham de forma gradual—funcionam em um dia e bloqueiam o acesso no seguinte. Uma boa monitoração deve:

• Monitorar a validade do certificado e disparar alertas bem antes do vencimento—idealmente com múltiplos limiares (30 dias, 7 dias, 1 dia).
• Validar a cadeia completa de certificados a partir de múltiplas regiões, já que intermediários faltantes ou problemas regionais com CAs podem quebrar a confiança de maneiras diferentes ao redor do mundo.
• Verificar o suporte a protocolos e cifras, garantindo que o site continue compatível conforme os navegadores deprecam versões antigas como TLS 1.0 e 1.1.
• Observar picos de erros de handshake, que frequentemente coincidem com configurações incorretas de balanceadores de carga ou rollouts em CDNs.

Quando falhas de TLS aparecem na monitoração, elas também fornecem contexto: a resolução DNS funcionou, a conectividade TCP estava ok, mas o canal seguro não pôde ser estabelecido. Isso reduz imediatamente o escopo do troubleshooting. A correção geralmente está no âmbito da renovação de certificados, configuração do balanceador de carga ou terminação na borda, não no código da aplicação.

Para muitas equipes, a lição operacional é simples: trate certificados como código. Automatize emissão e renovação, monitore a expiração com a mesma agressividade com que monitora o espaço em disco e ensaie rotações para que certificados expirados nunca se tornem interrupções públicas graves.

Erros HTTP

Finalmente, depois que DNS, TCP e TLS têm sucesso, o navegador envia uma requisição HTTP. O servidor responde com um código de status HTTP—200 se tudo estiver bem, ou um código de erro se não.

Monitorar HTTP é o que a maioria das pessoas pensa quando imagina “monitoramento de disponibilidade”. Mas sem o contexto das etapas anteriores, os erros HTTP só contam parte da história.

Erros HTTP comuns:

• 404 Not Found – O recurso não existe. Isso pode ser um link quebrado, página deletada ou requisição mal roteada.
• 500 Internal Server Error – O servidor encontrou uma condição inesperada. Normalmente bugs de código ou de configuração.
• 502 Bad Gateway – Um proxy ou balanceador de carga não conseguiu obter uma resposta válida de um servidor upstream.
• 503 Service Unavailable – O servidor está sobrecarregado ou em manutenção.
• 504 Gateway Timeout – Um serviço upstream demorou demais para responder.

Como monitorar HTTP:

• Execute requisições sintéticas GET a partir de agentes globais para verificar respostas.
• Capture códigos de resposta e alerte sobre qualquer coisa fora do intervalo 200–299.
• Monitore fluxos de transação, não apenas páginas isoladas (login, depois adicionar ao carrinho, depois checkout).
• Defina limiares para o tempo de resposta, não apenas para a disponibilidade.

O monitoramento HTTP indica que a camada de aplicação está com problemas. Ao contrário dos problemas de DNS/TCP/TLS, erros HTTP geralmente estão sob responsabilidade das equipes de desenvolvimento ou operações, não de provedores externos.

Juntando tudo: Uma estratégia de monitoramento em camadas

O valor de separar os erros por tipo é a clareza. Cada falha ocorre em sequência. Se o DNS falhar, nada mais acontece. Se o TCP falhar, o DNS estava ok. Se o TLS falhar, DNS e TCP funcionaram. Se o HTTP falhar, tudo até aquele ponto funcionou.

Uma abordagem de monitoração em camadas espelha essa sequência:

1. Comece com checagens de DNS.
2. Adicione monitoramento de conexão TCP.
3. Sobreponha monitoramento de certificados TLS.
4. Finalize com monitoramento de respostas HTTP.

Esse modelo em camadas permite identificar a causa raiz rapidamente:

• Erro de DNS? Ligue para seu provedor de DNS.
• Erro de TCP? Acione seu provedor de hospedagem ou ISP.
• Erro de TLS? Corrija seu certificado ou a configuração da borda.
• Erro de HTTP? Converse com sua equipe web.

Em vez de um alerta vago de “o site está caído”, você obtém um mapa preciso do que quebrou e quem deve consertar. Isso reduz o tempo médio de resolução (MTTR) e evita que as equipes se acusem mutuamente.

Conclusão

Sites não falham de uma única maneira—eles falham em camadas. DNS, TCP, TLS e HTTP introduzem cada um seus próprios riscos e suas próprias assinaturas de erro. Monitorar por tipo de erro transforma essa complexidade em clareza.

Com a estratégia de monitoração certa (e uma ferramenta como Dotcom-Monitor), você não apenas sabe que o site está caído: você sabe por que ele está caído. Sabe se deve escalar para seu host DNS, provedor de rede, equipe de segurança ou desenvolvedores. E obtém essa visibilidade rápido, sem esperar por um ticket de suporte ou pela reclamação de um cliente.

No fim, monitorar por tipo de erro não é apenas sobre disponibilidade. É sobre responsabilidade e velocidade. Na próxima vez que seu site falhar, não se contente com “algo quebrou”. Saiba exatamente qual camada falhou, o que isso significa e como consertar.