Erreur 502 Bad Gateway : signification et solutions

Qu'est-ce que l'erreur 502 Bad Gateway ?

502 Bad Gateway est un code de statut HTTP qui signifie que le serveur qui vous répond agit comme passerelle ou proxy, et qu'il a reçu une réponse invalide du serveur placé derrière lui. Le standard HTTP (RFC 9110, section 15.6.3) la définit exactement ainsi : le serveur, « agissant en tant que passerelle ou proxy, a reçu une réponse invalide d'un serveur entrant qu'il a sollicité en tentant de traiter la requête ».

La plupart des sites web modernes comportent au moins deux couches. Un serveur frontal, comme nginx, Apache, Cloudflare ou un load balancer cloud, accepte votre connexion, puis transmet la requête à une application en amont (upstream) comme PHP-FPM, une application Node.js, Gunicorn pour Python ou un conteneur. Quand cet upstream est arrêté, plante ou renvoie quelque chose que le proxy ne peut pas exploiter, le proxy n'a rien à vous donner et renvoie donc une 502.

Le point essentiel : la passerelle elle-même fonctionne. Elle a reçu votre requête et y a répondu. La panne se situe un cran plus loin.

Les différents visages de l'erreur 502

Le code de statut est partout le même, mais la page affichée dépend du proxy qui l'a produite :

Quelle que soit la version affichée, le nom du proxy en bas de page est un indice utile : il indique au propriétaire du site quelle couche examiner.

502, 500, 503 ou 504 : quelle différence ?

Les codes 5xx signifient tous « problème de serveur », mais chacun désigne une couche différente :

Règle simple : 502 = l'upstream a refusé la connexion, a raccroché ou a renvoyé une mauvaise réponse, 504 = l'upstream n'a pas répondu à temps. Nos guides consacrés aux erreurs voisines les détaillent : 500 Internal Server Error, 503 Service Unavailable et 504 Gateway Timeout.

Quelles sont les causes d'une erreur 502 Bad Gateway ?

• L'application en amont ne tourne pas. PHP-FPM, Node, Gunicorn ou le conteneur a planté, n'a pas démarré après un déploiement, ou est en train de redémarrer.
• Le proxy pointe au mauvais endroit. proxy_pass ou fastcgi_pass utilise le mauvais port, un ancien chemin de socket PHP après une mise à jour, ou localhost à l'intérieur d'un conteneur Docker.
• L'application plante sur certaines requêtes. Une page déclenche un arrêt pour manque de mémoire ou une exception non gérée, et la connexion se ferme avant toute réponse.
• Tous les workers sont occupés. PHP-FPM a atteint pm.max_children : les nouvelles requêtes attendent dans la file du socket. La plupart finissent en 504 par expiration ; quand la file est pleine, nginx consigne (11: Resource temporarily unavailable) et renvoie une 502.
• Les en-têtes de réponse sont trop gros. De gros cookies ou de longs en-têtes de sécurité dépassent le proxy_buffer_size de nginx.
• Incohérence de keep-alive derrière un load balancer. L'application ferme les connexions inactives plus tôt que ne le prévoit le load balancer, qui envoie alors une requête dans une connexion en cours de fermeture.
• Le proxy ne peut plus joindre l'upstream après un changement réseau. Un pare-feu qui rejette le proxy, ou un upstream passé à une nouvelle IP, donne une 502 (Connection refused, No route to host). Un pare-feu qui abandonne les paquets en silence donne plutôt une 504, et derrière Cloudflare ces cas s'affichent en 521 ou 522.

Comment corriger une erreur 502 en tant que visiteur

Vous ne pouvez pas réparer le serveur de quelqu'un d'autre, mais ces étapes confirment que le problème vient bien de son côté et éliminent les rares causes locales :

