ERR_CONNECTION_RESET: causas e correções

O que significa ERR_CONNECTION_RESET

Diferente do ERR_CONNECTION_REFUSED, que aparece antes de qualquer dado trafegar, um reset acontece depois que o handshake TCP deu certo e a conexão já estava trocando dados. Alguma coisa no caminho, ou um dos próprios pontos, envia um pacote RST que encerra a conexão sem a sequência normal de fechamento. O navegador não tem como saber se o RST veio do servidor, de um middlebox como um firewall ou balanceador de carga, ou da própria pilha de rede do cliente, então a mensagem permanece genérica não importa a causa.

Um fechamento TCP normal envolve uma troca de pacotes FIN nos dois sentidos, o que deixa cada lado terminar de enviar o que já estava na fila. Um RST pula tudo isso: o que estava em trânsito é descartado, e qualquer dado que o servidor já tinha começado a escrever mas o cliente ainda não tinha recebido se perde. É por isso que um reset no meio de um download grande ou de uma resposta longa de API costuma deixar um resultado visivelmente cortado, em vez de uma falha limpa antes de qualquer coisa carregar.

Como o erro aparece

O Chrome mostra "This site can't be reached ... ERR_CONNECTION_RESET" no meio do carregamento, às vezes depois de parte da página já ter renderizado. O curl reporta diretamente:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

Do lado do servidor, o nginx registra uma linha correspondente para o mesmo evento: readv() failed (104: Connection reset by peer) while reading upstream. Um reset que acontece de forma consistente na mesma quantidade de bytes ou no mesmo tempo decorrido aponta para um limite de tamanho ou de timeout em algum ponto do caminho, e não para uma falha aleatória de rede.

O que causa o ERR_CONNECTION_RESET

• Um firewall, IDS ou WAF derruba a conexão no meio do fluxo. Uma regra que casa no meio de uma requisição ou resposta, em vez de no momento da conexão, produz um reset em vez de uma recusa imediata.
• Problemas de MTU ou fragmentação de pacotes. Um caminho com MTU menor do que os dois lados esperam pode corromper pacotes grandes, e alguns roteadores mal configurados respondem resetando a conexão em vez de fragmentar corretamente.
• Inspeção de TLS por antivírus ou proxy corporativo. Uma interceptação que falha no meio de um handshake ou de uma resposta costuma resetar a conexão em vez de falhar de forma graciosa.
• Um processo worker do servidor cai no meio de uma requisição. Um erro de aplicação, uma morte por falta de memória, ou um reinício de worker durante um deploy deixam uma conexão aberta sem nada para respondê-la.
• Um descompasso de timeout de keep-alive entre cliente e servidor ou proxy. Se o timeout de inatividade de um balanceador de carga é menor que o do backend, ele pode resetar uma conexão que o backend ainda considera ativa.
• Interferência ou modelagem de tráfego do provedor de internet. Alguns provedores resetam conexões longas ou de alta banda, principalmente streaming ou downloads grandes, como forma de gerenciar o tráfego.

Como saber de quem é a culpa

Teste a mesma requisição a partir de uma segunda rede, como dados móveis em vez do Wi-Fi do escritório. Se funcionar lá, um firewall local, antivírus ou proxy está interceptando a conexão. Se o reset acontece igual em todo lugar, a causa está do lado do servidor ou numa regra de WAF na frente dele. Uma verificação de HTTP rodada a partir de vários lugares ao mesmo tempo mostra se o reset é universal ou limitado a uma rede, sem precisar de um segundo dispositivo para testar.

Como corrigir o ERR_CONNECTION_RESET

Se você é o visitante

1. Reinicie seu roteador ou modem. Uma entrada travada na tabela NAT ou um estado de conexão obsoleto em roteadores domésticos é uma causa comum e fácil de resolver.
2. Desative qualquer VPN ou proxy e recarregue. Se o reset parar, a VPN ou o proxy está interceptando ou lidando mal com a conexão.
3. Desligue a inspeção de HTTPS no seu antivírus, geralmente numa configuração chamada "proteção web" ou "inspeção SSL/TLS", e tente de novo. Se resolver, adicione o site a uma lista de exceções em vez de deixar a inspeção desligada.
4. Verifique se há um MTU baixo configurado, se você está numa VPN ou num hotspot móvel; baixar um pouco o MTU no cliente pode resolver resets ligados a fragmentação.

