WordPress erreur 502 : corriger Bad Gateway

Pour corriger une WordPress erreur 502, vérifiez d’abord quel serveur renvoie le code, puis contrôlez le journal PHP, le proxy et le délai d’exécution. Une erreur 502 Bad Gateway signifie qu’un serveur intermédiaire n’a pas obtenu une réponse valide du serveur WordPress ou PHP. La correction la plus rapide consiste à comparer la page publique, /wp-admin/ et une requête locale, puis à désactiver temporairement le plugin ou le thème récemment modifié. Ne supprimez pas le site et ne désactivez pas toutes les protections sans avoir conservé les journaux.

Cette erreur apparaît souvent après une mise à jour, pendant un pic de trafic, après une modification de .htaccess ou lorsqu’un processus PHP dépasse les limites de l’hébergement. Le navigateur affiche parfois seulement « Bad Gateway », tandis que le journal du serveur indique la vraie cause. Ce guide fournit une méthode reproductible, adaptée à un hébergement mutualisé, un VPS ou une architecture avec CDN.

Que signifie une erreur 502 Bad Gateway dans WordPress

Le code HTTP 502 est renvoyé par une passerelle qui communique avec un autre serveur. Dans une installation WordPress classique, le navigateur parle à Apache ou Nginx, qui transmet la requête à PHP-FPM. Avec un CDN, un reverse proxy supplémentaire peut se trouver devant l’hébergement. Si la réponse PHP est interrompue, vide, invalide ou reçue trop tard, la passerelle renvoie 502 au visiteur.

La nuance est importante : WordPress n’est pas toujours l’émetteur direct du code. Un plugin fatal peut faire tomber PHP, mais une mauvaise configuration du proxy peut aussi provoquer le même écran sur un site dont le code est sain. Notez l’heure, l’URL, la méthode HTTP, les éventuels identifiants de requête et la présence du problème sur plusieurs appareils.

# Voir le statut et les en-têtes sans suivre les redirections
curl -sS -D - -o /dev/null https://exemple.fr/

# Mesurer le temps de réponse et le serveur qui répond
curl -sS -o /dev/null -w 'HTTP %{http_code} | total %{time_total}sn' https://exemple.fr/

Si la page d’accueil renvoie 502 mais que les fichiers statiques répondent, PHP ou la base de données est probablement impliqué. Si le site entier est inaccessible depuis plusieurs réseaux, vérifiez aussi l’hébergeur et le DNS. Si une seule URL échoue, recherchez une requête, une extension ou une règle spécifique à cette page.

Faire le tri entre erreur 502, 500 et 504

Une erreur 500 indique généralement que le serveur a rencontré une erreur interne, souvent une exception PHP, une directive invalide ou un fichier corrompu. Une erreur 502 indique un échange incorrect entre deux serveurs. Une erreur 504 signifie que la passerelle a attendu trop longtemps. Les frontières peuvent varier selon Nginx, Apache, LiteSpeed, le CDN et l’hébergeur, mais cette distinction guide les premiers tests.

Pour une erreur 500 WordPress, notre guide de diagnostic de l’erreur 500 WordPress détaille les erreurs PHP et le fichier .htaccess. Pour un problème de lenteur qui précède le 502, consultez aussi notre méthode pour analyser un back office WordPress lent. Ces diagnostics sont complémentaires, pas interchangeables.

# Tester trois zones du site
for url in / /wp-admin/ /wp-json/; do
  printf '%s : ' "$url"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}sn' "https://exemple.fr$url"
done

Une seule zone en 502 réduit le périmètre. Si /wp-json/ échoue avec une requête simple, le problème peut être global. Si seul l’administration est lente ou indisponible, cherchez une extension qui ajoute des requêtes lourdes, une limite de mémoire ou une session bloquée.

Consulter les journaux avant de modifier le site

Le journal d’erreurs est souvent la preuve la plus utile. Dans cPanel, cherchez les erreurs du domaine dans les journaux bruts ou la section dédiée aux erreurs. Sur un VPS, vérifiez les journaux Nginx ou Apache, PHP-FPM et le service de base de données. Un message comme upstream prematurely closed connection pointe vers la communication proxy et PHP. Une trace Allowed memory size exhausted pointe vers la mémoire PHP.

