Código de status HTTP · Não oficial, usado por nginx
Erro 444 No Response
O 444 é um código exclusivo do nginx: significa que o nginx fechou a conexão sem enviar nem um byte de resposta. Ele só aparece no seu próprio access log, geralmente porque uma regra `return 444;` pegou um scanner, um bot ou um pedido para um nome de host desconhecido.
| Classe | 4xx/5xx, Códigos não oficiais (nginx, Cloudflare) |
|---|---|
| Também chamado de | Connection Closed Without Response |
| Definido em | nginx docs: return directive |
| Pode ir para o cache por padrão | Não; nada é enviado, então não há o que guardar |
| Pode repetir o pedido | Não; o nginx derruba a conexão de propósito e vai fazer de novo |
| Cabeçalhos relevantes | Nenhum específico deste código |
O que significa o 444
A documentação da diretiva return do nginx é direta: o código não padrão 444 fecha a conexão sem enviar cabeçalho de resposta. Internamente ele se chama NGX_HTTP_CLOSE. O número é gravado no access log para você poder contar esses pedidos, mas nunca trafega pela rede, então nenhum navegador ou cliente de API recebe um status 444.
Do outro lado, o cliente vê uma conexão que terminou sem resposta nenhuma. O curl mostra "Empty reply from server" (código de saída 52) e o Chrome mostra ERR_EMPTY_RESPONSE. A ideia é essa: um bot testando /wp-login.php ou acessando o servidor pelo IP puro não recebe página, cabeçalho nem pista de qual software está rodando.
Quando usar
- Num bloco default_server, para descartar pedidos cujo cabeçalho Host não bate com nenhum dos seus sites, que é a maior parte do tráfego de scanners que chega num IP público.
- Para caminhos ou user agents que você nunca quer atender, como sondagens de vulnerabilidade de softwares que você nem usa.
- Evite quando uma pessoa de verdade pode cair ali: ela recebe um erro vazio do navegador sem explicação, enquanto um 403 ou 404 diria alguma coisa.
Causas comuns
Se você está visitando o site
- O servidor tem uma regra que descarta seu pedido em silêncio, muitas vezes porque você acessou pelo IP ou por um domínio antigo que ele não atende mais.
- Seu user agent, caminho ou IP caiu numa lista de bloqueio feita para bots.
Se você administra o servidor
- Um `return 444;` num server block coringa, num location ou num if sobre $http_user_agent.
- O DNS de um domínio novo já aponta para o servidor antes de existir um server_name correspondente, e o pedido cai no default server que responde 444.
Como resolver
Se você está visitando o site
- Use o endereço que o dono do site divulga, e não o IP ou um domínio antigo.
- Se um navegador comum recebe ERR_EMPTY_RESPONSE num site que você deveria acessar, avise o dono do site; nada do seu lado resolve.
Se você administra o servidor
- Descubra qual regra disparou: procure " 444 " no access log e compare o cabeçalho Host e o caminho com seus server_name e blocos location.
- Adicione o server_name que falta para um domínio legítimo, ou restrinja o padrão de user agent que pegou clientes reais.
- Para o coringa em HTTPS, combine o bloco 444 com ssl_reject_handshake on (nginx 1.19.4+) e você não precisa de certificado para nomes desconhecidos.
Como diagnosticar o 444
# Drop requests for host names you don't serve (bare IP, scanners)
server {
listen 80 default_server;
server_name _;
return 444;
}
# HTTPS catch-all without a certificate (nginx 1.19.4+)
server {
listen 443 ssl default_server;
ssl_reject_handshake on;
}
# Inside a real site: drop probes for software you don't run
location ~* ^/(wp-login\.php|xmlrpc\.php) {
return 444;
}# What a client sees
curl -v http://SERVER_IP/
# * Empty reply from server
# curl: (52) Empty reply from serverCostuma ser confundido com
- 444 vs 403
- O 403 é uma resposta de verdade, com cabeçalhos e geralmente um corpo explicando a recusa; o 444 não envia nada, só desliga.
- 444 vs 499
- Os dois só existem no log do nginx, mas o 444 significa que o nginx fechou a conexão e o 499 que o cliente fechou.
Perguntas frequentes
- Um navegador pode receber o status 444?
- Não. O nginx fecha a conexão TCP sem escrever linha de status, então o navegador mostra um erro de rede como ERR_EMPTY_RESPONSE. O 444 só existe no access log do nginx.
- O 444 é melhor que o 403 para bloquear bots?
- Para scanners automáticos, sim: gasta menos banda e não revela nada sobre o servidor. Para qualquer coisa que uma pessoa possa acessar, o 403 é mais gentil, porque explica o que aconteceu e como conseguir acesso.
- O return 444 funciona com HTTPS e HTTP/2?
- A diretiva funciona em qualquer server block, mas no HTTPS o handshake TLS acontece antes do nginx ver o pedido, então o bloco coringa ainda precisa de certificado. Desde o nginx 1.19.4, ssl_reject_handshake on recusa o handshake para nomes desconhecidos.
Revisado em por Arielton Oberek.