Como Corrigir o Erro ERR_CONNECTION_TIMED_OUT: Um Guia Técnico Completo

O erro ERR_CONNECTION_TIMED_OUT significa que o seu browser enviou um pedido de ligação a um servidor remoto, mas não recebeu resposta dentro do período de tempo permitido — tipicamente 30 segundos em browsers baseados em Chromium. O handshake TCP nunca é concluído, pelo que o browser abandona a tentativa e apresenta este erro em vez de uma página carregada.

Esta não é uma falha de causa única. Pode ter origem no lado do cliente (a sua máquina, a sua rede, o seu browser), em infraestrutura intermédia (resolvedores DNS, proxies, firewalls), ou no lado do servidor (origem sobrecarregada, servidor web mal configurado, SSL expirado, ou falha de encaminhamento upstream). Diagnosticá-la corretamente requer trabalhar em cada camada de forma sistemática.

O Que Acontece Realmente Durante um Timeout de Ligação

Quando escreve um URL e prime Enter, o seu browser executa uma sequência precisa: resolução DNS, ligação TCP (SYN / SYN-ACK / ACK), handshake TLS opcional, e depois o ciclo de pedido/resposta HTTP. Um erro de timeout significa que o processo ficou bloqueado em algum ponto dessa cadeia — mais frequentemente na fase de ligação TCP, antes de qualquer dado HTTP ser trocado.

Perceber em que fase ocorreu a falha diz-lhe onde concentrar a sua correção. Uma falha DNS produz um código de erro diferente (`ERR_NAME_NOT_RESOLVED`). Uma falha TLS produz `ERR_SSL_PROTOCOL_ERROR`. Quando vê `ERR_CONNECTION_TIMED_OUT` especificamente, a pesquisa DNS foi bem-sucedida, mas o socket TCP nunca recebeu um SYN-ACK do IP de destino. Isso restringe consideravelmente o campo de investigação.

Causas Raiz: Por Que Ocorre Este Erro

Método 1: Verificar a Sua Ligação à Internet na Camada de Rede

Não se limite a “verificar se a internet está a funcionar.” Execute um teste estruturado:

• Ping ao gateway: Abra a Linha de Comandos e execute `ping 192.168.1.1` (ou o IP do seu router). Se isto falhar, o problema está entre a sua máquina e o router.
• Ping a um IP público diretamente: Execute `ping 8.8.8.8`. Se isto for bem-sucedido mas os websites falharem, o problema é DNS, não conectividade.
• Execute um traceroute: `tracert google.com` no Windows ou `traceroute google.com` no Linux/macOS. Procure onde os saltos param de responder — isso identifica o segmento de rede com falha.
• Reinicie o seu router: Desligue-o da corrente durante 30 segundos. Isto força uma nova concessão DHCP e restabelece a sessão PPPoE/PPPoA com o seu ISP.
• Teste num hotspot móvel: Se o site carregar via LTE mas não na sua banda larga doméstica, a falha está a montante do seu router — provavelmente o seu ISP ou um caminho de encaminhamento específico que utilizam.

Método 2: Limpar e Reconstruir a Cache DNS

Uma cache DNS envenenada ou desatualizada pode armazenar um endereço IP antigo e inacessível para um domínio, fazendo com que cada tentativa de ligação expire contra um servidor que já não existe nesse endereço.

No Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

No macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

No Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

Após limpar, verifique se a cache está limpa no Windows com `ipconfig /displaydns` — o resultado deve ser mínimo. Em seguida, tente a ligação novamente antes de fazer quaisquer outras alterações, para poder isolar se a cache DNS era a única causa.

Método 3: Mudar para um Resolvedor DNS Público Fiável

O resolvedor DNS predefinido do seu ISP pode ser lento, pouco fiável, ou sujeito a filtragem geográfica. Substituí-lo por um resolvedor público rápido resolve frequentemente erros de timeout causados por falhas de pesquisa DNS que retornam silenciosamente registos incorretos ou nenhum registo.

No Windows (IPv4):

1. Abra o Painel de Controlo > Rede e Internet > Centro de Rede e Partilha > Alterar definições do adaptador.
2. Clique com o botão direito no seu adaptador ativo e selecione Propriedades.
3. Selecione Protocolo Internet Versão 4 (TCP/IPv4) e clique em Propriedades.
4. Selecione Utilizar os seguintes endereços de servidor DNS e introduza o seu resolvedor preferido.

