ERR_EMPTY_RESPONSE

Ce que signifie cette erreur et comment la reconnaître

• Le navigateur affiche ERR_EMPTY_RESPONSE au lieu d’un statut HTTP tel que 200, 404 ou 500.
• La requête échoue avant que le navigateur ne reçoive les en-têtes de réponse, le HTML ou une page d’erreur applicative.
• Un rechargement peut parfois réussir si un worker, un pool de connexions ou un service upstream récupère.
• Un nom d’hôte ou une route peut échouer alors que les autres sites restent accessibles.
• Une requête en ligne de commande en mode verbeux peut montrer que la connexion TCP s’ouvre, puis se ferme sans en-têtes de réponse.
• L’URL publique peut échouer via un reverse proxy alors qu’une requête autorisée vers le service upstream se comporte différemment.
• L’erreur peut ne concerner qu’un navigateur, un appareil, un réseau source, un VPN ou un chemin passant par un proxy.

Causes principales, classées par probabilité

1. L’application ou le worker PHP-FPM s’est arrêté avant d’envoyer une réponse. Des erreurs applicatives fatales, des crashes de workers, des limites de processus, une pression mémoire ou des dépendances défaillantes peuvent interrompre la requête avant la génération d’une réponse HTTP normale.
2. Nginx ou l’hôte a atteint sa capacité en connexions ou en descripteurs de fichiers. Les valeurs effectives de worker_connections, les limites de fichiers ouverts, les connexions actives et la mémoire disponible influencent toutes la capacité à terminer les requêtes et les connexions upstream.
3. Un reverse proxy ne parvient pas à maintenir une connexion upstream valide. Un comportement keepalive, une réutilisation de connexion, des valeurs de timeout ou des paramètres de proxy incompatibles peuvent fermer la connexion client avant l’arrivée des en-têtes upstream.
4. Le service upstream est indisponible ou réinitialise les connexions. Un service peut être démarré tout en étant incapable d’accepter, de traiter ou de terminer la requête.
5. Un firewall, un VPN, un WAF, un load balancer ou un autre équipement réseau ferme la connexion. Cette cause est plus probable lorsque l’erreur dépend du réseau client, de l’adresse source ou du chemin réseau.
6. Une condition locale au navigateur perturbe la requête. Des extensions, un état de connexion mis en cache, un proxy local, un VPN ou un logiciel de sécurité peuvent produire un symptôme similaire lorsque les autres clients fonctionnent normalement.

Comment corriger le problème

1. Déterminer l’étendue de la panne

Notez le nom d’hôte, le chemin exact, l’heure approximative avec le fuseau horaire, le client, le réseau et le caractère systématique ou non de l’échec. Testez le même chemin dans une fenêtre privée, avec un autre navigateur, un autre appareil et, si cela est autorisé, depuis un autre réseau.

Si un seul navigateur ou appareil échoue, commencez par examiner les extensions, les paramètres du proxy local, le logiciel VPN, l’état de connexion mis en cache et les contrôles de sécurité du terminal. Ne supposez pas que la page d’accueil est représentative : testez la route spécifique qui échoue.

2. Vérifier si le client reçoit les en-têtes de réponse

Depuis un client concerné ou proche, effectuez une requête en lecture seule vers la cible autorisée. Remplacez les valeurs entre crochets par le nom d’hôte et le chemin réels :

curl -v https://[your hostname]/[path]

Si la connexion se ferme sans en-têtes de réponse, cela confirme le diagnostic d’absence de réponse. Si un statut HTTP est renvoyé, examinez plutôt ce statut, la redirection, le comportement TLS ou l’affichage dans le navigateur. Comparez si possible la sortie verbeuse d’un client fonctionnel et d’un client en échec.

3. Corréler la requête avec les journaux du serveur

Utilisez l’heure et le chemin exacts pour examiner :

1. Les journaux d’accès et d’erreurs de Nginx ou du serveur web concerné.
2. Les journaux de PHP-FPM si la route invoque PHP.
3. Les journaux de l’application pour détecter les erreurs fatales, les exceptions non interceptées et les dépendances défaillantes.
4. Les journaux du système d’exploitation pour détecter les événements de manque de mémoire, l’arrêt de processus, l’épuisement des descripteurs de fichiers et les défaillances de services.

Une entrée dans le journal d’accès sans réponse upstream terminée, une réinitialisation upstream ou un message d’arrêt d’un worker aide à identifier la couche qui a fermé la connexion. L’erreur du navigateur seule ne permet pas d’identifier le composant responsable.

