ERR_CONNECTION_TIMED_OUT: por que acontece e como corrigir

O que significa ERR_CONNECTION_TIMED_OUT

Quando um navegador abre uma conexão, ele envia um pacote SYN e espera um SYN-ACK. Um timeout significa que nenhuma resposta chegou, nem um SYN-ACK nem o RST que uma porta fechada enviaria, então o navegador não sabe se o pacote chegou a alguma coisa. Esse silêncio é a diferença para o ERR_CONNECTION_REFUSED, uma rejeição rápida e definitiva do destino. A lista de erros do Chromium define o código (-118) como “a connection attempt timed out” (uma tentativa de conexão deu timeout).

O sistema operacional do cliente não desiste depois de uma tentativa. Ele reenvia o SYN várias vezes com intervalos crescentes, caso o primeiro tenha se perdido numa perda comum de pacotes. No Linux, net.ipv4.tcp_syn_retries vale 6 por padrão, e a documentação do kernel dá o timeout final em 131 segundos. A RFC 9293 pede que o TCP continue tentando um SYN por pelo menos 3 minutos, mas deixa a aplicação desistir antes, então a espera que você vê depende do sistema operacional e do navegador juntos. De qualquer forma, um timeout demora muito mais para aparecer do que uma recusa, que em geral volta em milissegundos.

Como o erro aparece

O Chrome mostra “This site can't be reached”, depois “example.com took too long to respond” (example.com demorou demais para responder) e ERR_CONNECTION_TIMED_OUT, só depois da espera inteira. O Firefox mostra “The connection has timed out”. Na linha de comando, defina um timeout de conexão para não esperar minutos:

curl -v --connect-timeout 10 https://example.com/
* Trying 203.0.113.10:443...
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds

O código de saída 28 significa timeout; versões mais novas do curl redigem a mensagem de outro jeito mas retornam o mesmo código. O --connect-timeout limita só a fase de conexão, então separa um timeout de conexão de uma resposta lenta. nc -zv -w 5 example.com 443 reporta “timed out” da mesma forma, e no Windows Test-NetConnection example.com -Port 443 no PowerShell termina com TcpTestSucceeded : False.

ERR_CONNECTION_TIMED_OUT e erros parecidos

O Chrome mostra todos estes sob o mesmo título “This site can't be reached”, então o código embaixo é o que os diferencia. As linhas seguem a ordem em que o carregamento de uma página os encontra, da consulta DNS ao primeiro byte da resposta. Os números são os códigos de erro internos do Chromium.

Erro	O que aconteceu no nível da rede ou do protocolo	Onde olhar primeiro
ERR_NAME_NOT_RESOLVED (-105)	A consulta DNS não devolveu nenhum endereço IP utilizável, então nenhuma conexão foi tentada.	Os registros DNS do domínio e o resolvedor que o dispositivo usa.
ERR_ADDRESS_UNREACHABLE (-109)	O sistema operacional ou um roteador informou que não há rota até o endereço IP.	O roteamento do lado do cliente: rotas de VPN, a rede local, a configuração de IPv6.
ERR_CONNECTION_TIMED_OUT (-118)	O SYN saiu e nada voltou, nem SYN-ACK nem RST, até o cliente desistir.	Firewalls e security groups que descartam pacotes, se o host está no ar e o endereço IP que o DNS devolve.
ERR_CONNECTION_REFUSED (-102)	O SYN chegou ao host e foi rejeitado na hora, em geral com um RST.	Se há um processo escutando naquela porta e naquele endereço, e regras REJECT do firewall.
ERR_CONNECTION_RESET (-101)	A conexão estava aberta e depois um RST a encerrou durante o handshake TLS ou a transferência.	Os logs do proxy, do WAF e da aplicação naquele momento; antivírus, VPN ou filtragem na rede do cliente.
ERR_EMPTY_RESPONSE (-324)	A conexão foi aberta e a requisição saiu, mas o servidor fechou a conexão sem enviar nenhum dado.	Os logs de erro do servidor e do proxy: workers que travaram ou conexões fechadas de propósito (o return 444 do nginx).

O que causa o ERR_CONNECTION_TIMED_OUT