Se você administra o site

1. Confira os logs de aplicação e de sistema em busca de uma queda ou de uma morte por falta de memória perto do horário do reset. Um processo worker morrendo no meio de uma requisição é uma das causas mais comuns.
2. Revise as regras de WAF e IDS e seus logs. Uma regra que reseta conexões que casam com certos payloads ou taxas pode parecer idêntica a uma falha de rede aleatória até você conferir o log de segurança especificamente.
3. Alinhe os timeouts de keep-alive em toda a stack. No nginx, defina o timeout voltado ao proxy para igualar ou superar o do próprio backend:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Um descompasso aqui é uma causa frequente de resets sob carga, quando o frontend fecha uma conexão que o backend ainda espera usar.
4. Fique de olho em mensagens de reset do upstream no log do proxy reverso, como upstream prematurely closed connection while reading response header from upstream, que aponta diretamente para a aplicação backend em vez da rede.
5. Recarregue depois de qualquer mudança, em vez de editar direto: nginx -t && systemctl reload nginx valida a configuração antes de aplicá-la.

Como prevenir o ERR_CONNECTION_RESET

Um reset que só aparece sob carga, ou só em respostas grandes, raramente aparece numa checagem manual rápida, já que depende de limites de tempo ou tamanho que uma única requisição pode não atingir. O monitoramento de HTTP contínuo, que verifica código de status e conteúdo do corpo numa programação a partir de mais de 300 pontos de verificação em 158 cidades, detecta um padrão de reset intermitente que um teste único deixaria passar, com alertas por e-mail, SMS, chamada de voz, Slack, Telegram e mais.

Erros relacionados

• ERR_CONNECTION_REFUSED acontece quando a conexão nunca chega a se estabelecer.
• ERR_CONNECTION_TIMED_OUT acontece quando nada responde à tentativa de conexão de jeito nenhum.
• This site can't be reached cobre todo o conjunto de erros de conexão que o Chrome agrupa sob um único título.

Perguntas frequentes

O ERR_CONNECTION_RESET significa que fui hackeado?

Não. Quase sempre aponta para um dispositivo de rede, uma regra de firewall, interceptação de antivírus, ou uma queda do lado do servidor, não para um ataque ao seu dispositivo.

Por que isso só acontece em downloads grandes?

Transferências grandes têm mais chance de bater num descompasso de MTU, num timeout de proxy, ou num limite de tamanho configurado num firewall ou balanceador de carga, tudo isso pode encerrar uma conexão no meio do caminho que uma requisição pequena terminaria antes de disparar.

O meu próprio antivírus pode causar isso?

Sim. Recursos de inspeção de HTTPS que interceptam e recriptografam o tráfego TLS às vezes falham em sites específicos ou respostas grandes e resetam a conexão em vez de deixá-la passar.

Um reset é pior que um timeout?

Não necessariamente. Um reset significa que algo encerrou ativamente a conexão, o que muitas vezes é mais fácil de diagnosticar que um timeout, onde nada acontece e não dá para saber se o pacote sequer chegou.

Por que o reset acontece sempre no mesmo ponto?

Uma quantidade consistente de bytes ou de tempo decorrido antes do reset geralmente aponta para um limite fixo, como um timeout de proxy, um tamanho máximo de resposta, ou uma configuração de keep-alive, em vez de uma falha aleatória.

Um provedor de internet pode resetar minhas conexões?

Alguns provedores resetam conexões longas como parte do gerenciamento de rede, principalmente em células congestionadas ou em transferências de alta banda como streaming de vídeo. Se a mesma requisição funciona bem no Wi-Fi mas reseta nos dados móveis, interferência da operadora é uma explicação razoável.