ERR_EMPTY_RESPONSE : causes et corrections

Ce que signifie ERR_EMPTY_RESPONSE

Cette erreur se situe plus tard dans le cycle de vie de la requête qu'une connexion refusée ou dont le délai est dépassé. Le navigateur se connecte avec succès au serveur, et dans une requête HTTPS le handshake TLS s'achève généralement aussi, mais après l'envoi de la requête, la connexion se ferme sans aucune ligne de statut HTTP, aucun en-tête, et aucun corps du tout. C'est différent d'une page d'erreur 500 ou 502, qui reste une réponse HTTP complète ; ici, il n'y a rien à analyser car rien n'est revenu.

Cela rend ERR_EMPTY_RESPONSE plus difficile à diagnostiquer depuis le côté client que la plupart des erreurs de connexion, puisque chaque couche jusqu'à la connexion de transport incluse a fonctionné correctement. La faute se situe précisément dans ce qui génère la réponse HTTP : le processus applicatif, le framework traitant la requête, ou un proxy devant lui qui a fermé le socket au lieu de transmettre, ou de générer, une page d'erreur correcte.

Comment l'erreur apparaît

Chrome affiche « This site can't be reached ... ERR_EMPTY_RESPONSE » une fois que la connexion se ferme sans données. curl rapporte la même condition en termes clairs :

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

« Empty reply from server » est le libellé exact de curl pour cette condition, et c'est le signal le plus clair que la connexion elle-même a fonctionné tandis que ce qui aurait dû générer une réponse ne l'a pas fait.

Ce qui provoque ERR_EMPTY_RESPONSE

• Un processus worker a planté pendant le traitement de la requête. Une exception non gérée, une extinction pour manque de mémoire, ou une erreur de segmentation peuvent fermer la connexion avant qu'aucune réponse ne soit écrite.
• L'application a dépassé son délai derrière un proxy qui ferme silencieusement. Certaines configurations de reverse proxy ferment la connexion du client sans envoyer de page d'erreur quand le backend prend trop de temps, au lieu de renvoyer un 502 ou 504 correct.
• Du HTTP simple est servi sur le port HTTPS, ou l'inverse. Un client parlant TLS à un port servant du HTTP simple, ou l'inverse, n'obtient aucune réponse valide que la couche protocolaire du client puisse analyser, et cela se manifeste souvent comme une réponse vide plutôt qu'une erreur de protocole claire.
• Une extension de navigateur ou un proxy local interfère avec la réponse. Les bloqueurs de publicité, les extensions de confidentialité, ou un proxy d'entreprise qui inspecte et gère parfois mal une réponse peuvent la réduire à néant.
• Une vérification de santé d'équilibreur de charge marque le backend comme défaillant en pleine requête, fermant la connexion vers ce backend avant que la réponse ne se termine.

Comment savoir de qui vient la faute

Désactivez d'abord les extensions de navigateur ou essayez une fenêtre incognito ; une extension côté client est l'une des causes les plus courantes et les plus faciles à écarter. Si la réponse vide persiste avec les extensions désactivées, testez depuis un second appareil ou réseau pour écarter un proxy local. Si cela se produit systématiquement depuis plusieurs emplacements extérieurs, le serveur ou un plantage applicatif en est la cause. Lancer une vérification HTTP depuis plusieurs points de contrôle à la fois confirme si la réponse vide est universelle ou liée à un seul client, une extension, ou un réseau.

Comment corriger ERR_EMPTY_RESPONSE

Si vous êtes visiteur

1. Essayez une fenêtre incognito ou privée avec les extensions désactivées pour écarter un bloqueur de publicité ou une extension de confidentialité qui interfère avec la réponse.
2. Désactivez tout proxy local ou VPN et réessayez, puisque certains interceptent et gèrent parfois mal les réponses au lieu de les laisser passer.
3. Videz le cache du navigateur pour le site ; un état de connexion mis en cache et corrompu peut occasionnellement resurgir sous forme de cette erreur lors d'une nouvelle tentative.
4. Attendez et rechargez. Si la cause est un processus worker qui a planté sur le serveur, un superviseur de processus le redémarre généralement en quelques secondes.

Si vous gérez le site

