Ir para o conteúdo principal

Guias / Corrigir: guias para os erros que aparecem de verdade

ERR_EMPTY_RESPONSE: causas e correções

ERR_EMPTY_RESPONSE significa que a conexão foi aceita, mas o servidor devolveu zero bytes, em vez de uma resposta HTTP normal ou até uma página de erro. O handshake TCP deu certo; o que quer que devesse responder a requisição nunca respondeu.

O que significa ERR_EMPTY_RESPONSE

Esse erro fica mais adiante no ciclo de vida da requisição do que uma conexão recusada ou expirada. O navegador se conecta ao servidor com sucesso, e numa requisição HTTPS o handshake TLS geralmente também se completa, mas depois de a requisição ser enviada, a conexão se fecha sem nenhuma linha de status HTTP, nenhum cabeçalho, e nenhum corpo. Isso é diferente de um erro 500 ou 502, que ainda é uma resposta HTTP completa; aqui, não há nada para interpretar porque nada voltou.

Isso torna o ERR_EMPTY_RESPONSE mais difícil de diagnosticar pelo lado do cliente do que a maioria dos erros de conexão, já que cada camada até a conexão de transporte, incluindo ela, funcionou corretamente. A falha está especificamente em o que quer que gere a resposta HTTP: o processo da aplicação, o framework que lida com a requisição, ou um proxy na frente dele que fechou o socket em vez de repassar, ou gerar, uma página de erro adequada.

Como o erro aparece

O Chrome mostra "This site can't be reached ... ERR_EMPTY_RESPONSE" assim que a conexão se fecha sem dados. O curl reporta a mesma condição em termos diretos:

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

"Empty reply from server" é a mensagem exata do curl para essa condição, e é o sinal mais claro de que a própria conexão funcionou enquanto o que deveria gerar uma resposta não funcionou.

O que causa o ERR_EMPTY_RESPONSE

  • Um processo worker caiu enquanto processava a requisição. Uma exceção não tratada, uma morte por falta de memória, ou uma falha de segmentação podem fechar a conexão antes de qualquer resposta ser escrita.
  • A aplicação expirou atrás de um proxy que fecha silenciosamente. Algumas configurações de proxy reverso fecham a conexão do cliente sem enviar uma página de erro quando o backend demora demais, em vez de devolver um 502 ou 504 adequado.
  • HTTP simples está sendo servido na porta HTTPS, ou o contrário. Um cliente falando TLS com uma porta que serve HTTP simples, ou o contrário, não recebe nenhuma resposta válida que a camada de protocolo do cliente consiga interpretar, e isso muitas vezes aparece como uma resposta vazia em vez de um erro de protocolo claro.
  • Uma extensão do navegador ou proxy local interfere na resposta. Bloqueadores de anúncio, extensões de privacidade, ou um proxy corporativo que inspeciona e às vezes lida mal com uma resposta podem reduzi-la a nada.
  • Um health check de balanceador de carga marca o backend como não saudável no meio da requisição, fechando a conexão com aquele backend antes de a resposta terminar.

Como saber de quem é a culpa

Desative extensões do navegador ou tente uma janela anônima primeiro; uma extensão do lado do cliente é uma das causas mais comuns e mais fáceis de descartar. Se a resposta vazia continuar com as extensões desligadas, teste num segundo dispositivo ou rede para descartar um proxy local. Se acontecer de forma consistente a partir de vários locais externos, o servidor ou uma queda de aplicação é a causa. Rodar uma verificação de HTTP a partir de vários pontos ao mesmo tempo confirma se a resposta vazia é universal ou ligada a um cliente, extensão, ou rede específicos.

Como corrigir o ERR_EMPTY_RESPONSE

Se você é o visitante

  1. Tente uma janela anônima ou privada com as extensões desativadas, para descartar um bloqueador de anúncio ou extensão de privacidade interferindo na resposta.
  2. Desative qualquer proxy local ou VPN e tente de novo, já que alguns interceptam e às vezes lidam mal com respostas em vez de repassá-las.
  3. Limpe o cache do navegador para o site; um estado de conexão em cache e corrompido pode ocasionalmente ressurgir como esse erro numa nova tentativa.
  4. Espere e recarregue. Se a causa é um processo worker que caiu no servidor, um supervisor de processo costuma reiniciá-lo em poucos segundos.