Resolvedores DNS públicos recomendados:

Caso limite crítico: Se migrou recentemente o seu website para um novo servidor ou alterou o seu registo A, a propagação DNS pode demorar até 48 horas. Durante esta janela, alguns utilizadores serão direcionados para o IP antigo. Executar `nslookup yourdomain.com 8.8.8.8` versus `nslookup yourdomain.com 1.1.1.1` permite-lhe comparar o que diferentes resolvedores retornam — se os IPs forem diferentes, está numa janela de propagação, não num verdadeiro erro de timeout.

Método 4: Limpar Cache, Cookies e Extensões do Browser

O Chrome e outros browsers baseados em Chromium armazenam respostas DNS em cache independentemente da cache DNS ao nível do sistema operativo. Esta cache DNS interna do browser pode conter registos desatualizados mesmo após limpar a cache do sistema.

Limpar diretamente a cache DNS interna do Chrome:

1. Navegue para `chrome://net-internals/#dns`
2. Clique em Clear host cache
3. Navegue para `chrome://net-internals/#sockets`
4. Clique em Flush socket pools

Limpar dados de navegação:

1. Abra o Chrome e prima `Ctrl + Shift + Delete`
2. Defina o intervalo de tempo para Todo o período
3. Marque Cookies e outros dados de sites e Imagens e ficheiros em cache
4. Clique em Limpar dados

Teste primeiro numa janela de Navegação Anónima. Se o site carregar em modo anónimo mas não numa janela normal, uma extensão do browser é a culpada. Desative todas as extensões através de `chrome://extensions/` e reative-as uma a uma para identificar a responsável. Bloqueadores de anúncios, extensões VPN e ferramentas de segurança são as fontes de interferência mais comuns.

Método 5: Desativar as Definições de Proxy

Uma configuração de proxy incorreta ou desatualizada é uma das causas mais frequentemente ignoradas deste erro, particularmente em máquinas corporativas ou após desinstalar software VPN que deixou definições de proxy para trás.

Através do Chrome:

1. Vá a Definições > Sistema > Abrir as definições de proxy do seu computador
2. Em Configuração manual de proxy, certifique-se de que Utilizar um servidor proxy está Desativado
3. Em Configuração automática de proxy, certifique-se de que Utilizar script de configuração está Desativado, a menos que utilize intencionalmente um ficheiro PAC

Através das Definições do Windows diretamente:

1. Abra Definições > Rede e Internet > Proxy
2. Desative todas as entradas de proxy manual
3. Ative Detetar definições automaticamente apenas se a sua rede o exigir

Através da Linha de Comandos (método mais rápido):

“`

netsh winhttp reset proxy

“`

Isto repõe as definições de proxy WinHTTP para ligação direta, contornando qualquer proxy ao nível do sistema que possa ter sido definido por software.

Método 6: Repor a Stack TCP/IP e o Catálogo Winsock

A corrupção no catálogo Winsock — a implementação Windows da API de sockets Berkeley — pode causar falhas de ligação intermitentes ou persistentes que parecem idênticas a timeouts do lado do servidor. Isto é particularmente comum após remoção de malware, atualizações de drivers de rede falhadas, ou atividade agressiva de antivírus.

Abra a Linha de Comandos como Administrador e execute estes comandos sequencialmente:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

Reinicie a sua máquina após executar todos os comandos. O ficheiro `resetlog.txt` será criado no seu diretório de trabalho e regista cada chave de registo que foi reposta — útil para auditar o que estava corrompido.

No Linux, o equivalente para repor o estado da rede é:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Método 7: Auditar Regras de Firewall e Antivírus

O Windows Defender Firewall e suites de segurança de terceiros podem bloquear silenciosamente ligações de saída para portas específicas, intervalos de IP, ou domínios. O bloqueio não produz um erro imediato de “ligação recusada” — em vez disso, os pacotes são descartados e o browser aguarda até atingir o seu limiar de timeout.

Teste de diagnóstico temporário:

1. Vá a Painel de Controlo > Sistema e Segurança > Windows Defender Firewall
2. Clique em Ativar ou desativar o Windows Defender Firewall
3. Desative-o temporariamente para redes privadas e públicas
4. Tente a ligação

