ERR_CONNECTION_RESET: causas e correções

O que significa ERR_CONNECTION_RESET

Ao contrário do ERR_CONNECTION_REFUSED, que ocorre no handshake, um reset chega depois que o handshake TCP deu certo: durante o handshake TLS, enquanto a requisição é enviada, ou no meio da resposta. Algo no caminho, ou um dos endpoints, envia um segmento RST que encerra a conexão na hora. A lista de erros do Chromium define o código (-101) como “a connection was reset (corresponding to a TCP RST)” (uma conexão foi resetada, correspondendo a um RST do TCP). O servidor, um balanceador de carga, um firewall e o software do seu próprio computador podem enviar um, e o navegador vê o mesmo RST, seja quem for que o enviou.

Um fechamento TCP normal é uma troca de FIN em cada direção, o que deixa os dois lados terminarem de enviar o que tinham na fila. Um RST pula isso e descarta tudo que estava em trânsito, e é por isso que um reset no meio de um download ou de uma resposta longa de API deixa um resultado truncado. A RFC 9293 descreve quando o próprio TCP envia um reset. Duas regras importam mais aqui: um segmento que chega para uma conexão que não existe mais recebe um reset, e um host que fecha uma conexão enquanto ainda há dados recebidos não lidos “SHOULD send a RST to show that data was lost” (DEVERIA enviar um RST para mostrar que dados foram perdidos). A segunda regra explica uma falha comum em uploads: um servidor que rejeita um upload e fecha o socket antes de ler o corpo inteiro reseta o cliente, que então nunca vê a página de erro do servidor.

Como o erro aparece

O Chrome mostra “This site can't be reached” com “The connection was reset” (a conexão foi resetada) e ERR_CONNECTION_RESET, às vezes depois de parte da página já ter sido renderizada. O Firefox mostra “The connection was reset”. O curl reporta com o código de saída 56:

curl -sS -o /dev/null http://example.com/export.csv
curl: (56) Recv failure: Connection reset by peer

Em HTTPS, o texto exato depende das versões do curl e da biblioteca TLS, mas o código de saída diz quando o reset aconteceu. O código 35 significa que ocorreu durante o handshake TLS, o que aponta para filtros de rede ou inspeção de TLS. O código 56 significa que ocorreu ao receber dados depois disso, o que aponta para quedas, limites de tamanho e timeouts. Um reset que acontece sempre na mesma contagem de bytes ou no mesmo número de segundos depois do início da requisição aponta para um limite fixo no caminho, não para uma falha aleatória de rede.

ERR_CONNECTION_RESET 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_RESET

• Um firewall, IPS ou WAF encerra a conexão no meio. Regras que casam com o conteúdo ou com a taxa de requisições agem depois do handshake, e algumas estão configuradas para encerrar a conexão com um reset em vez de devolver uma página de erro.
• Filtragem de rede pelo nome do servidor. Filtros que leem o nome do site no handshake TLS, incluindo alguns filtros corporativos, escolares e nacionais, bloqueiam sites injetando um reset. Alguns provedores e operadoras móveis também resetam conexões como parte do gerenciamento de tráfego.
• Inspeção de TLS por antivírus ou por um proxy corporativo. A varredura de HTTPS que falha num site específico ou numa resposta grande muitas vezes reseta a conexão em vez de falhar com uma mensagem clara.
• Um processo do servidor morre no meio da requisição. Uma queda da aplicação, uma morte por falta de memória ou a reinicialização de um worker durante um deploy fecha os sockets que o processo mantinha. O cliente vê um reset ou, se nada tinha sido enviado e o fechamento foi limpo, ERR_EMPTY_RESPONSE.
• Um upload maior do que o servidor aceita. O servidor responde com um erro e fecha a conexão enquanto o navegador ainda está enviando o corpo, e os dados não lidos provocam um reset.
• Timeouts de ociosidade em balanceadores de carga e dispositivos de NAT. Uma conexão ociosa por mais tempo do que o timeout do dispositivo é esquecida, e o próximo pacote nela recebe um reset. WebSockets, server-sent events e long polling são os mais afetados.
• Problemas de MTU do caminho em VPNs, túneis e links PPPoE. Quando as mensagens ICMP de que a descoberta de MTU do caminho depende são bloqueadas, pacotes de tamanho cheio se perdem enquanto os pequenos passam. O handshake dá certo, a transferência trava e, conforme o lado que desistir primeiro, o navegador mostra um reset ou um timeout.

Causas no servidor e configuração

Quando o reset chega ao navegador, ele veio de quem mantém a conexão do próprio navegador ou está no caminho dela: o servidor web, o balanceador de carga ou a borda do CDN na frente dele, um dispositivo de rede, ou o software na máquina do visitante. Um backend que reseta um proxy reverso costuma virar um 502 Bad Gateway para o visitante, então a busca no servidor começa na borda e vai para dentro.

Workers que caíram ou foram mortos

# Kernel out-of-memory kills in the last hour
sudo journalctl -k --since "1 hour ago" | grep -i -E "out of memory|killed process"

