Erreurs HTTP et serveur

À propos de cette catégorie d’erreurs

# Erreurs HTTP et serveur

Les erreurs HTTP et serveur surviennent lorsqu’une requête ne peut pas être traitée normalement. Certains échecs renvoient un code d’état HTTP tel que 500, 502, 503 ou 504. D’autres se produisent avant que le navigateur ne reçoive une réponse HTTP et affichent des messages tels que ERR_CONNECTION_REFUSED ou ERR_CONNECTION_TIMED_OUT.

Le message du navigateur identifie le symptôme, mais pas toujours le composant qui doit être examiné. Commencez par localiser la limite qui échoue : du navigateur au réseau, du réseau au service en écoute, du proxy au backend, ou de l’application à sa dépendance.

Identifiez d’abord le type d’échec

Un code d’état HTTP a été renvoyé

Un code numérique signifie qu’un composant capable de gérer HTTP a répondu. Il peut s’agir du serveur web d’origine, d’un reverse proxy, d’un load balancer ou d’un CDN, et pas nécessairement de l’application elle-même.

• 500 Internal Server Error : Le serveur a rencontré une condition inattendue lors du traitement de la requête. Commencez par consulter les logs de l’application et du serveur web. Voir le [guide 500 Internal Server Error](/http-500-internal-server-error).
• 502 Bad Gateway : Un proxy a reçu de son backend une réponse non valide, vide ou inexploitable. Vérifiez le processus backend, l’hôte et le port upstream, ainsi que la connexion entre le proxy et l’origine. Voir le [guide 502 Bad Gateway](/http-502-bad-gateway).
• 503 Service Unavailable : Le service ne peut pas traiter la requête à ce moment-là. Les causes possibles incluent le mode maintenance, une capacité épuisée, un processus indisponible ou une dépendance défaillante. Voir le [guide 503 Service Unavailable](/http-503-service-unavailable).
• 504 Gateway Timeout : Une gateway a transmis la requête, mais n’a pas reçu de réponse avant l’expiration de son délai d’attente. Le backend peut être toujours actif, mais lent, surchargé ou en attente d’un autre service. Voir le [guide 504 Gateway Timeout](/http-504-gateway-timeout).

Un code d’état ne suffit pas, à lui seul, à prouver quelle couche a échoué. Examinez l’identité visuelle de la réponse, les headers, l’horodatage et les logs pour déterminer si la réponse vient de l’origine ou d’un intermédiaire.

Le navigateur signale un échec de connexion

Une erreur au niveau de la connexion signifie que le navigateur n’a pas reçu de réponse HTTP normale depuis l’endpoint attendu.

• ERR_CONNECTION_REFUSED : La destination a été atteinte, mais la connexion a été refusée. Vérifiez qu’un service écoute sur le port attendu et que les règles de sécurité locales ou réseau n’empêchent pas l’accès. Pour les environnements de développement, voir [ERR_CONNECTION_REFUSED sur localhost](/err-connection-refused-localhost).
• ERR_CONNECTION_TIMED_OUT : Le navigateur a attendu sans recevoir de réponse exploitable. Examinez le chemin réseau, le routage, le filtrage, le DNS, l’accessibilité du serveur et la disponibilité des ressources avant de rechercher une erreur HTTP générée par l’application. Voir le [guide ERR_CONNECTION_TIMED_OUT](/err-connection-timed-out).

Une séquence de diagnostic pratique

1. Reproduisez l’échec et consignez les informations

Rechargez la page une fois, puis essayez la même URL dans une fenêtre privée ou sur un autre appareil. Notez l’URL exacte, le texte de l’erreur, le code d’état, l’heure approximative et la page de réponse visible. Une page provenant d’un CDN ou d’un proxy et portant son identité visuelle suggère que la requête a atteint un intermédiaire ; un message générique du navigateur peut signifier qu’aucune réponse HTTP exploitable n’est arrivée.

Si un seul navigateur ou appareil échoue, examinez son proxy, son VPN, son cache DNS, ses extensions et son logiciel de sécurité local. Si la même URL échoue sur plusieurs appareils et réseaux, le serveur, le proxy, l’origine ou un chemin réseau partagé devient plus probable.

2. Définissez l’étendue du problème

Déterminez si le problème concerne une route, un hôte, une application entière ou l’ensemble du service.

