Erreur 502 Bad Gateway : trouver la cause et réparer.Page de nginx, de l'hébergeur ou de Cloudflare : la marche à suivre.

1. Attendez une minute, puis rechargez une fois : notez l'heure exacte et les pages touchées.
2. Testez ailleurs : un téléphone en 4G sans VPN, puis la page wp-login.php, jamais mise en cache.
3. Regardez l'état de l'hébergeur ; derrière Cloudflare, une page à ses couleurs désigne votre serveur.
4. Lisez le journal des erreurs à l'heure notée : PHP arrêté, processus épuisés ou script coupé.
5. Désactivez l'extension en cause par FTP, et revenez à la version de PHP précédente si elle vient de changer.
6. Soulagez PHP : bloquez les robots insistants, ajoutez un cache, déplacez les tâches lourdes la nuit.
7. Toujours en erreur ? Faites redémarrer PHP par l'hébergeur, avec l'heure, l'adresse et le Ray ID.

Dans ce guide

• Les messages de l'erreur 502
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• 502, 504, 503, 500 : ce qui les distingue
• Ce que nous ferions à votre place
• Questions fréquentes

Le mot anglais « gateway » veut dire passerelle. Sur la plupart des hébergements, un serveur nginx ou Apache reçoit la visite et la confie à PHP, qui calcule la page avec WordPress, PrestaShop ou Joomla ; si le site passe par Cloudflare, c'est un relais de plus, placé devant. La 502 dit que le relais fonctionne, mais qu'il n'a pas obtenu de réponse utilisable de ce qui se trouve derrière lui. Selon le relais qui l'affiche :