• Attendez 30 à 60 secondes et rechargez (Ctrl + R, ou Cmd + R sur Mac). Beaucoup de 502 ne durent que le temps d'un déploiement ou d'un redémarrage.
• Vérifiez si le site est hors ligne pour tout le monde. Le Vérificateur de site en panne de DNS Robot ouvre la page depuis 11 endroits, et le Vérificateur d'en-têtes HTTP affiche le code de statut exact que reçoit notre serveur. S'ils obtiennent aussi une 502, le problème vient du site, pas de vous.
• Forcez le rechargement avec Ctrl + Shift + R (Mac : Cmd + Shift + R), au cas rare où une page d'erreur en cache vous serait affichée.
• Videz votre cache DNS si le site a récemment changé d'hébergeur, pour atteindre le nouveau serveur. Voici comment vider le cache DNS sur chaque système.
• Désactivez VPN et proxys. Votre propre proxy peut être la « passerelle » défaillante, surtout sur les réseaux d'entreprise.
• Essayez un autre navigateur ou votre téléphone en données mobiles. Si cela fonctionne, supprimez les cookies de ce site.

Comment corriger une erreur 502 Bad Gateway sur votre serveur

Côté serveur, la 502 fait partie des erreurs les plus faciles à corriger, car le proxy consigne généralement ce qui s'est mal passé (la course de keep-alive d'un load balancer et les 502 propres à Cloudflare font exception). Effectuez ces trois vérifications dans l'ordre ; la quatrième partie est un cas réel.

1. Lire le journal d'erreurs du proxy

Reproduisez la 502, puis lisez les 50 dernières lignes du journal d'erreurs du proxy (commandes sous le tableau). Chacun de ces messages nginx oriente vers sa propre solution :

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Vérifier que l'application en amont tourne

# PHP-FPM (adaptez la version)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js sous PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # cherchez les conteneurs qui redémarrent en boucle
docker logs --tail 50 <container>

# A-t-il été tué pour avoir consommé trop de mémoire ?
sudo dmesg -T | grep -i "killed process"

Si le service est arrêté, démarrez-le et cherchez pourquoi il s'est arrêté : un déploiement raté, une erreur de syntaxe dans la nouvelle version, ou l'OOM killer (manque de mémoire). Dans le journal de PHP-FPM, server reached pm.max_children setting signifie que tous les workers étaient occupés. N'augmentez pm.max_children que si le serveur a la RAM nécessaire ; sinon, trouvez les requêtes lentes qui monopolisent les workers.

3. Vérifier que proxy_pass pointe vers le bon port ou socket

Comparez ce vers quoi nginx est configuré pour transmettre avec ce qui écoute réellement :

# Vers quoi nginx transmet-il ?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# Qu'est-ce qui écoute réellement ?
sudo ss -tlnp            # ports TCP et leurs processus
ls -l /run/php/          # fichiers socket de PHP-FPM

Deux incohérences classiques : après une mise à jour de PHP, le socket devient php8.3-fpm.sock alors que nginx pointe toujours vers php8.1-fpm.sock ; et dans Docker, proxy_pass http://localhost:3000 désigne le conteneur nginx lui-même et non l'application, utilisez donc le nom du service Compose (http://app:3000).

4. Un cas réel : comment dnsrobot.net a renvoyé une 502

Cela nous est arrivé le 30 septembre 2026. Après la publication d'une série de nouveaux articles de blog, un seul d'entre eux renvoyait 502 Bad Gateway via nginx 1.24, alors que toutes les autres pages fonctionnaient. L'application Next.js derrière nginx renvoyait cette même page avec un 200 OK quand nous la demandions directement sur le port 3000. L'application allait donc bien, et c'était la passerelle qui échouait.

Le journal d'erreurs de nginx donnait la réponse en une ligne : upstream sent too big header while reading response header from upstream. Les en-têtes de réponse de cette page atteignaient 4 087 octets, principalement un long en-tête Content-Security-Policy plus des en-têtes Link de préchargement. nginx lit la première partie de la réponse, en-têtes compris, dans un tampon défini par proxy_buffer_size, qui vaut par défaut une page mémoire : 4 Ko sur notre serveur. Il ne restait que 9 octets de marge, et le bloc d'en-têtes complet, ligne de statut comprise, a débordé.

