ERR_CONNECTION_RESET: o que é e como resolver

O que é o ERR_CONNECTION_RESET?

O ERR_CONNECTION_RESET é o erro que o Chrome, o Edge, o Brave e outros navegadores Chromium mostram quando uma conexão com um site foi aberta e depois cortada à força. A página diz "Não é possível acessar esse site. A conexão foi redefinida." Dentro do Chromium, é o erro de rede -101, e o código-fonte o descreve em uma linha: uma conexão foi redefinida, "correspondendo a um TCP RST".

Um reset TCP (RST) é o botão de desligar da rede. Uma conexão normal termina educadamente com um pacote FIN depois que os dados são entregues. Um reset a encerra na hora, sem despedida, e o que estava carregado pela metade é descartado. O seu navegador chegou a alcançar o servidor: o DNS funcionou e a conexão foi estabelecida. Depois, algo no caminho decidiu derrubá-la.

Esse "algo" é todo o mistério. Pode ser o seu próprio computador (antivírus, VPN, uma pilha de rede quebrada), o seu roteador ou provedor de internet, um firewall na frente do site ou o próprio processo do servidor web. As correções abaixo estão ordenadas para descobrir qual deles é, das mais rápidas para as mais demoradas.

Como esse erro aparece em outros navegadores

A mensagem muda de um navegador para outro, mas todos estão relatando o mesmo reset TCP.

Se o Firefox mostrar PR_CONNECT_RESET_ERROR em uma página de "Falha na conexão segura", o reset aconteceu durante o handshake HTTPS. As causas se sobrepõem bastante às deste guia, principalmente a verificação HTTPS do antivírus e a filtragem de rede.

O que causa o ERR_CONNECTION_RESET?

Todo reset tem um remetente. Descobrir quem o enviou diz quem pode resolver.

As cinco primeiras estão do seu lado e normalmente você as resolve em minutos. As duas últimas estão do lado do site: nenhuma limpeza de cache vai ajudar, e a única solução é o dono resolver, ou você esperar.

Passo 1: o problema é você ou o site?

Gaste 60 segundos nisto antes de mudar qualquer configuração. Isso diz qual metade deste guia se aplica a você.

• Teste outra rede. Desligue o Wi-Fi do celular e abra a mesma página usando dados móveis. Se carregar, o reset está acontecendo no seu dispositivo ou na sua rede de casa/do trabalho.

• Teste outro site. Se todos os sites HTTPS dão reset, suspeite da VPN, do proxy ou do antivírus. Se só um site dá, suspeite de filtragem ou do servidor desse site.

• Teste o servidor de fora. O Verificador de Portas do DNS Robot se conecta à porta 443 do site a partir dos nossos servidores. Se a porta está aberta para nós mas dá reset para você, o problema está entre você e o site.

• Rastreie a rota. Um traceroute mostra cada salto de rede entre o DNS Robot e o servidor, o que ajuda a diferenciar um servidor morto de um caminho quebrado.

Correção 1: recarregue e depois tente uma janela anônima

Um reset isolado costuma ser coisa de momento: um roteador reiniciando, um servidor reiniciando durante um deploy, uma troca de ponto de acesso Wi-Fi. Pressione Ctrl + R (Mac: Cmd + R) depois de alguns segundos.

Se continuar acontecendo, abra a página em uma janela anônima (Ctrl + Shift + N, no Mac Cmd + Shift + N). O modo anônimo roda sem as suas extensões e sem cookies salvos. Se a página carregar ali, a culpa é de uma extensão ou de um cookie corrompido: desative as extensões uma a uma, ou limpe os dados desse site pelo ícone à esquerda da barra de endereço → Configurações do site → Excluir dados.

Correção 2: desligue a VPN e verifique as configurações de proxy

VPNs e proxies ficam no meio de todas as conexões e, quando o servidor deles está sobrecarregado, bloqueado ou tem um temporizador de inatividade curto demais, eles dão reset nas conexões. Desconecte a VPN por completo (não apenas troque de servidor) e recarregue.

• Windows 11: Configurações → Rede e Internet → Proxy. Deixe Detectar configurações automaticamente ativado e, em Configuração manual de proxy, clique em Configurar (ou Editar) e desative Usar um servidor proxy.