• Um firewall descarta os pacotes. Regras DROP, security groups de nuvem e o deny do ufw descartam o SYN sem responder. É a configuração usual para portas que não devem ser públicas, e a causa mais comum quando o próprio servidor está no ar.
• O host está fora do ar ou isolado. Um servidor desligado, travado ou desconectado não consegue responder de forma alguma. Um roteador que sabe que o host sumiu pode enviar um erro ICMP no lugar, que o Chrome reporta como ERR_ADDRESS_UNREACHABLE.
• O DNS devolve o endereço errado. Um registro que ainda aponta para um servidor antigo depois de uma migração, um IP antigo em cache ou uma entrada no arquivo hosts levam o navegador a um endereço onde nada responde.
• Um problema de roteamento no caminho. Um link de peering quebrado, uma rota mal configurada ou uma queda do provedor deixam os pacotes perdidos antes de chegarem à rede de destino, às vezes só para algumas regiões.
• O servidor está sobrecarregado. Quando a fila de escuta está cheia, o Linux descarta as novas tentativas de conexão em vez de recusá-las, e uma tabela de rastreamento de conexões cheia num firewall ou host de NAT faz o mesmo.
• Sua rede bloqueia a porta. Alguns firewalls de empresas, escolas e Wi-Fi públicos permitem apenas portas comuns como 80 e 443, então um site em :8080 ou :8443 dá timeout ali e carrega em casa.

Causas no servidor e configuração

Um serviço que escuta só em 127.0.0.1 produz uma recusa, não um timeout. Se clientes externos dão timeout, algo descarta os pacotes antes de eles chegarem à porta, e a forma mais rápida de achar onde é observá-los no servidor enquanto você se conecta de outra rede:

sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

O filtro mostra os SYNs que chegam e as respostas SYN-ACK do servidor. Nenhum SYN significa que o descarte acontece antes do servidor: um firewall de nuvem, um firewall de rede, o roteamento ou um DNS apontando para outro lugar. SYNs chegando sem SYN-ACK saindo significa que um firewall no host ou uma fila cheia os está descartando. SYNs respondidos com SYN-ACKs significa que o servidor está respondendo, e as respostas se perdem na volta ou são descartadas do lado do cliente.

Security groups de nuvem e ACLs de rede

Firewalls de nuvem normalmente descartam o tráfego que não permitem, então uma regra de entrada ausente produz um timeout, não uma recusa. Liste as regras que se aplicam ao servidor:

# AWS: inbound rules of a security group
aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 --query 'SecurityGroups[].IpPermissions'

# Azure: rules of a network security group
az network nsg rule list --resource-group web-rg --nsg-name web-nsg --output table

# Google Cloud: firewall rules in the current project
gcloud compute firewall-rules list

As ACLs de rede da AWS são stateless, então precisam de uma regra de saída para o tráfego de retorno nas portas efêmeras (1024-65535) além da regra de entrada. Uma regra de retorno ausente também parece um timeout.

Firewalls de host

# Default policy and DROP rules with packet counters
sudo iptables -L INPUT -n -v --line-numbers

# ufw: "deny" drops without replying; allow the port explicitly
sudo ufw status verbose
sudo ufw allow 443/tcp

# nftables
sudo nft list ruleset | grep -n -E "drop|policy"

Um cabeçalho Chain INPUT (policy DROP) significa que tudo que não é explicitamente permitido é descartado. Uma regra DROP cujo contador de pacotes sobe a cada nova tentativa é a que está descartando suas conexões.

Registros DNS

Compare o endereço que os servidores de nomes do próprio domínio publicam com o que os resolvedores públicos devolvem e com o IP real do servidor:

dig +short NS example.com
dig +short A example.com @ns1.example-dns.net
dig +short A example.com @1.1.1.1

Se a resposta autoritativa está certa e um resolvedor ainda devolve o endereço antigo, o TTL do registro ainda não expirou. Um TTL baixo definido antes de uma mudança planejada encurta essa espera:

example.com.      300  IN  A      203.0.113.10
www.example.com.  300  IN  CNAME  example.com.

Um registro AAAA desatualizado é mais difícil de notar: o Chrome inicia uma tentativa IPv4 em paralelo depois de um pequeno atraso, então os navegadores podem carregar o site enquanto clientes só com IPv6 e verificações dão timeout.

Servidores Linux sobrecarregados

