ERR_EMPTY_RESPONSE

O que este erro significa e como reconhecê-lo

• O navegador exibe ERR_EMPTY_RESPONSE em vez de um status HTTP como 200, 404 ou 500.
• A requisição falha antes que o navegador receba cabeçalhos de resposta, HTML ou uma página de erro da aplicação.
• Recarregar a página pode funcionar ocasionalmente se um worker, pool de conexões ou serviço upstream se recuperar.
• Um hostname ou uma rota pode falhar enquanto outros sites permanecem acessíveis.
• Uma requisição detalhada pela linha de comando pode mostrar que a conexão TCP é aberta e depois encerrada sem cabeçalhos de resposta.
• A URL pública pode falhar por meio de um reverse proxy, enquanto uma requisição autorizada ao serviço upstream apresenta comportamento diferente.
• O erro pode afetar apenas um navegador, dispositivo, rede de origem, VPN ou caminho de proxy.

Causas principais, por probabilidade

1. A aplicação ou o worker do PHP-FPM foi encerrado antes de enviar uma resposta. Erros fatais na aplicação, travamentos de workers, limites de processos, pressão de memória ou dependências indisponíveis podem encerrar a requisição antes que uma resposta HTTP normal seja gerada.
2. O Nginx ou o host atingiu a capacidade de conexões ou de descritores de arquivo. worker_connections efetivo, limites de arquivos abertos, conexões ativas e memória disponível afetam a conclusão das requisições e das conexões com o upstream.
3. Um reverse proxy não consegue manter uma conexão válida com o upstream. Comportamento incompatível de keepalive, reutilização de conexões, valores de timeout ou configurações do proxy podem fazer a conexão do cliente ser encerrada antes da chegada dos cabeçalhos do upstream.
4. O serviço upstream está indisponível ou reseta conexões. Um serviço pode estar em execução, mas incapaz de aceitar, processar ou concluir a requisição.
5. Um firewall, VPN, WAF, load balancer ou outro dispositivo de rede encerra a conexão. Isso é mais provável quando o erro depende da rede do cliente, do endereço de origem ou da rota.
6. Uma condição local do navegador interfere na requisição. Extensões, estado de conexão em cache, proxy local, VPN ou software de segurança podem produzir um sintoma semelhante quando outros clientes funcionam normalmente.

Como corrigir

1. Determine o escopo da falha

Registre o hostname, o caminho exato, o horário aproximado com fuso horário, o cliente, a rede e se a falha é consistente. Teste o mesmo caminho em uma janela anônima, outro navegador, outro dispositivo e — se permitido — outra rede.

Se apenas um navegador ou dispositivo falhar, investigue primeiro extensões, configurações de proxy local, software de VPN, estado de conexão em cache e controles de segurança do endpoint. Não presuma que a página inicial seja representativa; teste a rota específica que falha.

2. Verifique se o cliente recebe cabeçalhos de resposta

A partir de um cliente afetado ou próximo, faça uma requisição somente de leitura ao destino autorizado. Substitua os valores entre colchetes pelo hostname e caminho reais:

curl -v https://[your hostname]/[path]

Se a conexão for encerrada sem cabeçalhos de resposta, isso reforça o diagnóstico de resposta vazia. Se um status HTTP for retornado, investigue esse status, o redirecionamento, o comportamento do TLS ou a renderização do navegador. Quando possível, compare a saída detalhada de um cliente funcional e de um cliente com falha.

3. Correlacione a requisição com os logs do servidor

Use o horário e o caminho exatos para inspecionar:

1. Os logs de acesso e de erro do Nginx ou do servidor web relevante.
2. Os logs do PHP-FPM, se a rota executar PHP.
3. Os logs da aplicação em busca de erros fatais, exceções não tratadas e dependências que falharam.
4. Os logs do sistema operacional em busca de eventos de falta de memória, encerramento de processos, esgotamento de descritores de arquivo e falhas de serviço.

Uma entrada no access log sem uma resposta upstream concluída, um reset do upstream ou uma mensagem de encerramento de worker ajuda a identificar qual camada fechou a conexão. O erro do navegador, por si só, não identifica o componente responsável.