# Restarts and crashes of a systemd service
sudo journalctl -u myapp --since "1 hour ago" --no-pager

O PHP-FPM registra processos filhos que caíram no próprio log, por exemplo WARNING: [pool www] child 2817 exited on signal 11 (SIGSEGV) after 12.481935 seconds from start. Compare os horários com o momento em que o reset aconteceu.

Limites de tamanho de upload

O nginx rejeita corpos de requisição maiores que client_max_body_size (1 MB por padrão) com um erro 413, e a documentação dele avisa que os navegadores não conseguem exibir esse erro corretamente; os visitantes muitas vezes recebem um reset no lugar. Aumente o limite onde os uploads acontecem:

# nginx: http, server, or location context
client_max_body_size 50m;

# Apache: limit in bytes (52428800 = 50 MiB)
LimitRequestBody 52428800

Timeouts de keep-alive entre um proxy e o backend

Um proxy reverso mantém abertas as conexões ociosas com o backend para reutilizá-las. Se o backend fecha uma conexão ociosa primeiro, o proxy pode enviar a requisição seguinte por uma conexão que o backend acabou de fechar e receber um reset de volta. O nginx então registra recv() failed (104: Connection reset by peer) while reading response header from upstream, e o Apache registra (104)Connection reset by peer: ... AH01102: error reading status line from remote server. O visitante costuma ver um 502 intermitente em vez de um reset. A regra é que o timeout de ociosidade do backend deve ser maior que o do proxy:

upstream app {
    server 127.0.0.1:3000;
    keepalive 16;
    keepalive_timeout 30s;   # shorter than the backend's idle timeout
}

server {
    listen 80;
    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;          # needed before nginx 1.29.7
        proxy_set_header Connection "";  # needed before nginx 1.29.7
    }
}

O Node.js fecha conexões keep-alive ociosas após 5 segundos por padrão, bem menos que os 60 segundos padrão do keepalive_timeout do upstream do nginx, então aumente o valor acima do que o proxy usa:

const http = require('node:http');
const server = http.createServer((req, res) => res.end('ok'));
server.keepAliveTimeout = 65000; // default is 5000 ms
server.listen(3000);

Balanceadores de carga e conexões de longa duração

Balanceadores de carga de camada 4 e gateways de NAT acompanham cada conexão e esquecem as ociosas. A AWS documenta que o Network Load Balancer deixa de acompanhar uma conexão TCP após 350 segundos sem dados por padrão, e que, se qualquer um dos lados enviar dados depois disso, o cliente recebe um TCP RST. Mantenha as conexões de longa duração ocupadas com frames de ping do WebSocket ou heartbeats da aplicação enviados com mais frequência que o menor timeout de ociosidade do caminho. O keepalive TCP simples só ajuda se você reduzir o temporizador dele, porque o Linux espera 2 horas por padrão (net.ipv4.tcp_keepalive_time) antes de enviar a primeira sonda.

Resets deliberados e Docker

O reset_timedout_connection on; do nginx faz o nginx resetar conexões que deram timeout, e conexões fechadas com o código não padrão 444, em vez de fechá-las normalmente. Com ele desligado, um return 444; costuma aparecer como ERR_EMPTY_RESPONSE. Num host Docker, curl: (56) Recv failure: Connection reset by peer contra uma porta publicada, a partir do próprio host, geralmente significa que a aplicação dentro do container escuta em 127.0.0.1 ou em outra porta que não a do mapeamento -p; o guia do ERR_CONNECTION_REFUSED cobre esse mapeamento.

Como aparece visto de fora

• Reset de todos os locais no mesmo ponto. Um limite de tamanho, um timeout ou uma queda naquela URL no servidor ou na borda dele. Reproduza com a requisição exata e leia os logs daquele momento.
• Reset só de um país ou de uma rede. Filtragem nessa rede, ou um nó de borda com problema atendendo aquela região.
• Resets intermitentes de locais aleatórios. Workers que caem, um servidor com problema atrás de um balanceador de carga, ou disputas de timeout de ociosidade.
• Reset só durante o handshake TLS. Inspeção de TLS ou filtragem por nome naquele caminho, ou o próprio terminador TLS. O HTTP puro para o mesmo host muitas vezes funciona.
• Normal em todos os pontos de verificação, reset só para você. Antivírus, uma VPN, um proxy ou o seu provedor.

O verificador HTTP envia a requisição de vários locais ao mesmo tempo e mostra o resultado de cada um, o que separa um reset que afeta o site inteiro de um ligado a uma única rede.

Como corrigir o ERR_CONNECTION_RESET

Se você é o visitante

