Qu'est-ce qu'une erreur 502 Bad Gateway et qui en est responsable ?

Une erreur 502 Bad Gateway est un serveur vous disant qu’un autre serveur, celui sur lequel il s’appuyait, a répondu avec quelque chose qu’il ne pouvait pas utiliser. Ce n’est pas « le site est en panne » au sens propre, et certainement pas « vous avez fait quelque chose de mal » : une machine au milieu a demandé votre page à la machine derrière elle, et ce qui est revenu était du charabia, une porte claquée, ou quelque chose qui n’avait aucun sens.

Le mot gateway est la clé. Le serveur que vous avez atteint n’est pas celui qui fabrique votre page ; c’est une façade, un reverse proxy ou un équilibreur de charge, placé devant l’application qui fait le vrai travail. Quand cette façade reçoit une réponse cassée de derrière, la seule chose honnête qu’elle peut vous signaler, c’est que la réponse était mauvaise. Ce qui est exactement ce que 502 signifie.

L’image à deux serveurs

Presque tous les sites un tant soit peu importants sont au moins deux machines. Il y a celui auquel votre navigateur se connecte d’abord - nginx, une arête CDN, un équilibreur de charge cloud - et derrière lui le serveur d’application qui exécute le code et construit la page.

La façade prend votre demande et la renvoie. La plupart du temps l’application répond proprement et la façade vous donne cette réponse, discrètement. Une 502 est ce que vous voyez quand cette deuxième étape échoue : la façade a demandé, et la réponse qu’elle a reçue n’était pas une réponse HTTP valide qu’elle pourrait relayer.

Une 502 n’est donc jamais vraiment à propos du serveur que vous avez atteint. C’est un message à propos de celui que vous n’avez pas.

502 contre 504, qui sont constamment confondus

Ils viennent du même endroit - le serveur façade, signalant celui derrière lui - et les distinguer réduit beaucoup la cause.

502 Bad Gateway

L'amont a répondu, et la réponse était inutilisable - une connexion refusée, un processus écrasé, du charabia sur la ligne. Généralement rapide

504 Gateway Timeout

L'amont n'a pas répondu du tout dans le temps imparti. Généralement lent, et la pause avant l'erreur est elle-même l'indice

En gros : 502 c’est « il a dit quelque chose de travers », 504 c’est « il n’a rien dit encore ». Une 502 arrive vite et pointe vers quelque chose de cassé, écrasé ou refusant les connexions ; une 504 arrive lentement et pointe vers quelque chose de bloqué ou surchargé. Si l’erreur est revenue presque instantanément, c’est bien plus probablement une 502 qu’une 504, peu importe ce que dit la page.

Un détail que la plupart des articles manquent : les fournisseurs réétiquettent cela. Cloudflare retourne une 502 à lui quand votre origin envoie une réponse invalide, et sa propre 520 pour une réponse si malformée qu’elle n’entre dans aucun code standard du tout. Derrière un CDN, le numéro que vous voyez peut être la lecture du CDN du même événement plutôt que celle de votre serveur.

Si vous êtes le visiteur

Rechargez une fois, car une 502 est souvent un worker écrasé solitaire ou un processus attrapé à mi-redémarrage, et la demande suivante atterrit sur un sain. Si ça s’efface, il n’y a rien à chasser.

Si ça persiste, la faute est du côté du site et il n’y a vraiment pas grand-chose que vous puissiez faire au-delà de les prévenir, car aucun réglage dans votre navigateur n’atteint un processus cassé sur leur serveur. Avant d’assumer que c’est vous, confirmez que ce n’est pas local : le contrôle le plus rapide est de pointer le vérificateur de statut HTTP sur l’adresse, qui demande la page à partir de notre serveur plutôt que du vôtre et signale le code qui est revenu. S’il voit le 502 aussi, le problème n’est pas votre connexion.

Si c’est votre site

Une 502 dit que la façade ne pouvait pas utiliser ce que l’application a envoyé, donc la question est ce que l’application a fait. Il n’y a que quelques réponses communes.

Le processus d’application est arrêté ou plantant. La cause la plus fréquente de loin. La façade essaie de se connecter et obtient « connexion refusée » parce que rien n’écoute, ou le processus accepte la demande et meurt à mi-réponse. Vérifiez que l’app fonctionne réellement, et lisez ses propres journaux pour un plantage ou une coupure mémoire au moment de l’erreur - les journaux de la façade ne vont dire que l’upstream a échoué, jamais pourquoi.

Une inadéquation de timeout entre les couches. Si l’application prend plus de temps pour répondre que ce que la façade est disposée à attendre, certains proxies signalent cela comme une 502 plutôt qu’une 504, fermant la connexion et appelant la réponse à moitié terminée mauvaise. Quand une 502 se corrèle avec des demandes lentes plutôt que des plantages, regardez ici.

Un déploiement cassé. Une nouvelle construction qui échoue au démarrage, écoute sur le mauvais port, ou répond avec des en-têtes que la façade rejette, va transformer chaque demande en 502 le moment où elle se met en direct. Si les erreurs ont commencé à un déploiement, c’est le premier endroit à regarder, et une restauration est plus rapide qu’un diagnostic.

Quelque chose entre les couches. Un proxy_pass mal configuré, un nom d’hôte upstream qui ne se résout plus, un groupe de sécurité qui a tranquillement cessé de permettre à la façade d’atteindre l’app - la connexion ne se complète jamais et la façade signale une bad gateway. Ceux-ci sont les plus lents à trouver parce que rien n’a planté ; un lien dans la chaîne a simplement cessé de transporter le trafic.

La raison pour laquelle ceux-ci sont si difficiles à poursuivre plus tard

Une 502 est souvent partie au moment où quelqu’un regarde. Le worker écrasé redémarre, le déploiement est restauré, la rafale de trafic passe, et le journal de la façade dit seulement qu’une demande upstream a échoué à 09:14 - pas ce qu’a dit l’upstream, pas quel processus, pas pourquoi.

Ce qui le règle, c’est la preuve capturée alors qu’elle se produit : la demande qui a échoué, le statut exact, le timing, et ce que la personne faisait quand cela est apparu. Une 502 qu’un utilisateur signale une heure plus tard, de mémoire, est une supposition. Une 502 avec la demande défaillante et son timestamp attaché est une ligne que vous pouvez faire correspondre contre le journal d’application et l’historique de déploiement et fermer.

Le journal réseau contient la demande défaillante avec son 502 et le moment où elle s’est produite, sauvegardée telle qu’elle s’est produite plutôt que mémorisée après - qui est la différence entre un rapport sur lequel quelqu’un peut agir et un qu’il faut d’abord reproduire.

En un paragraphe

Une erreur 502 Bad Gateway est un serveur première ligne disant que le serveur derrière lui a donné une réponse qu’il ne pouvait pas utiliser - plantée, refusée, ou malformée - et il arrive vite, ce qui est ce qui le distingue du lent 504. Si vous visitez, rechargez une fois puis supposez que c’est leur côté. Si c’est le vôtre, vérifiez que l’application fonctionne et ce qu’elle a consigné, soupçonnez le dernier déploiement si le timing convient, et capturez la demande défaillante pendant que vous l’avez, car une 502 est presque impossible à poursuivre une fois qu’elle a passé.