1. Vérifiez les journaux applicatifs à la recherche d'un plantage au même horodatage que la requête échouée ; une exception non gérée ou une extinction pour manque de mémoire est la cause la plus courante et laisse généralement une trace claire.
2. Confirmez que le bon protocole est lié à chaque port. Vérifiez que le port 443 sert réellement du TLS et que le port 80 sert du HTTP simple, pas l'inverse, avec une vérification directe :

   curl -v https://example.com:443/
   curl -v http://example.com:80/

3. Passez en revue le comportement de délai du reverse proxy. Sur nginx, un backend qui dépasse proxy_read_timeout devrait quand même renvoyer un 504, donc une réponse vide au lieu d'une page d'erreur correcte signifie généralement que quelque chose ferme la connexion plus bas dans la pile.
4. Vérifiez les journaux d'équilibreur de charge et de vérification de santé pour un backend marqué défaillant autour du moment de l'échec, ce qui peut fermer les connexions en cours vers cette instance.
5. Redémarrez le worker ou le service affecté si un plantage est confirmé, et surveillez étroitement les journaux après le redémarrage pour une répétition de la même erreur.

Comment prévenir ERR_EMPTY_RESPONSE

Un plantage de worker dans des conditions spécifiques, comme une charge utile de requête particulière ou un pic de mémoire, peut être suffisamment intermittent pour passer un test manuel tout en échouant quand même pour de vrais visiteurs selon un certain rythme. Une surveillance HTTP continue qui vérifie le code de statut et le corps de la réponse à intervalle régulier depuis plus de 300 points de contrôle dans 158 villes détecte un schéma de réponse vide qu'une vérification manuelle unique manquerait probablement, avec des alertes par e-mail, SMS, appel vocal, Slack, Telegram et bien plus.

Erreurs associées

• ERR_CONNECTION_RESET termine aussi prématurément une connexion qui fonctionnait, mais avec une réinitialisation explicite plutôt qu'une fermeture silencieuse.
• 502 Bad Gateway est une réponse d'erreur HTTP correcte venant d'un proxy, contrairement à la réponse vide que décrit cette erreur.
• This site can't be reached couvre l'ensemble complet des erreurs de connexion que Chrome regroupe sous un seul titre.

Questions fréquentes

ERR_EMPTY_RESPONSE est-il la même chose qu'une erreur 502 ?

Non. Un 502 est une réponse HTTP complète avec une ligne de statut, des en-têtes, et généralement un corps, envoyée délibérément par un proxy. ERR_EMPTY_RESPONSE signifie qu'aucune réponse HTTP n'a été envoyée du tout, juste une connexion fermée.

Pourquoi cela n'arrive-t-il que sur une page spécifique ?

Une page qui déclenche systématiquement cette erreur, tandis que d'autres se chargent bien, pointe généralement vers un plantage dans le chemin de code que cette page ou ce point de terminaison d'API spécifique utilise, plutôt qu'un problème général de serveur ou de réseau.

Un bloqueur de publicité peut-il vraiment causer cette erreur ?

Oui. Certains bloqueurs de publicité et extensions de confidentialité interceptent et réécrivent les réponses, et un bug ou une règle agressive peuvent occasionnellement réduire une réponse légitime à néant plutôt que de la bloquer proprement.

ERR_EMPTY_RESPONSE signifie-t-il que mes données ont été perdues ?

Pas nécessairement pour une requête GET, mais pour une soumission de formulaire ou un appel d'API qui modifie des données, vérifiez si l'action s'est réellement terminée sur le serveur avant de réessayer, puisque le client ne peut pas savoir à partir d'une réponse vide si la requête a été traitée.

Pourquoi curl dit-il « Empty reply from server » au lieu d'un code d'erreur ?

Parce qu'il n'y a aucune réponse HTTP dont lire un code de statut. Le libellé propre de curl décrit l'événement au niveau du transport, une connexion fermée sans données, qui se situe une couche en dessous du protocole HTTP lui-même.

Mon propre réseau pourrait-il fermer la connexion au lieu du serveur ?

C'est moins courant qu'une cause côté serveur mais cela arrive. Un proxy ou un pare-feu d'entreprise qui termine les connexions de longue durée après une période d'inactivité fixe peut produire le même symptôme ; tester la même requête depuis un autre réseau écarte rapidement cette hypothèse.