Le code 444 n’est pas un véritable code de statut HTTP. C’est une valeur spéciale de nginx : return 444; demande à nginx de fermer la connexion sans envoyer ni en-tête ni corps de réponse. Le 444 n’apparaît que dans le journal d’accès de nginx ; le client ne le reçoit jamais.
Les administrateurs l’utilisent pour écarter à moindre coût le trafic indésirable, comme les requêtes avec des en-têtes Host inconnus, les scanners à la recherche de fichiers wp-login.php ou .env, ou les User-Agents bloqués. Pour le client, la connexion se ferme simplement : les navigateurs affichent une erreur comme ERR_EMPTY_RESPONSE, et curl signale « Empty reply from server ».
Si le site est derrière Cloudflare, les visiteurs voient plutôt une erreur 520, car Cloudflare a reçu une réponse vide du serveur d’origine.
Exemple de réponse
# Nothing is sent back. The client only sees the connection close:
$ curl -i http://example.com/wp-login.php
curl: (52) Empty reply from server
# nginx access.log
203.0.113.7 - - [06/Nov/2026:10:15:32 +0000] "GET /wp-login.php HTTP/1.1" 444 0 "-" "curl/8.11.1"SEO et vérification des redirections
Comme aucune réponse n’est envoyée, les robots d’exploration enregistrent une erreur de connexion au lieu d’un code de statut, et Google traite ces erreurs comme des erreurs serveur : l’exploration ralentit et, si le problème persiste, les pages sont retirées de l’index. Assurez-vous que les règles 444 ne ciblent que le trafic indésirable, jamais les vrais robots d’exploration. Un vérificateur de redirections signale une erreur de connexion pour un tel saut, puisqu’il n’y a aucun statut à afficher.
Causes fréquentes et cas d’usage
- Un bloc
serverpar défaut écarte les requêtes adressées à des noms d’hôte inconnus avecreturn 444;. - Des règles de sécurité écartent les scanners de vulnérabilités et les bots malveillants.
- Une règle trop large cible aussi des requêtes légitimes : certains visiteurs reçoivent alors des réponses vides.