Se o site carregar com a firewall desativada, reative-a imediatamente e crie uma regra de saída específica para permitir tráfego para o domínio ou IP afetado, em vez de deixar a firewall desativada. Navegue para Definições Avançadas > Regras de Saída > Nova Regra para configurar isto com precisão.

Para software antivírus: A maioria das suites modernas inclui uma funcionalidade de inspeção HTTPS ou “escudo web” que realiza uma intercetação man-in-the-middle do tráfego TLS. Isto pode quebrar ligações se o certificado raiz do antivírus não for reconhecido pelo browser, ou se o antivírus sinalizar incorretamente o servidor de destino. Desativar temporariamente o componente de escudo web (não o antivírus completo) é um teste mais cirúrgico do que desativar toda a proteção.

Método 8: Repor as Flags e o Preditor de Rede do Chrome

As flags experimentais e as funcionalidades de previsão de rede do Chrome podem ocasionalmente causar problemas de ligação, especialmente após atualizações do browser que alteram o comportamento destas funcionalidades.

Desativar a previsão de rede:

1. Vá a Definições > Privacidade e segurança > Cookies e outros dados de sites
2. Desloque-se até Pré-carregar páginas para navegação e pesquisa mais rápidas e desative

Repor todas as flags do Chrome para os valores predefinidos:

1. Navegue para `chrome://flags`
2. Clique em Reset all no canto superior direito
3. Reinicie o Chrome

Repor todas as definições da stack de rede do Chrome:

1. Vá a Definições > Avançadas > Repor e limpar > Restaurar as definições para os valores predefinidos originais

Isto não elimina marcadores ou palavras-passe, mas repõe páginas de arranque, definições de novo separador, separadores fixos, definições de conteúdo, cookies e extensões — dando-lhe efetivamente uma linha de base de configuração de rede limpa.

Método 9: Aumentar o Timeout de Ligação TCP (Avançado)

Por predefinição, o Windows aguarda aproximadamente 21 segundos antes de declarar uma tentativa de ligação TCP falhada (com base no valor de registo `TcpMaxConnectRetransmissions`, que tem como predefinição 2 retransmissões com backoff exponencial). Em redes lentas ou congestionadas, este valor pode ser demasiado curto.

Ajustar através do Editor de Registo (Windows):

1. Abra `regedit`
2. Navegue para `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
3. Encontre ou crie um valor DWORD chamado `TcpMaxConnectRetransmissions`
4. Defina-o para `3` ou `4` (hexadecimal) para permitir mais tentativas de retransmissão

Importante: Isto aumenta o tempo que o Windows aguardará antes de desistir de uma ligação TCP. Não corrige a causa subjacente — simplesmente dá mais tempo para que servidores lentos ou rotas congestionadas respondam. Utilize isto apenas como ferramenta de diagnóstico ou para casos de uso específicos, como ligar a servidores geograficamente distantes.

Método 10: Verificar Se o Servidor É Realmente Acessível

Antes de gastar mais tempo em correções do lado do cliente, confirme se o problema está do lado do servidor. Um website pode ser completamente inacessível devido a uma conta de alojamento suspensa, uma regra de firewall do lado do servidor, ou um servidor web mal configurado — nenhum dos quais pode ser corrigido a partir do seu browser.

Ferramentas para verificar a acessibilidade do servidor a partir de pontos externos:

• downforeveryoneorjustme.com — Verificação simples de ativo/inativo a partir de uma única localização
• downdetector.com — Agrega relatórios de utilizadores para serviços principais
• tools.pingdom.com — Testa o tempo de resposta a partir de múltiplas localizações globais
• mxtoolbox.com/SuperTool — Testa DNS, cabeçalhos HTTP e conectividade
• check-host.net — Pings e verificações HTTP a partir de dezenas de nós geográficos simultaneamente

Execute `curl -v https://yourdomain.com` a partir de um terminal para ver o ponto exato de falha — se a ligação TCP é recusada, expira, ou é bem-sucedida mas retorna um código de erro HTTP. Este único comando diz-lhe mais do que qualquer ferramenta com interface gráfica.

Causas do Lado do Servidor: O Que Verificar Se É o Proprietário do Website