Activez le débogage WordPress uniquement avec une stratégie de confidentialité. Sur un site public, journalisez sans afficher les erreurs à l’écran, limitez l’accès au fichier et désactivez le mode debug après le diagnostic. La documentation officielle recommande de tester ces réglages sur un environnement de développement ou une copie de staging.

// À placer avant la ligne d’arrêt de wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Après reproduction, consultez wp-content/debug.log sans le rendre public. Cherchez l’heure exacte et la première erreur, pas seulement les messages qui suivent. Une erreur fatale dans un plugin, un appel à une fonction supprimée ou une boucle de requêtes peut expliquer la 502. Supprimez ensuite les informations sensibles et restaurez WP_DEBUG à false sur la production.

Tester un plugin ou un thème sans perdre l’accès

Une extension récemment mise à jour est un suspect prioritaire, mais désactiver toutes les extensions en production peut modifier le comportement du site. Commencez par la dernière version installée, la fonctionnalité qui déclenche l’erreur et les traces du journal. Si l’administration reste accessible, désactivez une seule extension, videz le cache puis rechargez l’URL concernée.

Si /wp-admin/ renvoie aussi 502, utilisez WP-CLI ou l’accès aux fichiers fourni par l’hébergement. Renommer temporairement le dossier d’une extension précise permet de la désactiver sans toucher aux autres. Faites une sauvegarde du nom d’origine et remettez-le dès que le test est terminé. La même méthode peut isoler un thème, mais préparez un thème de secours compatible.

# Avec WP-CLI, depuis le dossier de WordPress
wp plugin list --status=active
wp plugin deactivate nom-du-plugin
wp cache flush

# Réactiver après le test
wp plugin activate nom-du-plugin

Une erreur qui disparaît après la désactivation confirme une corrélation, pas toujours la cause exacte. Réactivez les extensions une par une et consultez le journal à chaque étape. Cherchez une version corrigée, un conflit avec PHP ou une surcharge de mémoire. Ne gardez pas une extension désactivée critique sans vérifier les conséquences de sécurité et de fonctionnement.

Contrôler PHP-FPM, la mémoire et les délais

PHP peut dépasser memory_limit, max_execution_time ou le délai du proxy. Une importation, une recherche complexe, une génération d’image ou une tâche de sauvegarde peut consommer plus de ressources qu’une page normale. Augmenter toutes les limites au hasard ne corrige pas une boucle ou une requête lente. Mesurez d’abord et cherchez la fonction qui consomme.

Contrôlez la version PHP annoncée par l’hébergement, les extensions chargées et les limites effectives. Une différence entre la version testée en local et celle de la production peut révéler une incompatibilité. Après une mise à jour PHP, testez les plugins, le thème et les tâches planifiées. Gardez une version supportée par WordPress et par vos extensions, sans revenir durablement à une version obsolète.

# Vérifications utiles depuis le serveur
php -v
php -i | grep -E 'memory_limit|max_execution_time|max_input_vars'

# Tâches WordPress visibles avec WP-CLI
wp cron event list --fields=hook,next_run_gmt, recurrence

Si PHP-FPM manque de processus disponibles, les requêtes attendent puis le proxy peut renvoyer 502 ou 504. Le support de l’hébergeur peut confirmer ce scénario avec les métriques du pool. Sur un VPS, vérifiez la mémoire, le nombre de workers et les redémarrages du service. Sur un mutualisé, réduisez les tâches lourdes et demandez les limites du compte plutôt que de modifier une configuration inaccessible.

Vérifier la base de données et les tâches lourdes

Une base de données indisponible produit souvent une erreur WordPress explicite, mais une requête lente peut se transformer en 502 lorsque le délai du proxy est atteint. Recherchez les pages qui déclenchent le problème, les imports récents, les sauvegardes et les extensions qui recalculent des index. Un pic de connexions ou une table endommagée doit être confirmé dans les outils de l’hébergeur.

Ne lancez pas une réparation SQL destructive sans sauvegarde et sans comprendre le moteur utilisé. Commencez par vérifier l’espace disque, l’état du service et les erreurs de connexion. Activez les outils de mesure sur un environnement de test. Un plugin de requêtes peut aider pendant le diagnostic, mais il ne doit pas rester actif ni visible publiquement sans contrôle.

# Tester uniquement la connexion WordPress avec WP-CLI
wp db check

# Lister les tailles de tables, si la commande est disponible
wp db size --tables

