ERR_CONNECTION_CLOSED: o que é e como resolver

O que é o ERR_CONNECTION_CLOSED?

O ERR_CONNECTION_CLOSED é o erro do Chrome e do Edge que diz "Não é possível acessar esse site. example.com encerrou a conexão inesperadamente." No Chromium, é o erro de rede -100, definido como "uma conexão foi fechada (correspondendo a um TCP FIN)".

Um FIN é o jeito educado de encerrar uma conexão TCP. É o oposto de um reset: nada travou nem foi derrubado, um dos lados simplesmente disse "terminei" e desligou. O problema é o momento. O outro lado desligou antes de o navegador receber a página, então não havia nada para mostrar.

Algo decidiu encerrar a sua conexão antes da hora. Pode ser o servidor do site, uma CDN na frente dele, um filtro na sua rede ou um software no seu próprio computador. As correções abaixo mostram qual deles.

Onde o encerramento acontece: geralmente no handshake HTTPS

O código de rede do Chromium diz onde procurar. Quando uma conexão termina durante o handshake TLS (HTTPS), a camada de criptografia transforma esse fim de conexão em ERR_CONNECTION_CLOSED. Quando uma conexão nova consegue enviar a requisição e o servidor fecha sem responder, o Chrome relata ERR_EMPTY_RESPONSE no lugar.

O Chrome também repete uma requisição automaticamente quando uma conexão antiga, reaproveitada, se fecha por baixo dela, então você raramente vê o erro por esse motivo. Por isso, uma página de ERR_CONNECTION_CLOSED em um site HTTPS geralmente significa que algo desligou enquanto a conexão segura estava sendo estabelecida. Isso aponta para o que quer que cuide do TLS no caminho: o scanner HTTPS do seu antivírus, uma VPN ou um proxy, um equipamento de filtragem na sua rede, a CDN do site ou a configuração TLS do servidor web.

O que causa o ERR_CONNECTION_CLOSED?

Correção 1: teste outra rede para achar o culpado

Abra a página no celular usando dados móveis (Wi-Fi desligado), ou em outro computador em uma rede diferente.

• Funciona em outro lugar: o encerramento vem do seu dispositivo ou da sua rede. Siga as correções de 2 a 6.

• Falha em todo lugar: o servidor ou a CDN do site está desligando. Só o dono pode resolver. Se o site for seu, pule para a seção para donos de sites mais abaixo.

• Verifique o certificado de fora: o Verificador de SSL do DNS Robot se conecta ao site a partir dos nossos servidores e mostra se o handshake HTTPS dá certo e qual certificado é servido.

Correção 2: desligue a VPN e o proxy

Servidores de VPN e proxies cuidam de todas as conexões que você faz e, quando estão sobrecarregados ou bloqueados, muitas vezes encerram as conexões no handshake. Desconecte a VPN por completo e depois verifique se há um proxy:

• Windows 11: Configurações → Rede e Internet → Proxy → em Configuração manual de proxy, desative Usar um servidor proxy.

• macOS: Ajustes do Sistema → Rede → sua conexão → Detalhes… → Proxies → desative-os.

• Extensões do navegador que funcionam como VPN ou proxy também contam. Teste em uma janela anônima, onde as extensões ficam desativadas por padrão.

Correção 3: pause a verificação HTTPS do antivírus

Suítes de segurança que inspecionam tráfego criptografado ficam no meio de todo handshake HTTPS. Se o scanner não consegue negociar com um site, por exemplo por causa de um recurso de TLS mais novo ou de um certificado incomum, ele muitas vezes simplesmente fecha a conexão.

Procure uma configuração chamada HTTPS scanning, Web Shield, SSL/TLS protocol filtering ou Scan encrypted connections (nas versões em português, algo como "verificação de HTTPS"), desative só ela e recarregue. Se a página carregar, adicione o site como exclusão e reative a verificação. Atualizar o antivírus muitas vezes resolve de vez.

Correção 4: mude o DNS para descartar filtragem

Alguns provedores e filtros de rede bloqueiam sites apontando o domínio para um servidor próprio, que depois desliga as conexões HTTPS que não consegue atender. Se o DNS Lookup do DNS Robot retornar endereços IP diferentes para o site dos que o seu computador obtém (nslookup example.com), o seu resolver está redirecionando você.

Mude para um resolver público como Cloudflare (1.1.1.1), Google (8.8.8.8) ou Quad9 (9.9.9.9), depois limpe o cache de DNS e tente de novo. Se a sua rede também bloqueia DNS criptografado, veja esta rede está bloqueando o tráfego de DNS criptografado.

