Erreur 502 Bad Gateway : causes et correctifs rapides (2026)

Votre site affiche une erreur 502 bad gateway et, soudain, c’est le grand silence radio : pages qui ne chargent plus, panier e-commerce qui se vide, formulaires qui ne partent pas… et cette petite sensation désagréable que votre site est en train de perdre de l’argent pendant que vous lisez ces lignes. Bonne nouvelle : une 502, c’est souvent réparable rapidement, à condition d’éviter la méthode “je clique partout et j’espère”.

Ici, on fait les choses proprement : je vous donne d’abord la méthode express pour remettre le site debout, puis je vous explique les causes les plus fréquentes (WordPress, serveur, proxy/CDN, PHP-FPM, etc.), et enfin comment éviter que ça recommence au prochain pic de trafic (parce que la 502 adore les “replays”).

La réponse rapide (à faire maintenant) : la méthode express en 10–20 minutes

Une erreur 502 signifie généralement qu’un intermédiaire (proxy, reverse proxy, CDN, passerelle) n’obtient pas une réponse correcte de votre serveur “d’origine”. Donc, votre priorité, c’est de déterminer si la panne vient de l’infrastructure (serveur, PHP, réseau) ou de l’application (WordPress, code, requêtes).

Commencez par vérifier si la 502 est globale. Ouvrez le site depuis un autre appareil, un autre réseau (4G/5G), ou demandez à quelqu’un de tester. Si tout le monde a la 502, c’est très probablement côté serveur / proxy. Si vous seul voyez la 502, on peut suspecter un cache local ou une résolution DNS capricieuse (moins fréquent, mais ça arrive).

Ensuite, si vous utilisez un CDN / proxy (par exemple Cloudflare), faites un test en le contournant temporairement (mode pause/bypass selon votre configuration). L’objectif est simple : savoir si le problème est sur le chemin “CDN → serveur” ou sur le serveur lui-même. Si le site revient sans CDN, vous avez déjà réduit l’enquête à une zone bien plus petite (et vous venez de gagner du temps, ce qui est toujours une bonne nouvelle quand votre site joue à cache-cache).

Troisième étape : regardez les ressources serveur si vous avez accès (même minimal). Une 502 apparaît très souvent quand le serveur est à bout : CPU/RAM saturés, disque plein, ou trop de processus en file d’attente. Dans ce cas, redémarrer un service peut faire revenir le site… mais si vous ne corrigez pas la cause, la 502 reviendra comme un boomerang.

Enfin, la règle d’or : le log fait foi. Une 502 sans logs, c’est comme un diagnostic auto sans ouvrir le capot : on peut deviner, mais on risque de changer la mauvaise pièce.

Erreur 502 Bad Gateway : ça veut dire quoi exactement ?

Une erreur 502 bad gateway survient lorsqu’un serveur qui joue le rôle de passerelle ou de proxy reçoit une réponse invalide du serveur “en amont” (upstream). En clair : quelqu’un au milieu tente de parler à votre serveur, mais la réponse reçue est incohérente, incomplète, ou la connexion tombe avant la fin. La définition “propre” du code 502 est bien résumée côté Mozilla (MDN) : https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/502

Ce point est important : une 502 n’est pas “un bug navigateur”. C’est un signal que votre chaîne technique (proxy/CDN → serveur web → PHP/runtime → application → base de données / services externes) a un maillon qui a craqué.

Les causes les plus fréquentes (et comment les reconnaître vite)

Serveur surchargé ou instable : la cause n°1 quand ça arrive “sans prévenir”

Quand la 502 apparaît par vagues, surtout aux heures de pointe, le suspect habituel, c’est la charge. Trop de visiteurs, trop de bots, une tâche cron qui se déclenche au mauvais moment, une sauvegarde qui mange les ressources… Résultat : le serveur met trop de temps à répondre, ou coupe la connexion, et le proxy remonte une 502.

Ce qui met la puce à l’oreille : le site revient tout seul, puis retombe. Le temps de réponse devient énorme avant l’erreur. Et souvent, d’autres signes apparaissent (admin lente, requêtes qui moulinent, pages qui “chargent mais jamais”).

La correction durable ici n’est pas “redémarrer et espérer”. C’est de stabiliser : identifier ce qui consomme, limiter les appels trop lourds, ajuster le cache, et parfois revoir l’hébergement si la marge est trop faible. Une 502 à répétition, c’est souvent un serveur dimensionné “au cordeau”, donc fragile.

PHP-FPM / runtime saturé : WordPress et sites dynamiques, le grand classique

Sur beaucoup de stacks modernes (Nginx + PHP-FPM notamment), la 502 surgit quand PHP n’arrive plus à traiter les requêtes : pool saturé, processus bloqués, timeouts, ou crash. Le proxy tente de contacter l’upstream PHP… et récupère une réponse invalide ou aucune réponse.