• macOS: Ajustes do Sistema → Rede → selecione Wi-Fi ou Ethernet → Detalhes… → Proxies. Desative todo proxy que você não configurou de propósito.

• O próprio Chrome usa o proxy do sistema, então não há nada separado para mudar no navegador.

# Windows also has a separate system-service proxy (WinHTTP).
# Run in an elevated Command Prompt or PowerShell:
netsh winhttp show proxy
netsh winhttp reset proxy

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

Muitos antivírus descriptografam e inspecionam o seu tráfego HTTPS. O recurso aparece com nomes como HTTPS scanning, Web Shield, SSL/TLS protocol filtering ou Scan encrypted connections (nas versões em português, algo como "verificação de HTTPS" ou "verificar conexões criptografadas"). Quando o scanner não consegue lidar com o certificado ou o protocolo de um site, ele dá reset na conexão em vez de deixá-la passar.

Para testar, desative a opção de verificação HTTPS, não o antivírus inteiro, e recarregue. Se a página carregar, mantenha a verificação desligada só para esse site (a maioria dos produtos permite uma exclusão) ou atualize o antivírus. Firewalls de terceiros podem fazer a mesma coisa, então teste com eles pausados também.

Correção 4: redefina a pilha de rede do Windows (Winsock)

O Windows mantém um catálogo de componentes de rede chamado Winsock. Clientes VPN, antivírus antigos e alguns malwares adicionam entradas a ele, e um catálogo danificado gera resets em todos os sites. Redefinir o Winsock e a pilha TCP/IP devolve os dois ao padrão. Abra o Prompt de Comando como administrador e execute:

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

:: Restart the PC afterwards. The Winsock reset needs a reboot to apply.

No Windows 11 também existe uma versão de um clique: Configurações → Rede e Internet → Configurações de rede avançadas → Redefinição de rede. Ela remove e reinstala todos os adaptadores de rede e reinicia o PC, então depois você vai precisar se reconectar ao Wi-Fi e reinstalar qualquer VPN.

Correção 5: limpe o DNS e teste outro resolver DNS

O DNS não envia resets por conta própria, mas alguns resolvers de provedores e de redes corporativas apontam domínios bloqueados para um servidor de filtragem que dá reset na conexão. Um endereço desatualizado em cache também pode levar você a um servidor que não hospeda mais o site. Limpe o cache primeiro. O nosso guia para limpar o DNS tem o comando para cada sistema:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

Depois, compare o que a sua rede retorna com uma resposta neutra. Consulte o domínio no DNS Lookup do DNS Robot: se os endereços IP ali forem diferentes dos que o seu computador resolve (nslookup example.com), o seu resolver está redirecionando você. Mude para um resolver público como Cloudflare (1.1.1.1) ou Google (8.8.8.8). O nosso Teste de Velocidade DNS mostra qual é o mais rápido de onde você está.

Correção 6: reduza o MTU se páginas grandes falham e as pequenas carregam

Um padrão clássico: páginas simples carregam, mas páginas grandes, downloads de arquivos ou logins dão reset. Isso aponta para um problema de MTU. Os pacotes são grandes demais para um dos enlaces do caminho (comum em VPNs, DSL com PPPoE e alguns hotspots móveis), e um equipamento que deveria avisar sobre o problema simplesmente os descarta em silêncio, então a conexão trava e depois falha.

Encontre o maior pacote que passa sem fragmentar. 1472 bytes de dados mais 28 bytes de cabeçalhos dão o MTU padrão de 1500:

:: Windows: -f = don't fragment, -l = payload size
ping example.com -f -l 1472
:: "Packet needs to be fragmented but DF set" = too big. Lower it until replies come back.

:: Then set MTU = (largest working size + 28), e.g. 1400:
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# macOS: -D = don't fragment, -s = payload size
ping -D -s 1472 example.com

Correção 7: esvazie os pools de socket do Chrome e redefina o Chrome

O Chrome reutiliza conexões abertas para carregar páginas mais rápido. Se uma dessas conexões do pool ficou obsoleta, por exemplo depois de você trocar de rede ou de a VPN cair, o Chrome pode tentar usá-la de novo e levar um reset. Abra chrome://net-internals/#sockets e clique em Flush socket pools, depois recarregue.