4. Verifique a saúde do PHP-FPM e da aplicação

Para uma rota dinâmica, determine se o PHP-FPM tem workers disponíveis e se os workers estão saindo repetidamente, atingindo limites configurados ou sendo encerrados pelo sistema operacional. Verifique deployments recentes, erros fatais, pressão de memória, chamadas lentas ao banco de dados e outras dependências bloqueadas.

Altere limites do PHP-FPM, o código da aplicação ou o estado do serviço somente depois de confirmar as evidências relevantes e avaliar a capacidade e o impacto operacional. Um restart pode limpar temporariamente workers com falha, mas não corrigirá um crash recorrente, esgotamento de recursos ou defeito na aplicação. Se um restart for autorizado, capture os logs e o estado dos processos antes de executá-lo.

5. Verifique a capacidade de conexões e descritores de arquivo do Nginx

Revise a configuração efetiva do Nginx e os limites do sistema operacional para o serviço afetado. Examine worker_connections, o comportamento dos processos workers, as conexões ativas, os limites de arquivos abertos, a memória disponível e as mensagens de erro que indiquem que um limite de recurso foi atingido.

Não aumente simplesmente worker_connections. O limite de descritores de arquivo do sistema operacional e a memória disponível precisam comportar a alteração. Registre os valores atuais e as condições de tráfego, siga o procedimento de alteração aprovado e valide o resultado após um reload ou restart controlado, se um deles for autorizado.

6. Isole uma falha do reverse proxy ou do upstream

Se houver uma CDN, load balancer, ingress ou reverse proxy Nginx na frente da aplicação, compare:

• A requisição pública através do proxy.
• Uma requisição autorizada ao upstream a partir do host do proxy ou de um ponto de teste interno equivalente.
• Os logs de erro do proxy e os logs da aplicação upstream para o mesmo timestamp.

Verifique se o proxy está reutilizando uma conexão que o upstream já fechou, se as configurações de keepalive são compatíveis e se os timeouts do proxy e do upstream são adequados para a rota. Altere uma configuração relacionada por vez, documente o impacto esperado e repita o mesmo teste.

7. Verifique os controles de rede e segurança

Se não houver entrada no log do servidor web no horário da falha, inspecione o firewall, a VPN, o WAF, o load balancer, o roteamento e o caminho de segurança do cliente. Compare uma rede de origem funcional com a que apresenta falha e procure decisões de política, resets de conexão ou tratamento de conexões ociosas que correspondam ao timestamp.

Se a conexão desaparecer antes de chegar ao servidor web, encaminhe o caso à equipe de rede ou hospedagem em vez de alterar o código da aplicação.

8. Valide a correção preservando as evidências

Após uma alteração aprovada na aplicação, configuração ou rede, repita os mesmos testes de caminho e cliente. Confirme que a resposta agora inclui cabeçalhos e um status HTTP apropriado, não apenas que o navegador deixou de exibir a mensagem original. Revise os logs do proxy, servidor web, upstream, aplicação e sistema e mantenha os valores de configuração anteriores e posteriores para comparação ou rollback.

Prevenção e como verificar a correção

• Monitore erros do servidor web, resets do upstream, disponibilidade de workers do PHP-FPM, encerramentos de processos, pressão de memória, uso de arquivos abertos e alertas de limite de conexões.
• Documente as políticas de reverse proxy, keepalive do upstream e timeout e teste-as após alterações na infraestrutura.
• Inclua um identificador de requisição ou um timestamp preciso com fuso horário nos relatórios de incidentes para que os logs do proxy, servidor web e aplicação possam ser correlacionados.
• Faça testes de capacidade das configurações de conexão e descritores de arquivo antes de aumentar o tráfego ou alterar a quantidade de workers.
• Faça deployments de alterações da aplicação com um plano de rollback e monitore imediatamente erros fatais, crashes de workers e falhas de dependências.
• Mantenha um procedimento autorizado para testar separadamente o endpoint público e o serviço upstream.
• Mantenha restarts de serviços e alterações de limites em produção dentro de um processo de alteração aprovado.

Perguntas frequentes