Se é o proprietário do website e os seus visitantes estão a reportar `ERR_CONNECTION_TIMED_OUT`, o problema está quase certamente na sua infraestrutura. As causas mais comuns do lado do servidor são:

Esgotamento da fila de ligações do servidor web:

No Apache, a diretiva `MaxClients` (ou `MaxRequestWorkers` no Apache 2.4+) limita as ligações simultâneas. Quando este limite é atingido, novas ligações ficam em fila e eventualmente expiram. Verifique a sua configuração atual:

“`

apache2ctl -V | grep -i mpm

grep -i maxrequestworkers /etc/apache2/apache2.conf

“`

No Nginx, o equivalente é `worker_connections` no bloco `events` e `worker_processes`. Uma configuração incorreta comum é definir `worker_processes` como `1` num servidor multi-core, criando um bottleneck.

Firewall a bloquear tráfego de entrada na porta 80/443:

Se gere um ambiente de Alojamento VPS, verifique as suas regras iptables ou nftables:

“`

iptables -L INPUT -n -v | grep -E "80|443"

“`

Uma regra ACCEPT em falta para as portas 80 e 443 fará com que todas as ligações do browser expirem silenciosamente. Verifique também se a firewall do seu painel de controlo de alojamento (CSF, UFW, ou Firewalld) não bloqueou inadvertidamente estas portas após uma atualização de segurança.

Problemas de certificado SSL a causar timeouts no handshake TLS:

Um certificado SSL expirado ou mal configurado pode fazer com que o handshake TLS fique bloqueado, o que se manifesta como um timeout de ligação em vez de um erro de certificado em alguns casos limite — particularmente ao usar versões TLS mais antigas ou cipher suites mal configuradas. Verifique o seu certificado com:

“`

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

“`

Esgotamento de recursos no servidor:

Uso elevado de CPU ou RAM pode fazer com que o processo do servidor web fique sem resposta. Num servidor Linux, verifique:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

O comando `ss -s` mostra o resumo dos estados dos sockets — um grande número de ligações no estado `TIME-WAIT` ou `CLOSE-WAIT` indica problemas no tratamento de ligações que farão com que novas ligações expirem.

Configuração DNS incorreta após migração de servidor:

Se moveu recentemente o seu site para um Servidor Dedicado ou alterou o seu fornecedor de alojamento, verifique se o registo A do seu domínio aponta para o endereço IP correto e se o TTL dos registos antigos expirou. Use `dig yourdomain.com +trace` para seguir a cadeia completa de resolução DNS desde os servidores raiz.

Comparação do ERR_CONNECTION_TIMED_OUT Com Erros de Browser Semelhantes

Compreender esta tabela é operacionalmente importante: se está a resolver problemas no seu próprio servidor, o erro específico que os seus utilizadores veem diz-lhe exatamente qual camada da stack investigar primeiro.

Matriz de Decisão Prática: Qual Correção Aplicar Primeiro

Use esta sequência para minimizar o tempo de diagnóstico:

1. Consegue aceder a outros websites? Não — corrija primeiro a sua rede local ou ligação ao ISP (Métodos 1, 6). Sim — avance para o passo 2.
2. O site carrega noutro dispositivo ou rede? Sim — o problema é do lado do cliente (Métodos 2, 3, 4, 5, 7). Não — o problema é provavelmente do lado do servidor ou propagação DNS.
3. Um verificador externo (check-host.net) mostra o site como inacessível a partir de múltiplas localizações? Sim — contacte o administrador do servidor ou o seu fornecedor de alojamento. Não — o problema é de encaminhamento regional ou do seu ISP específico.
4. O site carrega em modo de Navegação Anónima? Sim — uma extensão do browser ou dados em cache é a causa (Método 4). Não — avance para correções ao nível de DNS e rede.
5. Alterou recentemente registos DNS ou migrou servidores? Sim — aguarde a propagação DNS e verifique os registos com `dig` ou `nslookup`. Não — verifique a firewall do lado do servidor e a configuração do servidor web.

Se está a gerir a sua própria infraestrutura de servidor — seja num VPS com cPanel ou num ambiente bare-metal — verifique sempre os logs do servidor antes de gastar tempo em correções do lado do cliente. O log de erros do Apache (`/var/log/apache2/error.log`) e o log de erros do Nginx (`/var/log/nginx/error.log`) conterão registos explícitos de falhas de ligação, eventos de esgotamento de recursos e erros de configuração.