Quando a fila de accept de um socket em escuta está cheia, o Linux descarta os novos SYNs em vez de resetá-los, porque tcp_abort_on_overflow vem desligado por padrão. Os clientes veem conexões lentas e timeouts. A fila é limitada por net.core.somaxconn (4096 por padrão desde o Linux 5.4) e pelo backlog que a aplicação pede; o nginx pede 511, a menos que a diretiva listen defina backlog=.

# Listen queues: Recv-Q is the current accept queue, Send-Q its limit
ss -ltn

# Counters of overflowed queues and dropped SYNs
nstat -az TcpExtListenOverflows TcpExtListenDrops

# Connection-tracking table full on a firewall or NAT host
sudo journalctl -k | grep -i "nf_conntrack: table full"

Aumente o backlog (por exemplo listen 443 ssl backlog=4096;) só junto com a correção do que deixa a aplicação lenta para aceitar conexões.

Kubernetes

Duas configurações descartam o tráfego em vez de rejeitá-lo. Com externalTrafficPolicy: Local, o kube-proxy não encaminha tráfego externo num nó que não tem pod pronto para o Service, então as conexões ao NodePort desse nó dão timeout. Balanceadores de carga de nuvem fazem health checks nos nós para evitar isso, mas clientes que se conectam direto a um NodePort não. Uma NetworkPolicy que não permite o tráfego também costuma descartá-lo, conforme o plugin de rede.

Como aparece visto de fora

• Timeout de todos os locais. O host está fora do ar, um firewall ou security group descarta a porta para todos, ou o DNS aponta para um endereço morto em toda parte.
• Timeout só de algumas regiões. Um problema de roteamento ou peering entre essas redes e o host, uma regra de firewall que descarta certos países ou faixas de endereços, ou um dos vários registros A apontando para um servidor morto.
• O ping responde, a porta dá timeout. O host está no ar e um firewall descarta aquela porta. Um ping que falha prova pouco por si só, porque muitos hosts bloqueiam ping.
• Uma porta responde, outra dá timeout. Uma regra de firewall cobre só aquela porta, por exemplo a falta de uma regra de permissão para a 443 depois de o HTTPS ser ativado.
• Aceita em todo lugar, timeout só para você. Sua rede: um firewall de saída, um bloqueio do provedor, uma entrada antiga de DNS ou do arquivo hosts, ou uma VPN.
• Timeouts intermitentes sob carga. Filas de escuta cheias ou uma tabela de rastreamento de conexões cheia.

O verificador de portas abre uma conexão TCP a partir de vários locais e reporta, para cada um, se ela foi aceita, recusada ou deu timeout, de modo que um descarte em um caminho se destaca de um host que está fora do ar em toda parte.

Como corrigir o ERR_CONNECTION_TIMED_OUT

Se você é o visitante

1. Tente uma rede diferente, como dados móveis, para descartar o roteador, a rota do seu provedor ou um firewall do trabalho.
2. Limpe o cache de DNS para o caso de ele guardar um endereço antigo e inalcançável. Execute o comando do seu sistema (Windows, macOS, Linux com systemd-resolved, nessa ordem):

   ipconfig /flushdns
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   resolvectl flush-caches

   No Chrome, abra também chrome://net-internals/#dns e clique em “Clear host cache”.
3. Confira o arquivo hosts (C:\Windows\System32\drivers\etc\hosts no Windows, /etc/hosts no macOS e no Linux) em busca de uma entrada antiga que prenda o domínio a um endereço morto.
4. Desative uma VPN ou proxy temporariamente. O nó de saída de uma VPN pode ser justamente o que está inalcançável.
5. Reinicie o roteador para limpar um estado de roteamento ou de conexão travado.

Se você administra o site

1. Confirme que o host está no ar pelo console do provedor ou por outra máquina, não por um shell no próprio servidor.
2. Observe os SYNs com o tcpdump enquanto se conecta de fora, como mostrado acima, para saber se os pacotes chegam ao servidor.
3. Confira security groups, ACLs de rede e firewalls de host em busca de uma regra de permissão ausente ou de uma regra DROP na porta.
4. Compare as respostas de DNS com o endereço real do servidor, incluindo os registros AAAA.
5. Trace o caminho por TCP:

   mtr --tcp --port 443 example.com
   sudo traceroute -T -p 443 example.com

   Um trace TCP consegue passar por firewalls que bloqueiam as sondas de trace ICMP ou UDP. Onde ele para é uma pista, não uma prova, porque muitos roteadores nem respondem às sondas de trace.