• L’échec d’une seule route peut indiquer un problème dans le code de l’application, une dépendance propre à cette route ou une requête lente.
• Le renvoi d’un 500 sur toutes les routes suggère un problème plus général de configuration de l’application ou du serveur.
• Un 502 ou un 504 sur un proxy oriente vers le processus d’origine, la connexion upstream ou la configuration du proxy.
• Une connexion refusée sur un port peut signifier que le service attendu n’écoute pas, tandis que d’autres services restent disponibles.

Lorsque c’est possible, comparez un endpoint fonctionnel avec celui qui échoue. Les différences de routage, d’authentification, de dépendances et d’état du déploiement peuvent être plus instructives qu’une modification de paramètres client sans rapport.

3. Vérifiez le composant qui a généré la réponse

Pour un 500, faites correspondre les logs de l’application et du serveur web avec l’heure de l’échec. Pour les réponses 502, 503 et 504, examinez les logs du proxy ou de la gateway ainsi que ceux du backend. Recherchez un processus arrêté, un déploiement échoué, une défaillance de connexion à une dépendance, un épuisement des ressources ou une requête qui dépasse un délai d’attente pertinent.

Pour un ERR_CONNECTION_REFUSED local, vérifiez qu’Apache ou Nginx fonctionne et que le port configuré est disponible. XAMPP, Laragon et MAMP peuvent produire ce symptôme lorsque leur serveur web n’a pas démarré ou lorsqu’un autre programme empêche le service de s’attacher au port attendu.

4. Testez séparément l’origine et les dépendances

Si vous administrez le service, vérifiez que le backend accepte les connexions et répond à un endpoint simple, sans supposer qu’une connexion réussie au proxy prouve que l’application est saine. Vérifiez ensuite les services requis, comme la base de données ou les autres dépendances configurées.

Un backend actif mais constamment lent correspond davantage à un 504 qu’un backend arrêté ou renvoyant une réponse inexploitable, ce qui peut produire un 502. Un 503 peut survenir avant le traitement d’une requête par l’application si le service est volontairement indisponible ou si une dépendance requise ne peut pas être utilisée.

Évitez les rechargements répétés comme méthode de dépannage. Ils peuvent augmenter la charge pendant que le problème du processus, de la dépendance ou du délai d’attente est examiné.

Utilisez les détails de l’erreur pour localiser la couche concernée

Le corps de la réponse, les headers et l’horodatage peuvent révéler quel composant a traité l’échec :

• Un message générique du navigateur indique généralement qu’aucune réponse HTTP exploitable n’a été reçue.
• Une page provenant d’un proxy ou d’un CDN et portant son identité visuelle indique qu’un intermédiaire a généré ou présenté l’erreur.
• Une page d’erreur propre à l’application peut orienter plus directement vers l’application d’origine.

Pour les échecs intermittents, faites correspondre les horaires avec les déploiements, les hausses de trafic, les redémarrages de processus et la latence des dépendances. Pour les échecs constants, comparez une requête fonctionnelle avec la requête en échec et examinez les différences de configuration avant de modifier les paramètres du serveur.

Pour les sites qui utilisent Cloudflare, un 504 portant l’identité visuelle de Cloudflare signifie généralement que son edge n’a pas pu obtenir de réponse de l’origine dans le délai applicable. Le [guide 504 Gateway Timeout derrière Cloudflare](/504-gateway-timeout-cloudflare) explique comment distinguer un problème d’origine d’un délai d’attente produit par une autre gateway ou par l’origine elle-même.

Informations à fournir pour demander de l’aide

Un signalement utile comprend :

• Le texte exact de l’erreur et le code d’état
• Le chemin de l’URL et l’heure approximative de l’échec
• Le fait que le problème touche ou non d’autres utilisateurs, appareils ou réseaux
• La présence éventuelle d’un proxy, d’un CDN ou d’un load balancer
• Les entrées pertinentes des logs du serveur web, du proxy et de l’application, après suppression des mots de passe, tokens et autres secrets

L’objectif est d’identifier la limite qui échoue. Une fois cette limite connue, le guide d’erreur correspondant peut fournir des vérifications plus ciblées, sans traiter les causes liées au navigateur, au réseau, au proxy et au backend comme si elles étaient interchangeables.