Se você administra o site

  1. Confira os logs de aplicação em busca de uma queda no mesmo horário da requisição que falhou; uma exceção não tratada ou uma morte por falta de memória é a causa mais comum e costuma deixar um rastro claro.
  2. Confirme que o protocolo correto está vinculado a cada porta. Verifique se a porta 443 está mesmo servindo TLS e a porta 80 servindo HTTP simples, e não o contrário, com uma checagem direta:
    curl -v https://example.com:443/
    curl -v http://example.com:80/
  3. Revise o comportamento de timeout do proxy reverso. No nginx, um backend que ultrapassa o proxy_read_timeout ainda deveria devolver um 504, então uma resposta vazia em vez de uma página de erro adequada geralmente significa que algo está fechando a conexão mais abaixo na pilha.
  4. Confira os logs de balanceador de carga e health check em busca de um backend marcado como não saudável perto do horário da falha, o que pode fechar conexões em andamento com aquela instância.
  5. Reinicie o worker ou serviço afetado se uma queda for confirmada, e monitore os logs de perto depois do reinício em busca de uma repetição do mesmo erro.

Como prevenir o ERR_EMPTY_RESPONSE

Uma queda de worker sob condições específicas, como um payload de requisição particular ou um pico de memória, pode ser intermitente o suficiente para passar num teste manual e ainda assim falhar para visitantes de verdade numa base regular. O monitoramento de HTTP contínuo, que verifica código de status e corpo da resposta num intervalo regular a partir de mais de 300 pontos de verificação em 158 cidades, detecta um padrão de resposta vazia que uma checagem manual única provavelmente deixaria passar, com alertas por e-mail, SMS, chamada de voz, Slack, Telegram e mais.

Erros relacionados

  • ERR_CONNECTION_RESET também encerra uma conexão que funcionava antes do fim, mas com um reset explícito em vez de um fechamento silencioso.
  • 502 Bad Gateway é uma resposta HTTP de erro completa, vinda de um proxy, diferente da resposta vazia que esse erro descreve.
  • 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_EMPTY_RESPONSE é a mesma coisa que um erro 502?

Não. Um 502 é uma resposta HTTP completa, com linha de status, cabeçalhos, e geralmente um corpo, enviada deliberadamente por um proxy. O ERR_EMPTY_RESPONSE significa que nenhuma resposta HTTP foi enviada, só uma conexão fechada.

Por que isso só acontece numa página específica?

Uma página que dispara esse erro de forma consistente, enquanto outras carregam bem, geralmente aponta para uma queda no caminho de código que aquela página ou endpoint de API específico usa, e não para um problema geral de servidor ou rede.

Um bloqueador de anúncio pode realmente causar esse erro?

Sim. Alguns bloqueadores de anúncio e extensões de privacidade interceptam e reescrevem respostas, e um bug ou uma regra agressiva pode ocasionalmente reduzir uma resposta legítima a nada, em vez de bloqueá-la de forma limpa.

O ERR_EMPTY_RESPONSE significa que meus dados foram perdidos?

Não necessariamente numa requisição GET, mas para o envio de um formulário ou uma chamada de API que muda dados, verifique se a ação de fato se completou no servidor antes de tentar de novo, já que o cliente não consegue saber, a partir de uma resposta vazia, se a requisição foi processada.

Por que o curl diz "Empty reply from server" em vez de um código de erro?

Porque não há resposta HTTP nenhuma para ler um código de status. A própria redação do curl descreve o evento de nível de transporte, uma conexão fechada sem dados, que fica uma camada abaixo do próprio protocolo HTTP.

Minha própria rede pode estar fechando a conexão em vez do servidor?

É menos comum que uma causa do lado do servidor, mas acontece. Um proxy corporativo ou firewall que encerra conexões de longa duração depois de um período fixo de inatividade pode produzir o mesmo sintoma; testar a mesma requisição numa rede diferente descarta isso rapidamente.

Verificar agora

Faça a verificação gratuita no seu próprio site, sem precisar de conta.

HTTP check

Monitorar permanentemente

Seja avisado no momento em que algo quebrar: o HostTracker verifica de mais de 300 localidades e notifica você por e-mail, SMS, Slack, Telegram e mais.

Recursos do HostTracker

Mais nesta seção: Corrigir: guias para os erros que aparecem de verdade