Continua falhando só no Chrome enquanto o Firefox funciona? Vá em chrome://settings/reset → Restaurar as configurações para os padrões originais. Isso desativa as extensões e limpa dados temporários, mas mantém favoritos, histórico e senhas salvas.

Como corrigir o ERR_CONNECTION_RESET no Android e no iPhone

Os celulares mostram esse erro pelos mesmos motivos, mais um extra: uma configuração de DNS privado no Android que aponta para um servidor de filtragem ou inacessível.

• Android, DNS privado: Configurações → Rede e Internet → DNS particular → defina como Automático (no Samsung: Configurações → Conexões → Mais configurações de conexão → DNS privado). O nosso guia sobre DNS privado no Android explica o que cada opção faz.

• Android, redefinir as configurações de rede: Configurações → Sistema → Opções de redefinição → Redefinir Bluetooth e Wi-Fi, além de Redefinir configurações de rede móvel se os dados móveis forem afetados (no Samsung: Configurações → Gerenciamento geral → Restaurar → Restaurar configurações de Wi-Fi e Bluetooth (Reset Wi-Fi and Bluetooth settings)).

• iPhone e iPad: Ajustes → Geral → Transferir ou Redefinir o iPhone → Redefinir → Redefinir Ajustes de Rede. Isso apaga as redes Wi-Fi e as senhas salvas e remove as configurações de VPN que não foram instaladas por um perfil de configuração.

• Nos dois: desligue qualquer VPN ou app bloqueador de anúncios (muitos funcionam como uma VPN local), alterne entre Wi-Fi e dados móveis e atualize o app do navegador.

Para donos de sites: descubra o que está dando reset nos seus visitantes

Se os visitantes relatam ERR_CONNECTION_RESET e o seu site falha a partir de várias redes, o reset está vindo da sua infraestrutura. Trabalhe de fora para dentro:

• Reproduza o erro de fora. Rode curl -v https://yourdomain.com em uma máquina fora da sua rede, ou teste a porta 443 com o Verificador de Portas. Anote se o reset vem antes do handshake TLS, durante ele ou depois que a requisição foi enviada.

• Verifique a sua camada de segurança. Limitadores de taxa, fail2ban, CrowdSec e WAFs na nuvem podem rejeitar IPs banidos com um reset TCP (por exemplo, uma regra do iptables REJECT --reject-with tcp-reset). Antes de qualquer outra coisa, verifique se o IP do usuário que relatou o problema está banido.

• Procure travamentos e reinícios. Um processo que morre no meio de uma requisição leva junto as conexões abertas. Verifique journalctl -u your-service, pm2 logs ou dmesg -T | grep -i "killed process" para ver se o OOM killer do Linux (que encerra processos por falta de memória) entrou em ação.

• Verifique o TLS. Sirva TLS 1.2 e 1.3 com a cadeia de certificados completa. Configurações de protocolo antigas ou uma cadeia quebrada podem encerrar o handshake de forma abrupta em alguns clientes. O Verificador de SSL mostra a sua cadeia de certificados e a validade, e o Verificador de Cabeçalhos HTTP mostra o que uma requisição real recebe de volta.

• Verifique a CDN. Se você está atrás da Cloudflare ou de outra CDN, leia o log de eventos de segurança dela em busca do IP ou do país do visitante antes de mexer no servidor de origem.

# Is the visitor's IP banned by fail2ban?
sudo fail2ban-client status              # list jails
sudo fail2ban-client status sshd         # banned IPs in one jail
sudo fail2ban-client set sshd unbanip 203.0.113.7

# Did the OOM killer end your app?
dmesg -T | grep -i "killed process"

ERR_CONNECTION_RESET vs. REFUSED vs. TIMED_OUT vs. CLOSED

Esses quatro erros parecem iguais na tela, mas descrevem coisas diferentes na rede, e cada um aponta para uma correção diferente. Os códigos são os números de erro de rede do próprio Chromium.

Guias completos dos erros vizinhos: ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT e ERR_CONNECTION_CLOSED. Se a sua rede também está bloqueando o DNS seguro, veja esta rede está bloqueando o tráfego de DNS criptografado.