Para equipas que gerem múltiplos domínios, manter o Registo de Domínios e a gestão DNS centralizados num único fornecedor reduz significativamente o risco de erros de timeout relacionados com propagação causados por configurações DNS divididas ou registos de domínio expirados.

Principais Conclusões Técnicas

• `ERR_CONNECTION_TIMED_OUT` indica especificamente uma falha ao nível TCP — o pacote SYN foi enviado mas nenhum SYN-ACK foi recebido. Isto distingue-o de erros DNS, erros TLS e erros ao nível HTTP.
• Teste sempre a partir de um ponto externo (check-host.net, curl a partir de um servidor remoto) antes de assumir que o problema está na sua máquina local.
• O Chrome mantém a sua própria cache DNS interna separada do sistema operativo. Limpar apenas a cache do sistema operativo através de `ipconfig /flushdns` é insuficiente — deve também limpar `chrome://net-internals/#dns`.
• Do lado do servidor, os descartes silenciosos de pacotes por regras de firewall são a causa mais comum deste erro específico. Uma ligação recusada (`RST`) produziria um código de erro diferente.
• Os atrasos de propagação DNS após migrações de servidor são frequentemente diagnosticados incorretamente como erros de timeout. Verifique sempre com `nslookup` contra múltiplos resolvedores antes de investigar mais.
• Para servidores web em produção, monitorize regularmente o resultado de `ss -s`. Uma contagem crescente de `CLOSE-WAIT` indica bugs de tratamento de sockets ao nível da aplicação que eventualmente causarão timeouts de ligação sob carga.

Perguntas Frequentes

Por que o ERR_CONNECTION_TIMED_OUT aparece apenas num website específico mas não noutros?

Isto significa quase sempre que o servidor de destino é inacessível a partir da sua rede especificamente — seja porque o servidor está inativo, o seu IP mudou devido à propagação DNS, ou uma regra de firewall no servidor está a bloquear o seu intervalo de IP. Use um verificador externo como check-host.net para confirmar se o site é globalmente inacessível ou apenas inacessível a partir da sua localização.

Limpar a cache DNS corrige o ERR_CONNECTION_TIMED_OUT?

Pode, mas apenas se a causa for um registo DNS desatualizado a apontar para um IP de servidor antigo. Se o registo DNS estiver correto e o servidor for genuinamente inacessível, limpar a cache não ajudará. Verifique sempre para que endereço IP o domínio resolve usando `nslookup` antes e depois de limpar.

Uma VPN pode causar ERR_CONNECTION_TIMED_OUT?

Sim. Uma VPN encaminha o seu tráfego através dos seus próprios servidores e resolvedores DNS. Se o servidor VPN estiver sobrecarregado, geograficamente distante, ou tiver um problema de encaminhamento para o site de destino, verá erros de timeout. Desconecte a VPN e teste diretamente. Por outro lado, alguns sites bloqueam intervalos de IP de nós de saída VPN ao nível da firewall, o que também produzirá este erro.

Como corrijo o ERR_CONNECTION_TIMED_OUT num servidor que giro?

Verifique nesta ordem: (1) confirme que o processo do servidor web está em execução (`systemctl status nginx` ou `apache2`), (2) verifique se as portas 80 e 443 estão abertas na sua firewall (`iptables -L` ou `ufw status`), (3) verifique o uso de recursos do servidor com `top` e `free -h`, (4) reveja o log de erros do servidor web para mensagens de recusa de ligação ou esgotamento de workers, (5) confirme que o seu certificado SSL é válido e não expirou.

O ERR_CONNECTION_TIMED_OUT é o mesmo que um 504 Gateway Timeout?

Não. Um 504 Gateway Timeout é um erro ao nível HTTP retornado por um reverse proxy (como Nginx ou um CDN) quando não consegue obter uma resposta do servidor de origem upstream dentro do seu timeout configurado. `ERR_CONNECTION_TIMED_OUT` é um erro ao nível do browser que ocorre antes de qualquer resposta HTTP ser recebida — a própria ligação TCP nunca é concluída. Ambos indicam um timeout, mas em camadas diferentes da stack de rede.