• « 502 Bad Gateway » sur une page blanche, avec le mot nginx en dessous : la page de nginx, le serveur placé devant PHP ou devant Apache.
• « Bad Gateway », suivi de « The proxy server received an invalid response from an upstream server » : la page d'Apache, quand il relaie la visite vers un autre serveur. Quand c'est PHP qui ne répond plus derrière Apache, celui-ci affiche plutôt une erreur 503 : voyez notre guide de l'erreur 503.
• Une page à l'image de l'hébergeur, avec son logo : la même erreur, présentée par lui.
• Une page aux couleurs de Cloudflare, titrée « Bad gateway », avec « Error code 502 », trois pictogrammes (l'hôte marqué « Error ») et un Ray ID tout en bas : d'après Cloudflare, c'est votre serveur qui lui a renvoyé l'erreur. Derrière Cloudflare, c'est le cas le plus fréquent.
• Une page presque blanche, sans le logo ni les pictogrammes de Cloudflare, sur un site qui passe par lui : l'erreur vient alors de Cloudflare lui-même. C'est plus rare : un réacheminement passager de son trafic, ou une compression mal réglée sur le serveur.
• « Cette page ne fonctionne pas » avec HTTP ERROR 502 : la façon dont Chrome et Edge l'affichent quand le serveur n'envoie aucune page.

Les codes 520 à 526, eux, sont propres à Cloudflare : notre guide des erreurs 520, 521 et 522 de Cloudflare les explique.

1. PHP arrêté ou planté. PHP, le moteur qui calcule les pages de WordPress, tourne le plus souvent à part, derrière le relais, sous le nom de PHP-FPM. Arrêté après une maintenance, une mise à jour du serveur ou une panne, ou coupé en pleine page, il ne rend rien d'utilisable au relais.
2. Plus de processus PHP libres. Chaque visite occupe un processus PHP le temps de calculer sa page, et leur nombre est limité par l'offre d'hébergement (le réglage pm.max_children de PHP-FPM). Un pic de visites, des robots qui aspirent le site, des milliers de tentatives de connexion sur wp-login.php ou xmlrpc.php : les visites suivantes attendent, puis échouent en 502 ou en 504.
3. Un script trop long. Une importation, une sauvegarde, un export de commandes, de grosses images à traiter, un service extérieur qui ne répond pas : passé le temps permis, PHP-FPM peut arrêter net le processus (le réglage request_terminate_timeout), et le relais reçoit une réponse coupée. Un manque de mémoire donne plutôt une erreur 500, sauf quand c'est le serveur entier qui en manque et arrête PHP.
4. Un serveur saturé : mémoire ou processeur à bout, pour tout le serveur, ou pour votre compte sur un hébergement mutualisé qui limite les ressources de chaque site. Les erreurs tombent aux heures chargées, mêlées de 503 et de 504 : notre guide de l'erreur 503 traite la saturation en détail.
5. Une extension ou un module qui fait planter PHP : non pas une erreur de PHP, qui donnerait une erreur 500 ou une erreur critique, mais un arrêt brutal du processus. La 502 revient alors toujours sur la même page ou la même action.
6. Un changement de version de PHP, fait par vous ou par l'hébergeur : la nouvelle version n'est pas démarrée pour votre site, ou une extension trop ancienne la fait planter.
7. Un relais mal relié au serveur : après un changement de serveur, un relais qui envoie encore les visites à l'ancienne adresse ; un pare-feu du serveur qui bloque le relais ; ou des informations techniques trop longues envoyées par le site avec la page (les en-têtes, par exemple quand une extension pose trop de cookies), que nginx refuse au-delà de 4 ou 8 Ko par défaut. Derrière Cloudflare, une mauvaise adresse ou un pare-feu donnent plutôt une erreur 521, 522 ou 523.
8. Plus rarement, une panne ou une maintenance chez l'hébergeur, ou un incident chez Cloudflare lui-même.

1. Attendez une minute, puis rechargez une seule fois

Un processus PHP qui a planté est relancé de lui-même, et un pic de visites retombe : une 502 brève disparaît souvent d'elle-même. Ne rechargez pas en boucle : vous alourdiriez un serveur déjà à la peine. Notez l'heure exacte, l'adresse de la page et le message (une capture suffit), et regardez si tout le site est touché ou seulement certaines pages : l'administration, la recherche, le panier, l'enregistrement d'une page.

2. Vérifiez que ce n'est pas votre connexion

Ouvrez le site sur un téléphone en 4G, sans Wi-Fi ni VPN. Si l'erreur n'apparaît que sur votre ordinateur, la cause est de votre côté : un VPN, un proxy d'entreprise, un pare-feu ou un antivirus qui filtre le web. Si elle apparaît partout, c'est le serveur : continuez.

3. Testez une page jamais mise en cache

Une page gardée en cache s'affiche sans passer par PHP : l'accueil peut marcher alors que PHP est arrêté. Ouvrez votresite.fr/wp-login.php, que les extensions de cache ne gardent pas : si cette page tombe en 502 et pas l'accueil, c'est bien PHP qui ne répond plus. Si tout tombe, ouvrez un simple fichier image du site, en ajoutant un chiffre au hasard pour éviter le cache : votresite.fr/wp-includes/images/w-logo-blue.png?essai=7. Si le logo de WordPress s'affiche, le relais marche et c'est ce qui se trouve derrière lui, presque toujours PHP, qui bloque ; s'il renvoie aussi l'erreur, c'est le relais ou le serveur entier.

4. Regardez l'état de l'hébergeur, et la page d'erreur

La page d'état de votre hébergeur et vos e-mails d'abord : un incident ou une maintenance en cours explique tout, et il n'y a qu'à attendre. Si le site passe par Cloudflare, une page d'erreur à ses couleurs, avec un Ray ID, désigne votre serveur : la suite se passe chez l'hébergeur ou dans le site. Une page presque blanche désigne Cloudflare : cloudflarestatus.com affiche ses incidents en cours. S'il n'y en a aucun et que l'erreur dure, demandez à l'hébergeur de vérifier la compression du serveur, que Cloudflare cite comme autre cause.

5. Lisez le journal des erreurs, à l'heure notée

Sous cPanel, ouvrez Métriques, puis Erreurs : c'est le journal d'Apache, avec la ligne la plus récente en haut. Cherchez aussi un fichier error_log à la racine du site : la ligne la plus récente y est tout en bas. Sous Plesk, ouvrez Journaux, dans la fiche du domaine : proxy_error_log y est le journal de nginx. Rechargez la page en erreur juste avant, pour repérer la bonne ligne. Dans le journal de nginx ou de PHP-FPM : connect() failed ou connect() to ... failed, PHP ne répond pas du tout ; upstream prematurely closed connection, il s'est arrêté en pleine page ; reached pm.max_children setting ou reached max_children setting, ses processus sont tous occupés ; execution timed out, un script trop long a été coupé ; exited on signal 11, PHP a planté, souvent à cause d'une extension ; upstream sent too big header, le site envoie des en-têtes trop longs pour nginx. Dans le journal d'Apache, cherchez proxy_fcgi : failed to make connection to backend, PHP ne répond pas ; Failed to read FastCGI header, il s'est arrêté en route. Le journal de WordPress, décrit dans notre guide de l'erreur 500, reste vide quand PHP s'arrête net. Les journaux de PHP-FPM ne sont en général pas montrés sur un hébergement mutualisé : c'est alors l'hébergeur qui les lira (étape 9).

6. Désactivez les extensions par FTP

Si la 502 a suivi l'installation ou la mise à jour d'une extension, ou frappe toujours la même page, mettez cette extension de côté : par FTP (avec FileZilla, par exemple) ou avec le gestionnaire de fichiers de l'hébergeur, ouvrez wp-content/plugins et renommez son dossier en ajoutant .off à son nom. WordPress la désactive. Sans indice, renommez le dossier plugins entier, ouvrez la page Extensions de l'administration pour que WordPress les désactive toutes, redonnez au dossier son nom, puis réactivez-les une à une en rechargeant le site après chacune. Celle qui ramène la 502 est à mettre à jour ou à remplacer. Sur PrestaShop, voyez notre guide PrestaShop : il explique comment mettre un module de côté, puis vider le cache.

7. Revenez à la version de PHP précédente

Si la version de PHP a changé juste avant l'erreur, par vous ou par l'hébergeur (regardez ses e-mails), revenez à la précédente : sous cPanel, « Sélectionner une version de PHP » ou « MultiPHP Manager » ; sous Plesk, dans les réglages de PHP de la fiche du domaine. Mettez ensuite à jour l'extension ou le thème trop ancien, de préférence sur une copie du site, avant de repasser à une version suivie : WordPress recommande PHP 8.3 ou plus, et PHP 8.2 ne recevra plus de correctif de sécurité après le 31 décembre 2026.

8. Soulagez PHP, si ses processus sont tous occupés

Dans l'espace de l'hébergeur, l'utilisation des ressources (sous cPanel, « Utilisation des ressources », chez les hébergeurs qui en limitent l'usage) montre quand les limites sont atteintes, et le journal des visites par qui. Bloquez au pare-feu de l'hébergeur, par une extension de sécurité ou chez Cloudflare les robots qui demandent wp-login.php, xmlrpc.php ou des recherches des centaines de fois. Ajoutez une extension de cache bien réglée, qui sert la plupart des pages sans faire travailler PHP, et déplacez sauvegardes et importations la nuit. Si les limites sont atteintes chaque semaine, le site a grandi plus vite que son hébergement.