6. Confira os contadores de fila e de conntrack se os timeouts aparecem só sob carga.

Como evitar o ERR_CONNECTION_TIMED_OUT

Um pacote descartado não deixa nenhum erro nos logs do servidor, porque nada no servidor chegou a receber a requisição. Verificações de porta e de HTTP feitas de fora da rede pegam um host inalcançável ou uma porta descartada assim que isso começa; a HostTracker as executa a partir de mais de 300 pontos em 158 cidades e envia alertas por e-mail, SMS, chamada de voz, Slack, Telegram e mais antes que os visitantes reclamem. Adicionar o monitoramento por ping ao lado de uma verificação de porta mostra na hora se foi o host inteiro ou só a porta que ficou em silêncio.

Perguntas frequentes

Quanto tempo o Chrome espera antes de mostrar ERR_CONNECTION_TIMED_OUT?

Depende sobretudo das configurações de TCP do sistema operacional, não de um temporizador fixo do navegador. No Linux, o kernel reenvia o SYN 6 vezes por padrão e desiste após cerca de dois minutos; outros sistemas usam números de tentativas diferentes. Uma falha que aparece em um ou dois segundos quase nunca é um timeout.

Por que o site carrega no celular mas dá timeout no notebook?

Isso geralmente aponta para algo específico do caminho de rede do notebook: um firewall do trabalho, um cliente de VPN, ou uma entrada de DNS em cache ou do arquivo hosts apontando para um endereço inalcançável.

Por que o ping funciona mas o site dá timeout?

O ping usa ICMP, enquanto o site precisa de uma conexão TCP com a porta 80 ou 443. Um firewall pode permitir um e descartar o outro, então um ping que funciona só prova que o host está no ar.

Por que dá timeout só numa porta como 8080 ou 8443?

A rede em que você está provavelmente permite apenas portas comuns. Muitas redes de empresas e públicas descartam conexões de saída para qualquer porta que não seja 80 e 443, então a mesma URL funciona de casa ou com dados móveis.

Um problema de DNS pode causar ERR_CONNECTION_TIMED_OUT em vez de um erro de DNS?

Sim, se o DNS resolve com sucesso mas devolve um endereço onde nada responde, como um servidor antigo que já foi desligado. A consulta funciona, e a tentativa de conexão a esse endereço dá timeout.

Um site pode bloquear meu IP com um timeout?

Sim. Um servidor ou o firewall dele pode descartar o tráfego de endereços banidos ou de países inteiros, e pacotes descartados parecem exatamente um servidor morto para você. Se o site carrega pelos dados móveis mas não pela sua conexão de casa, pergunte ao dono do site se o seu endereço foi bloqueado.

ERR_CONNECTION_TIMED_OUT é igual em todo navegador?

A causa é a mesma, mas o texto muda. O Microsoft Edge é baseado no Chromium e mostra o mesmo código, enquanto o Firefox mostra “The connection has timed out”.

Um timeout sempre significa que o servidor está fora do ar?

Não. Significa que nada respondeu à tentativa de conexão, o que também pode querer dizer que um firewall a descartou, que há uma rota quebrada em algum ponto do caminho ou que o DNS aponta para o endereço errado enquanto o servidor de verdade está bem.

Por que o site dá timeout para mim mas carrega para um colega na mesma rede?

Procure um cliente de VPN por dispositivo, uma entrada de DNS em cache, uma linha no arquivo hosts ou uma configuração de proxy do navegador que só a sua máquina tem. Um problema de rede compartilhado costuma afetar todo mundo nela, então uma diferença entre dois dispositivos aponta para um deles.

Fontes e leitura adicional

• Chromium net error list: as definições de CONNECTION_TIMED_OUT (-118) e dos outros códigos da tabela acima.
• RFC 9293, Transmission Control Protocol: a seção 3.8.3 sobre falhas de conexão e por quanto tempo um SYN é reenviado.
• Linux kernel IP sysctl documentation: tcp_syn_retries, tcp_abort_on_overflow e somaxconn.
• Kubernetes: virtual IPs and service proxies: como as políticas de tráfego encaminham ou descartam o tráfego de um Service.