1. Tente outra rede, como dados móveis em vez de Wi-Fi. Se o site carregar ali, a causa está no seu dispositivo ou na sua rede.
2. Desligue a varredura HTTPS do antivírus, em geral listada como “proteção da web” ou “varredura SSL/TLS”, e tente de novo. Se resolver, adicione o site a uma lista de exceções em vez de deixar a varredura desligada.
3. Desative qualquer VPN ou proxy e recarregue. Se o reset parar, a VPN ou o proxy está interceptando ou tratando mal a conexão.
4. Reinicie o roteador ou o modem para limpar o estado de conexões antigas.
5. No Windows, redefina o Winsock. Execute netsh winsock reset num Prompt de Comando como administrador e reinicie. Isso pode remover ganchos de rede deixados por softwares de segurança ou de VPN desinstalados.
6. Feche as conexões abertas do Chrome. Abra chrome://net-internals/#sockets e clique em “Flush socket pools”, depois recarregue.
7. Teste a MTU do caminho se você usa uma VPN ou um hotspot móvel. Execute o comando do seu sistema (Windows, Linux, macOS, nessa ordem):

   ping -f -l 1472 example.com
   ping -M do -s 1472 example.com
   ping -D -s 1472 example.com

   Se o ping falhar com um erro “needs to be fragmented” ou “message too long”, ou não tiver resposta, reduza o tamanho até passar; esse tamanho mais 28 é a MTU do seu caminho. Ajustar a MTU da VPN ou da interface de rede para esse valor pode fazer os resets pararem.

Se você administra o site

1. Reproduza e meça. Anote onde o reset acontece com curl -sS -o /dev/null -w '%{size_download} bytes %{time_total}s\n' https://example.com/path. Uma contagem de bytes ou uma duração que se repete aponta para um limite.
2. Confira os logs da aplicação e do kernel em busca de uma queda, de uma morte por falta de memória ou de uma reinicialização naquele momento.
3. Revise os logs de WAF e IPS. Uma regra que reseta conexões com certos payloads ou taxas parece idêntica a uma falha de rede até você olhar o log de segurança.
4. Confira limites de tamanho e timeouts em cada salto: client_max_body_size, timeouts de ociosidade do balanceador de carga e as configurações de keep-alive acima.
5. Recarregue com segurança depois de cada mudança: sudo nginx -t && sudo systemctl reload nginx valida a configuração antes de ela entrar em vigor.

Como evitar o ERR_CONNECTION_RESET

Um reset que aparece só sob carga, só em respostas grandes ou só a partir de certas redes dificilmente aparece numa verificação manual rápida. O monitoramento HTTP contínuo repete a requisição em intervalos regulares a partir de mais de 300 pontos de verificação em 158 cidades, então um padrão de reset intermitente ou regional fica visível, e a HostTracker envia alertas por e-mail, SMS, chamada de voz, Slack, Telegram e mais assim que as verificações começam a falhar.

Perguntas frequentes

ERR_CONNECTION_RESET significa que fui hackeado?

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

Por que recebo ERR_CONNECTION_RESET ao enviar um arquivo?

O arquivo provavelmente é maior do que o servidor aceita. O servidor rejeita o corpo, fecha a conexão antes de ler tudo, e o navegador recebe um reset em vez da página de erro. O dono do site precisa aumentar o limite de upload, como o client_max_body_size do nginx.

Por que isso só acontece em downloads de arquivos grandes?

Transferências grandes duram mais e movem mais dados, então têm mais chance de cruzar um timeout de proxy, um limite de tamanho num firewall ou balanceador de carga, ou um filtro que inspeciona o conteúdo. Qualquer um desses pode encerrar no meio uma conexão que uma requisição pequena terminaria antes.

Por que um WebSocket ou uma requisição longa cai depois de alguns minutos ociosa?

Um balanceador de carga, dispositivo de NAT ou proxy no caminho esqueceu a conexão ociosa, e o pacote seguinte recebeu um reset. Envie pings ou heartbeats com mais frequência que o menor timeout de ociosidade do caminho.

Meu próprio antivírus pode causar isso?

Sim. A varredura HTTPS que intercepta e recriptografa o tráfego TLS às vezes falha em sites específicos ou em respostas grandes e reseta a conexão em vez de deixá-la passar.

Um reset é pior que um timeout?

Não necessariamente. Um reset significa que algo encerrou a conexão ativamente, o que costuma ser mais fácil de diagnosticar que um timeout, em que nada volta e você não sabe sequer se os pacotes chegaram.

Por que o reset acontece sempre no mesmo ponto?

Uma contagem de bytes ou um tempo decorrido constante antes do reset costuma apontar para um limite fixo, como um timeout de proxy, um tamanho máximo de corpo ou um timeout de ociosidade, e não para uma falha aleatória.

Uma operadora móvel pode resetar minhas conexões?

Algumas operadoras resetam conexões como parte do gerenciamento de rede, especialmente em células congestionadas ou em transferências de muita banda, como vídeo. Se a mesma requisição funciona de forma confiável no Wi-Fi mas reseta nos dados móveis, a operadora é uma causa provável.

Fontes e leitura adicional

• Chromium net error list: as definições de CONNECTION_RESET (-101) e dos outros códigos da tabela acima.
• RFC 9293, Transmission Control Protocol: a seção 3.5.2 sobre a geração de resets, e a seção 3.6 sobre o fechamento de uma conexão com dados não lidos.
• nginx core module: client_max_body_size e reset_timedout_connection.
• AWS: Network Load Balancer TCP idle timeout: o acompanhamento de ociosidade e o RST enviado depois que ele expira.