9. Faites redémarrer PHP, et donnez des faits à l'hébergeur

Sur un hébergement mutualisé, vous ne pouvez en général pas redémarrer PHP vous-même : demandez-le au support. Sur un serveur privé virtuel (VPS) ou un serveur dédié, c'est le service PHP-FPM : sous Plesk, dans la gestion des services du serveur ; en ligne de commande, sur Debian ou Ubuntu, sudo systemctl restart php8.3-fpm, en remplaçant 8.3 par votre version de PHP. Dans tous les cas, donnez à l'hébergeur l'heure exacte, l'adresse de la page, le message et, si le site passe par Cloudflare, le Ray ID : il pourra lire ses journaux à ce moment précis, vérifier les processus PHP de votre compte et s'assurer que son pare-feu laisse passer le relais.

Une 502 et une 504 qui alternent sur le même site racontent souvent la même histoire : un PHP débordé, qui répond tantôt trop tard, tantôt plus du tout.

• Erreur 504 Gateway Timeout. Le serveur placé devant le site attend trop longtemps la page : tâche trop longue, base lente, serveur saturé.
• Erreur 503 WordPress. Site bloqué en maintenance après une mise à jour, ou serveur saturé.
• Erreur 500 WordPress. « Internal Server Error » : le fichier .htaccess, une extension, la version de PHP ou la mémoire.
• Erreur 520, 521 ou 522 de Cloudflare. Le serveur qui héberge le site refuse la connexion, tarde trop ou répond de façon inattendue.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 30 octobre 2026. Manipulations vérifiées le 30 octobre 2026 ; elles valent pour WordPress 6 et 7, PHP 8.1 à 8.5, et PrestaShop 8 et 9 quand ils sont cités. Documentations consultées le 30 octobre 2026.

• Cloudflare, erreurs 502 et 504 (page aux couleurs de Cloudflare : l'erreur vient du serveur d'origine ; page sans sa marque : elle vient de Cloudflare, ou d'une compression mal réglée sur le serveur).
• Cloudflare, mise en cache par défaut (images PNG comprises) et niveaux de cache (une adresse dont le paramètre change est redemandée au serveur).
• MDN, 502 Bad Gateway (définition, réseau du visiteur).
• PHP, configuration de PHP-FPM (pm.max_children, request_terminate_timeout).
• nginx, module FastCGI (fastcgi_read_timeout, 60 secondes par défaut ; fastcgi_buffer_size, 4 ou 8 Ko, et les en-têtes trop longs) et code du relais (une connexion impossible donne une 502, un délai dépassé une 504).
• Apache, module proxy_fcgi (lignes du journal ; PHP injoignable ou arrêté en route : une erreur 503, pas une 502).
• cPanel, interface Erreurs (le journal d'Apache, le plus récent en haut), et Plesk, journaux du domaine (proxy_error_log, le journal de nginx).
• Google Search Central, erreurs HTTP et réseau (exploration ralentie, pages retirées si les erreurs durent).
• PHP, versions encore suivies (8.2 jusqu'au 31 décembre 2026), et WordPress, configuration recommandée (PHP 8.3 ou plus).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.