Un proxy a reçu une réponse invalide du serveur situé derrière lui.
Quand l’utiliser
L’application derrière nginx ou un répartiteur de charge a planté ou renvoyé n’importe quoi.
Causes courantes et solutions
Un proxy comme nginx, un répartiteur de charge ou Cloudflare n’a pas pu obtenir de réponse valide de l’application située derrière lui. Causes courantes : l’application a planté ou ne tourne pas, elle écoute sur un autre port ou une autre adresse que ceux attendus par le proxy (127.0.0.1 au lieu de 0.0.0.0 dans Docker), un chemin ou des permissions incorrects pour le socket PHP-FPM, ou des en-têtes de réponse trop volumineux. Le log d’erreurs de nginx indique « connection refused » ou « upstream prematurely closed connection ».
Les 502 intermittents derrière AWS ALB sont souvent dus à des conditions de concurrence sur le keep-alive : l’application ferme les connexions inactives avant le répartiteur, alors réglez le délai keep-alive de l’application au-dessus du délai d’inactivité de 60 secondes de l’ALB, par exemple server.keepAliveTimeout = 65000 dans Node.js. La page d’erreur de Cloudflare indique si c’est le navigateur, Cloudflare ou votre hébergement qui a échoué. Vérifiez aussi les boucles de plantage dans systemd ou Kubernetes, et les processus tués par l’OOM killer dans dmesg.
Erreur serveur (5xx)
Les codes 5xx sont des erreurs serveur : la requête est peut-être correcte, mais le serveur ou un composant derrière lui a échoué. Ils méritent une alerte.
À quoi ça ressemble
HTTP/1.1 502 Bad GatewayComment l’envoyer
| Node.js / Express | res.status(502).end() |
|---|---|
| Python / Flask | return '', 502 |
| nginx | return 502; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/