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 donné une mauvaise réponse (ou a raccroché), 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 n'ont nulle part où aller.

• 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.

• Un pare-feu ou un changement réseau entre le proxy et l'origine. Par exemple, un CDN ne peut plus joindre une origine dont l'adresse IP ou les règles de pare-feu ont changé.

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. L'outil En-têtes HTTP de DNS Robot demande la page depuis nos serveurs et affiche le code de statut exact. Si nous obtenons aussi une 502, le problème vient du site, pas de vous. Un Test Ping indique si la machine serveur répond tout court.

• Forcez le rechargement et videz le cache. Ctrl + Shift + R (Mac : Cmd + Shift + R) ignore la copie en cache, au cas où une page d'erreur obsolète 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 note presque toujours précisément ce qui s'est mal passé. Effectuez ces quatre vérifications dans l'ordre.

1. Lire le journal d'erreurs du proxy

Reproduisez la 502, puis lisez les dernières lignes du journal d'erreurs sur le serveur proxy :

# 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

Ces messages nginx couvrent l'immense majorité des 502, et chacun oriente vers la solution :

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 ?
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 ?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# 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). Après chaque modification, lancez sudo nginx -t puis sudo systemctl reload nginx.

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 :

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;
}

Après nginx -t et un rechargement, la page renvoyait 200. 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 gros cookies 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), 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 // à garder légèrement au-dessus de keepAliveTimeout

Erreur 502 Bad Gateway sur Cloudflare

Derrière Cloudflare, regardez d'abord qui a généré la page d'erreur :

• Page aux couleurs de Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗) : Cloudflare fonctionne mais n'a pas obtenu de réponse valide de votre serveur d'origine. Vérifiez que l'origine est en ligne, écoute sur 443/80 et ne bloque pas les plages d'IP de Cloudflare dans son pare-feu. Testez l'origine directement avec le Vérificateur de ports.

• Page 502 simple, sans habillage : si elle ne mentionne pas cloudflare (par exemple si elle cite nginx ou Apache), c'est votre propre serveur d'origine qui a généré la 502. Suivez les étapes côté serveur ci-dessus. Une page vide avec seulement « cloudflare » en bas vient de Cloudflare lui-même, par exemple lors d'un bref réacheminement du trafic ou quand l'origine envoie un contenu gzip corrompu.

• L'IP d'origine a changé ? Si vous avez changé d'hébergeur, mettez à jour l'enregistrement A dans le DNS de Cloudflare. Une Recherche DNS montre ce que le monde voit actuellement.

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.