ERR_EMPTY_RESPONSE : signification et solutions

Qu'est-ce que ERR_EMPTY_RESPONSE ?

ERR_EMPTY_RESPONSE est le code d'erreur que Chrome et Edge affichent quand un site n'envoie rien en retour ; la page de Chrome indique « Cette page ne fonctionne pas. example.com n'a envoyé aucune donnée. » Dans Chromium, il s'agit de l'erreur réseau -324, définie ainsi : « le serveur a fermé la connexion sans envoyer de données » (net_error_list.h).

Le navigateur est allé plus loin qu'avec la plupart des erreurs de connexion. L'adresse a été résolue, la connexion s'est ouverte et le navigateur a envoyé sa requête. Puis le serveur, ou quelque chose placé devant lui, a fermé la connexion avec une réponse vide : pas de code de statut, pas d'en-têtes, pas de page. Seul le code HTTP/1.1 de Chromium utilise cette erreur, et uniquement pour une nouvelle connexion qui se ferme avec zéro octet (Chromium) ; quand une ancienne connexion réutilisée se ferme, Chrome réessaie discrètement, et en HTTP/2 la même fermeture s'affiche comme ERR_CONNECTION_CLOSED. C'est pourquoi on la voit surtout sur localhost, sur des adresses en HTTP simple et sur des serveurs qui ne parlent que HTTP/1.1.

Comme une requête a bien été livrée, ERR_EMPTY_RESPONSE désigne généralement le côté serveur : une application qui a planté en traitant la requête, une règle qui coupe volontairement les connexions, ou un service qui a accepté la connexion sans rien derrière. Quelques causes sur votre propre ordinateur peuvent aussi la produire.

NS_ERROR_NET_EMPTY_RESPONSE de Firefox, c'est autre chose

Firefox a une erreur au nom presque identique, qui signifie autre chose. NS_ERROR_NET_EMPTY_RESPONSE est le code de Firefox pour ordinateur quand une page revient avec un statut d'erreur en 400 (comme 403 ou 404) et un corps vide (source de Firefox) ; Firefox pour Android affiche une page blanche à la place. Le serveur a bien répondu ; il n'a simplement envoyé aucune page avec l'erreur, et Firefox affiche donc sa propre page « Il semble y avoir un problème sur ce site ».

La solution est donc différente aussi : trouvez quel statut le serveur a envoyé, et pourquoi. Le panneau Réseau du navigateur l'affiche ; curl -I peut obtenir une autre réponse, car les règles anti-bots traitent souvent curl autrement qu'un navigateur. Un pare-feu ou une règle anti-bot qui répond 403 avec un corps vide est une cause possible. L'équivalent Firefox de la réponse vide de Chrome, une connexion fermée sans rien envoyer, est NS_ERROR_NET_RESET, affiché comme « La connexion a été réinitialisée ».

Quelles sont les causes de ERR_EMPTY_RESPONSE ?

Solution 1 : rechargez et essayez la navigation privée

Si le serveur a redémarré au mauvais moment, recharger quelques secondes plus tard suffit. Si l'erreur se répète, ouvrez la page dans une fenêtre de navigation privée (Ctrl + Maj + N, sur Mac Cmd + Maj + N). La navigation privée démarre sans vos cookies enregistrés et n'exécute que les extensions que vous y avez autorisées (aucune par défaut) : elle vous dit vite si quelque chose de stocké dans votre navigateur est en cause.

Vérifiez ensuite si le site est en panne pour tout le monde. Le Vérificateur de site en panne charge la page depuis 11 endroits, et l'outil En-têtes HTTP de DNS Robot affiche le statut et les en-têtes que reçoit notre serveur : s'ils obtiennent une réponse normale, le problème se situe entre vous et le site. S'ils n'obtiennent rien non plus, c'est le site lui-même qui échoue.

Solution 2 : désactivez VPN, proxy et analyse HTTPS

Tout ce qui s'intercale dans vos connexions peut accepter la requête, puis la fermer sans vous transmettre la réponse :