Correção 5: limpe o estado SSL, os pools de socket e os dados do navegador

• Pools de socket do Chrome: abra chrome://net-internals/#sockets e clique em Flush socket pools, para o Chrome parar de reutilizar conexões que podem estar obsoletas.

• Estado SSL do Windows: pressione Win + R, digite inetcpl.cpl, abra a guia Conteúdo e clique em Limpar estado SSL.

• Dados do site: clique no ícone à esquerda da barra de endereço → Configurações do site → Excluir dados, para que os cookies e os dados em cache desse site comecem do zero.

• Atualize o navegador: acesse chrome://settings/help. Versões antigas podem falhar no handshake com servidores que usam recursos de TLS mais novos.

Correção 6: redefina a pilha de rede e reinicie o roteador

Se vários sites falham em um único dispositivo, redefina a configuração de rede dele. Reinicie também o roteador, o que limpa a tabela de conexões. No Windows, rode estes comandos em um Prompt de Comando de administrador e depois reinicie:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

O Windows 11 também tem Configurações → Rede e Internet → Configurações de rede avançadas → Redefinição de rede, que reinstala os adaptadores de rede. No Mac, remova a rede Wi-Fi em Ajustes do Sistema → Wi-Fi e conecte-se a ela de novo.

Como corrigir o ERR_CONNECTION_CLOSED no Android e no iPhone

• Troque de rede: do Wi-Fi para os dados móveis ou o contrário, para descobrir se há um filtro de rede envolvido.

• Desligue apps de VPN, de bloqueio de anúncios e de "segurança". Muitos deles passam o tráfego por uma VPN local e o inspecionam.

• DNS privado no Android: Configurações → Rede e Internet → DNS particular → Automático. Veja o guia de DNS privado para entender cada opção.

• Atualize o Chrome ou o Safari pela loja de apps, e atualize o sistema operacional se ele estiver várias versões atrás.

• Redefina as configurações de rede: no iPhone, Ajustes → Geral → Transferir ou Redefinir o iPhone → Redefinir → Redefinir Ajustes de Rede. No Android, Configurações → Sistema → Opções de redefinição → Redefinir Bluetooth e Wi-Fi (e Redefinir configurações de rede móvel se os dados móveis também falharem).

Para donos de sites: por que o seu servidor desliga a conexão

Se visitantes em várias redes recebem ERR_CONNECTION_CLOSED, teste você mesmo o handshake TLS a partir de uma máquina fora da sua rede. O openssl s_client mostra exatamente onde ele para:

• SNI e certificados: todo hostname que os visitantes usam, tanto example.com quanto www.example.com, precisa de uma entrada server_name e de um certificado que o cubra. Hostnames que caem em um bloco de servidor padrão sem certificado muitas vezes têm o handshake encerrado.

• Protocolos: sirva TLSv1.2 e TLSv1.3. Configurações muito antigas que oferecem só TLS 1.0/1.1, ou listas de cifras incomuns, falham com os navegadores atuais. O Verificador de SSL mostra o certificado e a cadeia que os visitantes recebem.

• Limites de conexão: se o nginx registra worker_connections are not enough, ou se uma regra connlimit do firewall ou de proteção contra DDoS entra em ação, novas conexões são descartadas ou fechadas sob carga. Aumente os limites ou encontre a origem do tráfego.

• CDN e WAF: verifique os eventos de segurança da CDN para os visitantes afetados. Regras de proteção contra bots e de bloqueio geográfico podem fechar conexões de regiões inteiras.

• Logs: procure no log de erros do servidor web linhas SSL_do_handshake() failed por volta do horário das reclamações. O nginx registra a maioria das falhas de handshake do lado do cliente no nível info, então com o nível padrão error talvez você não veja nada: defina error_log /var/log/nginx/error.log info; por um curto período enquanto investiga.

# Full handshake with SNI (the hostname visitors use)
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Good: certificate chain, "Verify return code: 0 (ok)", a TLSv1.3 or TLSv1.2 protocol line
# Bad: "unexpected eof while reading" or "no peer certificate available"
#      = the server (or something in front of it) closed the handshake

# Test a specific protocol version
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Depois, verifique estes itens, em ordem:

ERR_CONNECTION_CLOSED vs. RESET vs. EMPTY_RESPONSE vs. erros de SSL

Guias relacionados: ERR_CONNECTION_RESET, ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH e ERR_CONNECTION_REFUSED.