Erreurs 502, 503 et 504 : ce que chacune signifie réellement

502, 503 et 504 signifient tous à peu près « le serveur n’a pas pu vous donner de vraie réponse pour le moment », c’est pourquoi ils sont si souvent confondus. Mais chaque code réduit le problème différemment, et la lecture correcte du numéro permet de gagner du temps en dépannant la mauvaise couche.

La distinction rapide

• 502 Bad Gateway — un serveur agissant comme passerelle ou proxy a reçu une réponse invalide du serveur derrière lui.
• 503 Service indisponible — le serveur est opérationnel mais refuse délibérément de traiter la demande pour le moment (surchargé ou en maintenance).
• 504 Gateway Timeout — un serveur agissant en tant que passerelle ou proxy n’a reçu aucune réponse du serveur derrière lui dans le délai imparti.

Le modèle : 502 et 504 impliquent tous deux deux serveurs : un proxy/équilibreur de charge/CDN devant et un serveur d’applications derrière. 503 n’est généralement qu’un serveur vous indiquant directement qu’il n’est pas prêt.

502 Passerelle incorrecte

Que se passe-t-il : Un proxy inverse, un équilibreur de charge ou un CDN (comme Cloudflare ou Nginx agissant comme une passerelle) a transmis votre demande au serveur d’applications réel et a reçu une réponse qu’il n’a pas pu comprendre ou qui était mal formée - pas un silence, une réponse réellement brisée.

Causes courantes :

• Le serveur d’application (Node, PHP-FPM, un processus backend) a planté ou redémarré en cours de requête.
• Un proxy inverse mal configuré pointant vers le mauvais port ou la mauvaise adresse.
• Le backend a renvoyé une réponse qui viole le formatage HTTP de base.
• Un CDN ou WAF devant le site est mal configuré et rejette une réponse backend légitime.

Que vérifier s’il s’agit de votre site : Consultez les journaux de votre serveur d’applications pour détecter les plantages ou les redémarrages au moment de l’erreur. Confirmez que votre configuration de proxy inverse (nginx proxy_pass, cible de l’équilibreur de charge, etc.) pointe vers un backend qui s’exécute réellement sur le port attendu.

503 Service indisponible

Que se passe-t-il : Le serveur a bien reçu votre demande, mais vous indique explicitement qu’il ne peut pas la gérer pour le moment. Contrairement à 502/504, cela est généralement intentionnel : un serveur indiquant sa propre condition plutôt qu’un proxy se plaignant de ce qu’il y a derrière.

Causes courantes :

• Maintenance planifiée — de nombreuses plates-formes renvoient volontairement 503 lors du déploiement ou de la mise à jour, souvent avec un en-tête Retry-After.
• Surcharge — trop de requêtes simultanées pour la capacité du serveur, courante lors des pics de trafic (une vente, une publication virale, une DDoS).
• Épuisement des ressources : le serveur n’a plus de mémoire, de connexions à la base de données ou de processus de travail pour gérer les nouvelles requêtes.
• Limitation de débit — certaines configurations renvoient 503 au lieu de 429 lorsqu’un client (ou un service en amont) envoie des requêtes trop rapidement.

Que vérifier s’il s’agit de votre site : Si ce problème apparaît lors d’un déploiement, il peut se résoudre en quelques secondes, voire quelques minutes. Si le problème persiste, vérifiez l’utilisation des ressources du serveur (CPU, mémoire, limites du pool de connexions) et les journaux de votre gestionnaire de processus pour détecter les travailleurs qui ne démarrent pas ou sont tués.

504 Expiration du délai de la passerelle

Que se passe-t-il : Même configuration à deux serveurs que 502, mais au lieu d’obtenir une réponse interrompue du backend, le proxy n’a rien reçu du tout dans le temps d’attente qui lui est imparti. C’est le frère “passerelle” d’un simple délai d’attente de connexion.

Causes courantes :

• Le backend met trop de temps à traiter la requête : une requête de base de données lente, un script non optimisé ou une dépendance (API, service tiers) elle-même lente ou en panne.
• Le backend est surchargé et trop occupé pour répondre à temps, même s’il n’est pas tombé en panne.
• Un paramètre de délai d’expiration du proxy trop agressif pour une opération légitimement lente (mais fonctionnelle), comme le téléchargement d’un fichier volumineux ou la génération d’un rapport volumineux.

Que vérifier s’il s’agit de votre site : Profilez directement le point de terminaison lent, en contournant le proxy, pour voir si le backend lui-même est lent ou si le problème concerne uniquement la couche proxy. Vérifiez si une dépendance spécifique (base de données, API externe) est dégradée, car c’est la cause première la plus courante d’un ralentissement d’un backend plutôt que d’un crash pur et simple.

C’est vous, ou c’est eux ?

Ces trois erreurs sont par définition côté serveur : elles ne sont pas causées par votre navigateur, votre DNS ou votre réseau local, ce qui les distingue clairement de problèmes tels que ERR_CONNECTION_TIMED_OUT ou DNS_PROBE_FINISHED_NXDOMAIN. Si vous voyez un 502, 503 ou 504, le correctif (s’il y en a un que vous pouvez créer) n’est presque jamais de votre côté - l’actualisation fonctionne parfois pour un 503 transitoire, mais un correctif persistant signifie simplement attendre que le site le résolve.

Pour confirmer que ce n’est pas seulement vous – certains CDN ou nœuds périphériques régionaux génèrent parfois une mauvaise erreur de passerelle tandis que d’autres vont bien – exécutez le site via une vérification d’état indépendante pour voir le code d’état HTTP en direct d’un serveur extérieur à votre propre réseau, ainsi que le temps de réponse et l’état SSL dans la même vue.