• VPN : déconnectez-le complètement et rechargez.
• Proxy : sous Windows 11, Paramètres → Réseau et Internet → Proxy → à côté de Utiliser un serveur proxy, sélectionnez Modifier et désactivez-le (désactivez aussi « Use setup script » s'il est activé). Sur Mac, Réglages Système → Réseau → votre connexion → Détails… → Proxys.
• Analyse HTTPS de l'antivirus : désactivez uniquement la fonction d'analyse web ou HTTPS (souvent appelée analyse HTTPS, Agent Web (Web Shield) ou filtrage des protocoles SSL/TLS) et rechargez. Si cela règle le problème, ajoutez une exclusion pour le site et réactivez l'analyse.

Solution 3 : effacez les données du site et désactivez les extensions

La plupart des serveurs répondent aux cookies très volumineux par une erreur 400 ou 431, mais certains serveurs et proxys abandonnent la requête à la place, ce qui se traduit par une réponse vide seulement après connexion à votre compte. Effacez les cookies de ce site : cliquez sur Afficher des informations à propos du site à gauche de la barre d'adresse → Cookies et données des sites → Gérer les données des sites sur l'appareil → supprimez-les, puis reconnectez-vous.

Ensuite, désactivez toutes les extensions dans chrome://extensions et rechargez. Réactivez-les une par une pour trouver celle qui interfère : souvent un bloqueur de publicités, un outil de confidentialité ou tout ce qui modifie les requêtes.

Solution 4 : videz le DNS et réinitialisez la pile réseau

Si tous les sites renvoient des réponses vides sur un même ordinateur, réinitialisez sa configuration réseau. Sous Windows, exécutez les commandes ci-dessous dans une invite de commandes administrateur, puis redémarrez. Sur Mac, videz le cache DNS, puis supprimez et ajoutez à nouveau le réseau Wi-Fi.

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

Essayez aussi un autre réseau, comme les données mobiles de votre téléphone. Si le site y fonctionne, un filtre sur votre réseau habituel (école, travail ou FAI) coupe peut-être la connexion.

ERR_EMPTY_RESPONSE sur localhost et Docker

C'est sur leur propre machine que les développeurs voient le plus souvent cette erreur. Les causes habituelles :

• L'application d'un conteneur Docker écoute sur 127.0.0.1. Dans un conteneur, 127.0.0.1 signifie « uniquement ce conteneur » : la redirection de port de Docker n'a donc rien à quoi se connecter et votre navigateur reçoit une réponse vide (ou, selon la configuration, un reset de connexion). Faites écouter l'application sur 0.0.0.0 dans le conteneur, par exemple vite --host 0.0.0.0, flask run --host=0.0.0.0 ou uvicorn main:app --host 0.0.0.0 (next dev écoute déjà sur toutes les interfaces).
• Le mappage de ports du conteneur ne correspond pas. -p 8080:3000 redirige votre port 8080 vers le port 3000 à l'intérieur du conteneur. Si l'application écoute en réalité sur le 5000, chaque requête revient vide.
• http:// sur un port qui n'accepte que HTTPS. Certains serveurs attendent du TLS sur un port et raccrochent simplement quand du HTTP en clair arrive. Essayez https://localhost:8443 au lieu de http://.
• Le serveur de développement a planté en traitant la requête. Regardez le terminal dans lequel il tourne. Une exception ou une erreur de mémoire insuffisante à ce moment-là vous donne la réponse.

# Reproduire sans le navigateur
curl -v http://localhost:8080/
# "Empty reply from server" = connexion acceptée, rien n'a été renvoyé

# Quels ports le conteneur publie-t-il, et qu'est-ce qui écoute à l'intérieur ?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Pour les propriétaires de sites : pourquoi votre serveur envoie des réponses vides

• Plantages et arrêts pour mémoire insuffisante. Si le processus qui traite la requête meurt, la connexion se ferme sans rien envoyer. Consultez les logs de l'application et dmesg -T | grep -i "killed process" pour repérer l'OOM killer de Linux, surtout sur les pages lourdes et les envois de fichiers.
• Coupures volontaires. Le return 444; spécial de nginx ferme la connexion sans aucune réponse, et sert souvent à bloquer les mauvais bots ou les noms d'hôte inconnus. Si une telle règle touche de vrais visiteurs (une règle de user agent ou de GeoIP trop large), ils voient ERR_EMPTY_RESPONSE, ou ERR_HTTP2_PROTOCOL_ERROR sur les connexions HTTP/2, où nginx réinitialise plutôt le flux. Les WAF, limiteurs de débit et services anti-bots peuvent faire de même.
• Redirections de port et répartiteurs de charge sans backend. Un écouteur qui accepte la connexion sans serveur sain derrière lui peut la fermer à vide. Vérifiez l'état de santé des cibles et que le port du backend correspond.
• Délais dépassés qui ferment au lieu de répondre. Faites en sorte que les requêtes longues renvoient une vraie erreur (comme 504) au lieu de fermer silencieusement le socket, pour que les visiteurs et la supervision voient ce qui s'est passé.
• Requêtes trop volumineuses. La plupart des serveurs répondent aux en-têtes ou aux cookies très volumineux par une erreur 400 ou 431, mais certains abandonnent la requête à la place. Gardez des cookies légers.

# Des règles qui coupent les connexions ?
sudo grep -rn "return 444" /etc/nginx/

# Tester depuis l'extérieur, comme se connectent les visiteurs
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE et les erreurs similaires

Guides associés : ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway et 500 Internal Server Error. Pour vérifier si le port d'un serveur accepte les connexions depuis l'extérieur, utilisez le Vérificateur de ports.