La correction tenait en trois lignes dans le bloc location qui transmet à l'application ; après nginx -t et un rechargement, la page renvoyait 200 :

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # place pour les gros en-têtes (4k par défaut auparavant)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

La leçon : si seules certaines pages renvoient une 502 alors que le reste du site fonctionne, cherchez une limite de taille, comme de gros en-têtes ou de grosses valeurs Set-Cookie sur ces pages, avant de soupçonner l'application.

Node.js derrière un load balancer : des 502 aléatoires

Si vous faites tourner Node.js derrière un AWS Application Load Balancer ou un équilibreur similaire et que vous voyez des 502 occasionnelles sans aucune erreur dans les journaux de l'application, vérifiez les délais de keep-alive. Le serveur HTTP de Node ferme par défaut les connexions keep-alive inactives au bout de 5 secondes (server.keepAliveTimeout, jusqu'à Node.js 26 inclus ; Node 24.6 et 22.19 y ont ajouté un keepAliveTimeoutBuffer de 1 seconde, et la prochaine version majeure porte la valeur par défaut à 65 secondes), alors qu'un ALB AWS garde les connexions inactives ouvertes 60 secondes. Il arrive que l'équilibreur réutilise une connexion au moment précis où Node la ferme, et cette requête revient en 502.

La solution consiste à garder le délai de l'application plus long que celui de l'équilibreur :

const server = app.listen(3000)
// Doit être plus long que le délai d'inactivité du load balancer (ALB par défaut : 60 s)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // nécessaire seulement avant Node 18 ; sans effet gênant ensuite

Erreur 502 Bad Gateway sur Cloudflare

Derrière Cloudflare, regardez d'abord qui a généré la page d'erreur (guide 502/504 de Cloudflare) :

• Page aux couleurs de Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗) : votre serveur d'origine lui-même a renvoyé une 502 ou une 504 à Cloudflare. Corrigez-le côté origine avec les étapes serveur ci-dessus. Si Cloudflare ne peut pas du tout se connecter à l'origine, vous obtenez une 521 ou une 522, pas une 502.
• Une page simple indiquant « 502 Bad Gateway » avec « cloudflare » en dessous : elle vient de Cloudflare lui-même. La documentation de Cloudflare cite deux causes : votre origine envoie du contenu gzip corrompu, ou du contenu gzip sans Content-Length mis à jour (désactivez la compression côté origine pour tester), et un pic soudain de trafic sur un datacenter Cloudflare, qui passe tout seul.
• Une page citant nginx ou Apache : la requête a généralement atteint votre serveur sans passer par Cloudflare, parce que l'enregistrement DNS n'est pas proxifié (nuage gris) ou que vous consultez directement l'origine (sauf si une Cache Rule active « Origin error page pass-through »).
• Changement d'hébergeur ? Mettez à jour l'enregistrement A de l'origine dans le DNS de Cloudflare (une mauvaise IP d'origine s'affiche généralement en 521, 522 ou 523). Une Recherche DNS ne montre l'origine que pour les enregistrements en nuage gris (DNS only) ; les enregistrements proxifiés répondent avec les IP de Cloudflare.

Une erreur 502 nuit-elle au SEO ?

Une courte interruption, non. La documentation de Google indique que les erreurs serveur 5xx poussent ses robots à ralentir temporairement l'exploration. Les pages déjà indexées restent d'abord dans l'index, mais si les erreurs persistent, Google finit par retirer ces URL.

Une 502 de quelques minutes pendant un déploiement est donc sans conséquence. Une 502 sur des pages importantes qui dure des jours, ou qui apparaît par intermittence pendant des semaines, peut réduire l'exploration et coûter des positions. Surveillez vos URL clés, et consultez le rapport Statistiques sur l'exploration de la Search Console après toute panne.