ERR_EMPTY_RESPONSE : signification et solutions

Qu'est-ce que ERR_EMPTY_RESPONSE ?

ERR_EMPTY_RESPONSE est la page d'erreur de Chrome et d'Edge qui 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 ».

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. Le code de Chromium n'utilise cette erreur que pour une nouvelle connexion qui se ferme avec zéro octet. Quand une ancienne connexion réutilisée se ferme, Chrome réessaie discrètement à la place.

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.

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 cookies ni extensions : 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. L'outil En-têtes HTTP de DNS Robot demande la page depuis nos serveurs : si nous obtenons une réponse normale, le problème se situe entre vous et le site. Si nous n'obtenons 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 → désactivez Utiliser un serveur proxy. 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

Des cookies très volumineux ou corrompus peuvent pousser un serveur à abandonner la requête au lieu d'y répondre, ce qui se traduit souvent par une erreur qui n'apparaît qu'après connexion à votre compte. Effacez les cookies de ce site : cliquez sur l'icône à gauche de la barre d'adresse → Cookies et données de site (ou Paramètres des sites) → supprimez les données, 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 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.

• 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. Des en-têtes ou des cookies très volumineux peuvent pousser certains serveurs à abandonner la requête. 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.