4. Vérifier l’état de PHP-FPM et de l’application

Pour une route dynamique, déterminez si PHP-FPM dispose de workers disponibles et si ceux-ci se terminent de manière répétée, atteignent les limites configurées ou sont arrêtés par le système d’exploitation. Recherchez les déploiements récents, les erreurs fatales, la pression mémoire, les appels lents à la base de données et les autres dépendances bloquées.

Ne modifiez les limites de PHP-FPM, le code de l’application ou l’état d’un service qu’après avoir confirmé les éléments pertinents et évalué la capacité ainsi que l’impact opérationnel. Un redémarrage peut supprimer temporairement des workers défaillants, mais il ne corrigera pas un crash récurrent, l’épuisement d’une ressource ou un défaut applicatif. Si un redémarrage est autorisé, collectez les journaux et l’état des processus avant de l’effectuer.

5. Vérifier la capacité de Nginx en connexions et en descripteurs de fichiers

Examinez la configuration effective de Nginx et les limites du système d’exploitation pour le service concerné. Analysez worker_connections, le comportement des processus workers, les connexions actives, les limites de fichiers ouverts, la mémoire disponible et les messages d’erreur indiquant qu’une limite de ressource a été atteinte.

N’augmentez pas simplement worker_connections. La limite de descripteurs de fichiers du système d’exploitation et la mémoire disponible doivent permettre cette modification. Relevez les valeurs actuelles et les conditions de trafic, suivez la procédure de changement approuvée et validez le résultat après un reload ou un redémarrage contrôlé si celui-ci est autorisé.

6. Isoler une défaillance du reverse proxy ou de l’upstream

Si un CDN, un load balancer, un ingress ou un reverse proxy Nginx se trouve devant l’application, comparez :

• La requête publique passant par le proxy.
• Une requête autorisée vers l’upstream depuis l’hôte du proxy ou depuis un point de test interne équivalent.
• Les journaux d’erreurs du proxy et les journaux de l’application upstream pour le même horodatage.

Vérifiez si le proxy réutilise une connexion que l’upstream a déjà fermée, si les paramètres keepalive sont compatibles et si les timeouts du proxy et de l’upstream sont adaptés à la route. Modifiez un seul paramètre associé à la fois, documentez l’impact attendu et répétez le même test.

7. Vérifier les contrôles réseau et de sécurité

S’il n’existe aucune entrée dans le journal du serveur web au moment de l’échec, examinez le firewall, le VPN, le WAF, le load balancer, le routage et le chemin de sécurité côté client. Comparez un réseau source fonctionnel avec le réseau en échec et recherchez les décisions de politique, les réinitialisations de connexion ou la gestion des connexions inactives correspondant à l’horodatage.

Si la connexion disparaît avant d’atteindre le serveur web, adressez-vous à l’équipe réseau ou à l’hébergeur plutôt que de modifier le code de l’application.

8. Valider la correction tout en conservant les éléments de preuve

Après un changement approuvé concernant l’application, la configuration ou le réseau, répétez les tests avec le même chemin et les mêmes clients. Vérifiez que la réponse contient désormais des en-têtes et un statut HTTP approprié, et pas seulement que le navigateur n’affiche plus le message d’origine. Examinez les journaux du proxy, du serveur web, de l’upstream, de l’application et du système, puis conservez les valeurs de configuration avant et après le changement pour comparaison ou rollback.

Prévention et vérification du correctif

• Surveillez les erreurs du serveur web, les réinitialisations upstream, la disponibilité des workers PHP-FPM, les arrêts de processus, la pression mémoire, l’utilisation des fichiers ouverts et les alertes de limites de connexions.
• Documentez les politiques de reverse proxy, de keepalive upstream et de timeout, puis testez-les après les changements d’infrastructure.
• Incluez un identifiant de requête ou un horodatage précis avec le fuseau horaire dans les rapports d’incident afin de corréler les journaux du proxy, du serveur web et de l’application.
• Testez la capacité des paramètres de connexions et de descripteurs de fichiers avant d’augmenter le trafic ou de modifier le nombre de workers.
• Déployez les changements applicatifs avec un plan de rollback et surveillez immédiatement les erreurs fatales, les crashes de workers et les défaillances de dépendances.
• Maintenez une procédure autorisée pour tester séparément le point d’accès public et le service upstream.
• Effectuez les redémarrages de services et les changements de limites en production dans le cadre d’un processus de changement approuvé.

Questions fréquentes