Si vous voyez dans les logs des messages du style “upstream timed out” ou “connect() failed” ou des erreurs liées à fastcgi, c’est un indice fort. Dans ce cas, un redémarrage de PHP-FPM peut remettre le site en ligne, mais la vraie question est : pourquoi PHP sature ? Trop de requêtes simultanées ? Un plugin qui boucle ? Une page qui fait une requête SQL énorme ? Une API externe qui bloque tout ?

Le bon réflexe, c’est de corriger la cause (optimisation, limites, cache, réglages) plutôt que de multiplier les redémarrages comme si on tapotait une vieille télé.

CDN / reverse proxy / WAF : quand l’intermédiaire devient le messager (et parfois le problème)

Avec un CDN ou un WAF, la 502 peut remonter parce que le CDN n’arrive pas à joindre l’origine (firewall trop strict, ports, TLS), ou parce que la configuration est incohérente (certificat invalide côté origin, mode strict, etc.). Ce n’est pas que “le CDN invente une 502”, c’est qu’il constate une conversation qui tourne mal.

Dans ces scénarios, le test le plus rentable reste le contournement temporaire du CDN. Si ça marche sans CDN, vous savez où chercher : règles WAF, firewall, TLS, paramètres “origin”, limitations réseau. Et surtout, vous évitez de casser l’application alors que le souci est avant même d’arriver à WordPress/Laravel.

DNS / IP / propagation : pas fréquent, mais redoutable quand ça arrive

Une IP qui change, un enregistrement A/AAAA incohérent, une propagation en cours… et vous pouvez avoir des réponses différentes selon les réseaux. Typiquement : certains voient le site, d’autres voient la 502. Ce genre de cas donne l’impression que “le site est possédé”, alors qu’il est juste mal pointé.

Ici, on vérifie les enregistrements DNS, l’IP de l’origine, et on s’assure que le domaine pointe bien vers le bon serveur, partout.

Application (WordPress, code, requêtes) : une page peut suffire à déclencher la 502

Oui, une 502 peut être provoquée par l’application : un plugin qui part en boucle, une requête SQL qui explose, un appel externe qui timeout, un import trop lourd, une mise à jour incompatible. Souvent, l’indice le plus clair est : “la 502 n’arrive que sur certaines pages” ou “ça a commencé juste après une mise à jour”.

Le bon plan, c’est d’isoler l’URL qui déclenche, puis de remonter les changements récents. Sur WordPress, désactiver temporairement cache/plugins/thème permet parfois de retrouver une base saine, le temps d’identifier le coupable.

Diagnostic propre (sans “tout désactiver” à l’aveugle) : la méthode qui évite de perdre une journée

Pour gagner du temps, je procède toujours dans cet ordre :

D’abord, je cherche si la 502 est générale ou localisée. Si tout le site est KO, c’est rarement “un plugin sur une page”. Si c’est localisé, l’application devient un suspect sérieux.

Ensuite, je collecte des preuves : l’heure exacte d’un test, puis je lis les logs correspondants (serveur web, PHP-FPM, application). Cette étape, c’est la différence entre un dépannage “au feeling” et une correction qui tient la route. Le message de log vous dit si c’est un timeout, un refus de connexion, un crash, un upstream inaccessible, ou une limite atteinte.

Puis je teste l’origine sans intermédiaire quand c’est possible. Ça permet de trancher : est-ce le proxy/CDN qui bloque, ou l’origine qui répond mal ?

Enfin, je corrige, puis je vérifie la stabilité. Un site qui revient 3 minutes puis retombe n’est pas “réparé”. Il est juste “en sursis”.

En effet, une erreur 5XX peut avoir un impact sur le référencement de votre site, mais également sur la confiance de vos clients. 

Les correctifs “safe” selon votre stack (sans transformer votre prod en laboratoire)

Sur WordPress, l’approche la plus sûre consiste à réduire la complexité temporairement : couper le cache, isoler plugins/thème, puis réintroduire progressivement. Le piège, c’est de tout réactiver d’un coup sans avoir identifié la cause : vous aurez l’impression que “ça marche” jusqu’à la prochaine montée en charge.

Sur Nginx/Apache + PHP-FPM, le correctif immédiat est souvent le redémarrage des services, mais la correction durable consiste à adapter les limites (workers/pool), ajuster les timeouts, et optimiser ce qui déclenche des traitements trop longs.

Avec un CDN/WAF, le bon réflexe est de vérifier la chaîne TLS, les règles de sécurité, et les accès réseau vers l’origine. Un firewall trop agressif peut créer des 502 “propres” côté CDN, alors que le serveur, lui, n’a jamais vu la requête.