ERR_CONNECTION_TIMED_OUT

O que este erro significa e como reconhecê-lo

• O navegador exibe uma mensagem como “Não é possível acessar este site” com ERR_CONNECTION_TIMED_OUT.
• A falha aparece após uma espera perceptível, em vez de imediatamente.
• O hostname funciona em uma rede, mas expira em outra.
• As solicitações ao endereço público do servidor também podem expirar enquanto o console de hospedagem ainda mostra a instância como em execução.
• O problema afeta muitos visitantes quando o host, a interface de rede, a rota ou a rede upstream está indisponível.
• Um servidor sob forte pressão de CPU, memória, processos ou conexões pode continuar ligado, mas não conseguir concluir novas conexões rapidamente.
• Uma CDN, um reverse proxy ou um load balancer pode estar acessível enquanto a conexão dele com a origem expira.

Causas principais, por probabilidade

1. O host ou a interface de rede está inacessível — o servidor, a VM, a interface de rede, a rota ou a rede upstream pode estar indisponível.
2. Um firewall ou security group descarta o tráfego silenciosamente — uma regra de descarte normalmente causa um timeout, enquanto uma rejeição explícita geralmente falha mais rápido.
3. O servidor está sobrecarregado — o esgotamento de recursos, os limites de processos ou o excesso de conexões abertas podem impedir a conclusão do handshake TCP ou da resposta da aplicação.
4. O DNS aponta para o destino errado — o hostname pode resolver para um endereço antigo, um endereço inacessível ou uma infraestrutura que não atende mais ao site.
5. O caminho de rede do visitante está interrompido — um problema de roteamento do ISP, uma VPN, um proxy, um firewall local ou um dispositivo de filtragem pode bloquear o acesso a partir de uma rede.
6. O IPv6 está configurado incorretamente — um registro AAAA inutilizável pode causar falhas em redes que preferem IPv6, mesmo quando o serviço IPv4 funciona.
7. Uma CDN, um reverse proxy, um load balancer ou uma camada de proteção upstream está configurada incorretamente — o front-end pode não conseguir alcançar a origem mesmo que a própria origem esteja em execução.

Como corrigir

1. Teste a partir de uma segunda rede

Abra o site usando dados móveis ou outra conexão não relacionada. Se uma VPN ou um proxy estiver ativo, teste sem ele quando permitido.

• Funciona na segunda rede: investigue o Wi-Fi original, a rota do ISP, o firewall local, a VPN, o proxy ou o dispositivo de filtragem.
• Expira em todas as redes: continue com as verificações de DNS, servidor, firewall e provedor de hospedagem.

Não presuma que um único teste bem-sucedido prova que o site está saudável para todos os usuários; problemas de roteamento e de família de endereços podem afetar apenas algumas redes.

2. Verifique o DNS e as duas famílias de endereços

Use uma ferramenta de consulta DNS, como nslookup ou dig, para identificar os endereços IPv4 e IPv6 retornados para o hostname. Compare cada endereço retornado com o servidor, load balancer, CDN ou outro serviço que deveria receber o tráfego.

Procure um endereço obsoleto, um registro inesperado ou um destino IPv6 que não esteja configurado. Se o DNS mudou recentemente, verifique os registros autoritativos e considere o período de cache configurado antes de avaliar a alteração a partir de uma única rede.

3. Teste o serviço sem depender do navegador

A partir de uma rede que deveria conseguir alcançar o site, execute uma solicitação somente leitura, como:

curl -v --connect-timeout 10 https://[your hostname]

A saída detalhada ajuda a mostrar se a falha ocorre durante a resolução do hostname, o estabelecimento da conexão TCP ou a negociação HTTPS. Teste a porta e o protocolo reais do serviço. Um ping com falha, por si só, não é conclusivo, pois o ICMP pode estar bloqueado.

Se você administra o serviço, compare separadamente o comportamento das conexões IPv4 e IPv6 usando testes apropriados somente leitura. Uma falha em apenas uma família de endereços restringe a investigação àquela rota, ao listener, à política de firewall ou ao registro DNS.

4. Verifique o console do provedor de hospedagem

Use o painel do provedor ou um console out-of-band, em vez de depender do SSH quando o acesso à rede estiver falhando. Confirme se a instância está em execução, se a interface de rede está conectada, se o endereço público está correto e se as verificações de integridade do provedor não indicam falhas.

Se o console mostrar que o host não responde, use um procedimento de recuperação autorizado. Uma reinicialização ou um power cycle é uma alteração operacional: confirme a permissão, entenda o efeito sobre usuários ativos e trabalho não salvo e siga o processo de recuperação documentado pelo provedor.

5. Revise as regras de firewall da nuvem e do host

Verifique security groups, ACLs de rede e políticas de firewall do provedor em relação à porta de serviço de entrada esperada, normalmente HTTP ou HTTPS conforme a configuração. Depois, revise o firewall do sistema operacional, como ufw ou iptables, se houver acesso ao console.

Verifique regras introduzidas durante uma alteração de hardening, um deploy, uma atualização de endereço ou uma migração. Confirme que o tráfego é permitido pelos intervalos de origem relevantes e que a regra se aplica à interface e à família de endereços corretas. Não desative a proteção de forma ampla; faça apenas a menor alteração autorizada e documente-a.

6. Verifique o esgotamento de recursos

No console do provedor ou em uma sessão administrativa existente, inspecione CPU, memória, pressão de disco, limites de processos, sockets em escuta e contagens de conexões. Uma máquina pode parecer ligada enquanto está saturada demais para aceitar novas conexões.

Compare as leituras atuais com os níveis normais e revise os logs próximos ao primeiro registro da falha. Se um serviço estiver esgotado, siga o procedimento aprovado de capacidade ou recuperação em vez de reiniciá-lo repetidamente. Uma reinicialização pode interromper o tráfego ativo e ocultar o problema de carga subjacente.

7. Verifique um proxy, uma CDN ou um load balancer

Se o DNS apontar para uma CDN, um reverse proxy ou um load balancer, verifique se o front-end consegue alcançar a origem na porta configurada. Confira o endereço da origem, o status das verificações de integridade, as configurações de TLS, a rota de rede e as allowlists.

Uma origem saudável não elimina a possibilidade de uma política ou rota quebrada entre o front-end e a origem. Da mesma forma, um front-end saudável não prova que a origem está aceitando conexões.

8. Encaminhe o caso com evidências úteis

Registre o hostname afetado, o horário aproximado e o fuso horário, a rede do cliente, os endereços IPv4 e IPv6 resolvidos, se cada família de endereços se comporta de forma diferente, a saída detalhada da conexão e o estado de integridade no console do provedor. Essas evidências ajudam a distinguir falhas de DNS, roteamento, filtragem, host e intermediários.

Prevenção e como verificar a correção

• Monitore o site a partir de vários locais externos e alerte sobre timeouts de conexão separadamente das falhas de status HTTP.
• Mantenha documentados os registros DNS, os endereços públicos, as origens da CDN e as configurações IPv4/IPv6 e revise-os após migrações.
• Teste alterações de firewall e security groups por meio de um processo controlado, com um caminho de recuperação pelo console do provedor.
• Mantenha margem de CPU, memória, file descriptors, processos e conexões para que picos de tráfego não impeçam novas conexões.
• Monitore a integridade da origem separadamente da integridade da CDN ou do load balancer.
• Inclua testes a partir de uma segunda rede e evidências de timeout de conexão no checklist de incidentes.
• Use um comportamento de firewall claro e intencional para portas de serviço legítimas, preservando a política de segurança necessária do ambiente.

Perguntas frequentes