ERR_EMPTY_RESPONSE: o que é e como resolver

O que é o ERR_EMPTY_RESPONSE?

O ERR_EMPTY_RESPONSE é a página de erro do Chrome e do Edge que diz "Esta página não está funcionando. example.com não enviou nenhum dado." (em inglês, "This page isn't working. example.com didn't send any data."). No Chromium, é o erro de rede -324, definido como: "O servidor fechou a conexão sem enviar nenhum dado."

O navegador chegou mais longe do que na maioria dos erros de conexão. O endereço foi resolvido, a conexão foi aberta e o navegador enviou a requisição. Depois, o servidor, ou algo na frente dele, fechou a conexão com uma resposta vazia: sem código de status, sem cabeçalhos, sem página. O código do Chromium só usa esse erro para uma conexão nova que fecha com zero bytes. Quando uma conexão antiga, reaproveitada, é fechada, o Chrome tenta de novo em silêncio.

Como uma requisição foi realmente entregue, o ERR_EMPTY_RESPONSE normalmente aponta para o lado do servidor: um app que travou ao processar a requisição, uma regra que derruba conexões de propósito ou um serviço que aceitou a conexão mas não tinha nada por trás. Algumas causas no seu próprio computador também podem produzi-lo.

O que causa o ERR_EMPTY_RESPONSE?

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

Se o servidor reiniciou na hora errada, recarregar alguns segundos depois é tudo de que você precisa. Se o erro se repetir, abra a página em uma janela anônima (Ctrl + Shift + N, no Mac Cmd + Shift + N). A janela anônima começa sem cookies e sem extensões, então mostra rapidamente se algo guardado no seu navegador está envolvido.

Depois, verifique se o site está fora do ar para todo mundo. O Verificador de Cabeçalhos HTTP do DNS Robot solicita a página a partir dos nossos servidores: se recebermos uma resposta normal, o problema está entre você e o site. Se também não recebermos nada, o próprio site está falhando.

Correção 2: desligue a VPN, o proxy e a verificação HTTPS

Qualquer coisa que fica no meio das suas conexões pode aceitar a requisição e depois fechá-la sem repassar a resposta:

• VPN: desconecte-a por completo e recarregue.

• Proxy: no Windows 11, Configurações → Rede e Internet → Proxy → desative Usar um servidor proxy. No Mac, Ajustes do Sistema → Rede → a sua conexão → Detalhes… → Proxies.

• Verificação HTTPS do antivírus: desative só o recurso de verificação web ou HTTPS (que costuma se chamar HTTPS scanning, Web Shield ou SSL/TLS protocol filtering) e recarregue. Se isso resolver, adicione uma exclusão para o site e religue a verificação.

Correção 3: limpe os dados do site e desative as extensões

Cookies muito grandes ou corrompidos podem fazer o servidor descartar a requisição em vez de responder, o que muitas vezes aparece como um erro só depois que você faz login. Limpe os cookies desse site: clique no ícone à esquerda da barra de endereço → Cookies e dados do site (ou Configurações do site) → exclua os dados e depois faça login de novo.

Em seguida, desative todas as extensões em chrome://extensions e recarregue. Reative uma de cada vez para achar a que interfere, que muitas vezes é um bloqueador de anúncios, uma ferramenta de privacidade ou qualquer coisa que edite requisições.

Correção 4: limpe o DNS e redefina a pilha de rede

Se todos os sites dão resposta vazia em um computador, redefina a configuração de rede dele. No Windows, em um Prompt de Comando de administrador, execute os comandos abaixo e reinicie. No Mac, limpe o cache DNS e remova e adicione de novo a rede Wi-Fi.

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

Teste também outra rede, como os dados móveis do celular. Se o site funcionar ali, um filtro na sua rede habitual (da escola, do trabalho ou do provedor de internet) pode estar cortando a conexão.

ERR_EMPTY_RESPONSE no localhost e no Docker

Os desenvolvedores veem esse erro com mais frequência na própria máquina. As causas habituais:

• O app no contêiner Docker escuta em 127.0.0.1. Dentro de um contêiner, 127.0.0.1 significa "só este contêiner", então o redirecionamento de porta do Docker não tem a que se conectar e o seu navegador recebe uma resposta vazia (ou, dependendo da configuração, um reset de conexão). Faça o app escutar em 0.0.0.0 dentro do contêiner, por exemplo next dev -H 0.0.0.0, vite --host 0.0.0.0, flask run --host=0.0.0.0 ou uvicorn main:app --host 0.0.0.0.

• O mapeamento de portas do contêiner não bate. -p 8080:3000 encaminha a sua porta 8080 para a porta 3000 dentro do contêiner. Se o app na verdade escuta na 5000, toda requisição volta vazia.

• http:// em uma porta só HTTPS. Alguns servidores esperam TLS em uma porta e simplesmente desligam quando chega HTTP simples. Teste https://localhost:8443 em vez de http://.

• O servidor de desenvolvimento travou ao processar a requisição. Confira o terminal em que ele roda. Uma exceção ou um erro de falta de memória nesse momento é a sua resposta.

# Reproduza sem o navegador
curl -v http://localhost:8080/
# "Empty reply from server" = conexão aceita, nada enviado de volta

# Quais portas o contêiner publica e o que escuta dentro dele?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Para donos de sites: por que o seu servidor envia respostas vazias

• Travamentos e processos encerrados por falta de memória. Se o processo que atende a requisição morre, a conexão fecha sem nada enviado. Confira os logs do app e o 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, principalmente em páginas pesadas e uploads.

• Descartes de propósito. O return 444; especial do nginx fecha a conexão sem nenhuma resposta, e costuma ser usado para bloquear bots ruins ou hostnames desconhecidos. Se uma regra assim pega visitantes reais (uma regra de user agent ou GeoIP abrangente demais), eles veem ERR_EMPTY_RESPONSE, ou ERR_HTTP2_PROTOCOL_ERROR em conexões HTTP/2, em que o nginx dá reset no stream. WAFs, limitadores de taxa e serviços antibot podem fazer o mesmo.

• Redirecionamentos de porta e balanceadores de carga sem backend. Um listener que aceita a conexão mas não tem nenhum servidor saudável por trás pode fechá-la vazia. Confira a saúde dos destinos e se a porta do backend está certa.

• Tempos limite que fecham em vez de responder. Faça as requisições demoradas retornarem um erro adequado (como 504) em vez de fechar o socket em silêncio, para que os visitantes e o monitoramento vejam o que aconteceu.

• Requisições grandes demais. Cabeçalhos ou cookies muito grandes podem fazer alguns servidores descartarem a requisição. Mantenha os cookies pequenos.

# Alguma regra que derruba conexões?
sudo grep -rn "return 444" /etc/nginx/

# Teste de fora, do jeito que os visitantes se conectam
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE vs. erros parecidos

Guias relacionados: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway e 500 Internal Server Error. Para verificar se a porta de um servidor aceita conexões de fora, use o Verificador de Portas.