Une tâche cron qui s’exécute à chaque visite peut amplifier le problème. Examinez les événements récurrents, les imports et les appels à des API externes. Décalez les travaux lourds vers une tâche planifiée serveur lorsque c’est possible, avec une limite de durée, des logs et une reprise contrôlée.

Examiner le reverse proxy, le CDN et le DNS

Si les journaux WordPress ne contiennent aucune trace au moment du 502, la requête peut ne jamais atteindre WordPress. Vérifiez le CDN, le reverse proxy, le certificat, l’adresse IP d’origine et l’état du serveur. Un enregistrement DNS récemment modifié peut envoyer les visiteurs vers une origine arrêtée. Une règle de cache ou de sécurité peut aussi traiter différemment les pages dynamiques.

Comparez le domaine public avec l’origine seulement si vous contrôlez cette origine et si cette vérification ne contourne pas une politique de sécurité. Ne publiez pas l’adresse IP dans un article, un ticket public ou un dépôt. Pour un CDN, relevez l’identifiant de requête et l’heure, puis demandez au support le motif exact du refus. Un redémarrage n’est justifié qu’après avoir sauvegardé la configuration et vérifié l’impact.

# Observer la chaîne de résolution DNS
dig +short exemple.fr
dig +short www.exemple.fr

# Comparer le certificat et le statut public
curl -Iv https://exemple.fr/ 2>&1 | grep -E 'subject:|issuer:|HTTP/'

Évitez de mettre en cache les pages personnalisées, l’administration, les réponses REST privées et les requêtes POST. Après une correction, purgez uniquement le cache nécessaire, puis testez avec un paramètre temporaire. Vérifiez enfin la version sans paramètre pour confirmer que le cache normal sert la réponse attendue.

Procédure de remise en ligne sans aggraver la panne

La séquence recommandée est la suivante : capturer le statut et l’heure, vérifier les journaux, reproduire sur trois URLs, isoler le dernier changement, désactiver un seul suspect, tester PHP et la base, puis vérifier le proxy. Notez chaque action. Si le site revient après une désactivation, restaurez la configuration précédente, appliquez une mise à jour corrigée et testez sur staging avant réactivation.

Une sauvegarde récente doit couvrir les fichiers, la base et la configuration. Conservez une copie hors du répertoire public. Après la remise en ligne, contrôlez la page d’accueil, une page article, l’administration, la REST API, les formulaires et les tâches cron. Surveillez les journaux et les temps de réponse pendant au moins quelques heures.

Ne remplacez pas le problème par une fausse correction. Augmenter le timeout du proxy peut cacher une requête lente, désactiver le WAF peut exposer le site et supprimer un plugin peut perdre ses données. La bonne correction traite la couche fautive tout en conservant des limites et une journalisation suffisantes.

FAQ sur WordPress erreur 502

Pourquoi WordPress affiche-t-il une erreur 502 ?

WordPress affiche une erreur 502 lorsqu’un proxy ou une passerelle ne reçoit pas une réponse valide de PHP, du serveur web ou d’un service en amont. Les causes fréquentes sont un plugin fatal, un processus PHP saturé, une requête trop lente ou une panne de l’hébergeur.

Comment savoir si un plugin provoque l’erreur 502 ?

Désactivez uniquement le plugin récemment modifié, videz le cache et rejouez la même URL. Si l’erreur disparaît, confirmez avec le journal et un test de réactivation contrôlé. Ne désactivez pas toutes les extensions sans sauvegarde ni plan de retour.

Une erreur 502 vient-elle toujours de l’hébergeur ?

Non. Elle peut venir du code WordPress, de PHP, de la base, du reverse proxy, du CDN ou de l’hébergeur. L’absence de trace dans les journaux WordPress et la présence d’un identifiant côté CDN orientent vers une couche extérieure.

Quelle différence entre erreur 502 et erreur 504 ?

Une erreur 502 indique généralement une réponse invalide ou interrompue entre une passerelle et son serveur amont. Une erreur 504 indique plutôt que la passerelle a attendu trop longtemps. Les deux peuvent être liées à PHP lent, mais les journaux permettent de les distinguer.

Faut-il augmenter le délai PHP pour corriger une erreur 502 ?

Pas systématiquement. Il faut d’abord identifier la requête lente ou le processus saturé. Augmenter un délai peut éviter une coupure ponctuelle, mais peut aussi immobiliser davantage les workers PHP et aggraver la panne.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.