Erreur 502 WordPress : causes et solutions en 6 étapes

Une erreur 502 sur WordPress signifie que le serveur placé devant votre site (Nginx, le proxy de l’hébergeur ou Cloudflare) a demandé la page à PHP, qui exécute WordPress, et a reçu une réponse invalide ou une connexion coupée. Pour la résoudre, procédez dans cet ordre : recharger après une minute, isoler Cloudflare, lire les journaux du serveur, redémarrer PHP‑FPM, régler les délais, puis neutraliser la dernière extension ou le dernier thème modifié. Une 502 ne supprime ni vos articles, ni vos pages, ni votre base de données.

Cet article traite uniquement le cas WordPress, côté propriétaire du site. Pour la définition générale du code 502, sa traduction ou les gestes à faire en tant que simple visiteur, lisez le guide 502 Bad Gateway : signification, traduction et solutions.

Erreur 502 sur WordPress : que faire sans être technique

Vous n’avez pas besoin de toucher au serveur pour avancer. Faites ceci, dans l’ordre.

1. Vérifiez que la panne est réelle. Attendez une minute, puis ouvrez le site sur votre téléphone en 4G, hors Wi‑Fi. Infomaniak rappelle qu’une 502 peut venir d’un serveur surchargé et disparaître en rechargeant la page au bout de quelques minutes.
2. Regardez la page d’erreur. Si elle porte le logo Cloudflare, Cloudflare indique que l’erreur vient de votre serveur et conseille de contacter votre hébergeur.
3. Notez trois informations : l’heure exacte avec le fuseau horaire, l’adresse de la page en erreur, et votre dernière action sur le site (mise à jour, nouvelle extension, changement de thème).
4. Ne réinstallez rien. Ne restaurez pas de sauvegarde et ne supprimez pas d’extension au hasard tant que la cause n’est pas connue. Le problème se situe le plus souvent dans la communication entre serveurs, pas dans votre contenu.
5. Écrivez à votre hébergeur. C’est lui qui a accès aux journaux du serveur et aux réglages de PHP.

Message à copier et à compléter :

Bonjour, mon site WordPress [adresse] affiche une erreur 502 Bad Gateway depuis [heure et fuseau]. Dernière modification de ma part : [mise à jour de l’extension X, ou aucune]. Pouvez‑vous vérifier les journaux d’erreurs de Nginx et de PHP‑FPM à cette heure‑là, me dire si PHP‑FPM a atteint une limite (processus, mémoire ou durée d’exécution) et le redémarrer si besoin ? Merci de m’indiquer la cause trouvée.

Si votre site est géré par un prestataire, envoyez‑lui ce même message. Le reste de l’article s’adresse à la personne qui a accès au serveur ou aux fichiers.

Pour voir le code que renvoie votre site depuis l’extérieur, lancez notre testeur de site gratuit : code HTTP, redirections et certificat, expliqués en français et sans inscription.

Erreur 502 sur WordPress : ce qui se passe

Sur WordPress, la chaîne est presque toujours la même. Un serveur frontal (Nginx, Apache en mode proxy, ou Cloudflare devant eux) reçoit la requête du visiteur et la transmet au serveur qui exécute WordPress. Selon la RFC 9110, section 15.6.3, le code 502 signifie que ce frontal a reçu une réponse invalide. MDN précise que, si la passerelle ne reçoit aucune réponse dans le délai, le code attendu est plutôt un 504 (source : MDN Web Docs, 2026).

PHP‑FPM désigne le gestionnaire de processus PHP placé derrière ce frontal : il garde plusieurs « workers » prêts à exécuter le code de WordPress pour le compte de Nginx. L’erreur 502 apparaît quand ce maillon plante, refuse la connexion ou la coupe avant d’avoir fini.

C’est différent d’une erreur 500, où PHP exécute votre code et plante à l’intérieur de WordPress. Sur une 502, PHP n’a souvent même pas fini de répondre. La distinction oriente le diagnostic : on regarde d’abord le serveur et PHP‑FPM, ensuite les extensions.

Pourquoi WordPress affiche une erreur 502 : les causes

• PHP‑FPM est tombé ou saturé, le processus qui exécute WordPress a crashé, ou toutes ses instances sont occupées et aucune n’est libre pour répondre.
• Un script trop long est coupé par PHP‑FPM, si le pool a une limite de durée, il tue le worker qui la dépasse : Nginx voit la connexion se fermer sans réponse complète et renvoie 502. Si c’est Nginx qui se lasse d’attendre le premier, il renvoie plutôt un 504.
• Cloudflare ou un CDN entre les deux, si votre serveur d’origine répond mal, Cloudflare affiche une page 502 à ses couleurs.
• Mémoire serveur épuisée, sur un mutualisé saturé, le serveur tue les processus PHP les plus gourmands pour survivre.
• Une extension ou un thème qui part en boucle, une requête infinie ou un appel externe qui ne répond jamais bloque un worker PHP jusqu’à ce qu’il soit tué.
• Une extension de cache ou de sécurité, Hostinger cite ces deux familles comme origine fréquente sur certains sites.
• Des en‑têtes trop gros, si le début de la réponse de PHP dépasse le tampon de Nginx (4 ou 8 Ko par défaut selon la plateforme), la documentation de Nginx la considère comme invalide. Le journal indique alors upstream sent too big header.

---

Comment résoudre l’erreur 502 Bad Gateway sur WordPress

Les six étapes ci‑dessous vont du plus simple au plus technique. Arrêtez‑vous dès que le site revient : chaque étape élimine une couche de la chaîne.

1. Attendez, puis rechargez (vraiment)

Une 502 est souvent temporaire. Un pic de trafic, un redémarrage de service, une maintenance côté hébergeur : le problème peut se résoudre seul. Google traite d’ailleurs les erreurs 5xx comme un signal passager : son robot ralentit l’exploration du site tant qu’elles durent, puis la réaccélère quand les pages répondent de nouveau en 2xx. En revanche, une URL qui renvoie une erreur serveur de façon persistante finit par sortir de l’index (source : Google Search Central, 2026).

Attendez une minute, rechargez sans le cache du navigateur (Ctrl+Shift+R ou Cmd+Shift+R), puis testez depuis votre téléphone en 4G. Si le site revient sur mobile mais pas sur votre poste, cherchez du côté de votre poste ou de votre réseau, pas du serveur. Si la 502 persiste sur tous les appareils au‑delà de deux ou trois minutes, passez à la suite.

---

2. Contournez Cloudflare pour isoler la source

Si vous utilisez Cloudflare (ou un autre proxy/CDN), la première question est : l’erreur vient‑elle de votre serveur, ou de la couche Cloudflare ?

Lisez d’abord la page d’erreur. Selon la documentation Cloudflare sur les erreurs 502 et 504, une page 502 aux couleurs de Cloudflare signifie que c’est votre serveur d’origine qui a renvoyé l’erreur. Une page blanche, sans le logo Cloudflare, signale au contraire un problème côté Cloudflare, qui peut venir de la compression sur l’origine : Cloudflare propose de la désactiver pour tester. Pour ouvrir un dossier chez Cloudflare, préparez l’horodatage avec le fuseau, l’URL et le résultat de votre-domaine/cdn-cgi/trace.

Le test : mettez temporairement Cloudflare en pause (dans le tableau de bord Cloudflare, Overview → Advanced Actions → Pause Cloudflare on Site). Vos visiteurs tapent alors directement sur votre serveur d’origine, sans intermédiaire. La documentation Cloudflare sur la mise en pause indique que la pause prend 5 minutes ou moins, et que le site perd pendant ce temps le pare‑feu (WAF) et les certificats SSL/TLS fournis par Cloudflare.

• Si le site revient → le problème était entre Cloudflare et votre origine (vérifiez notamment les délais et le certificat SSL côté origine).
• Si la 502 persiste → votre serveur est bien la source. Continuez le diagnostic côté hébergement.

Réactivez Cloudflare une fois le diagnostic posé.

---

3. Lisez les logs Nginx, PHP‑FPM et WordPress

C’est la source de vérité. Une 502 laisse presque toujours une trace côté serveur, dans les logs de Nginx et de PHP‑FPM.

Où les trouver :

• Via le panel de l’hébergeur : cherchez Journaux ou Logs → erreurs serveur.
• Via SSH : tail -100 /var/log/nginx/error.log et tail -100 /var/log/php*-fpm.log (les chemins peuvent varier selon le système).

Ce que vous cherchez : des lignes comme upstream prematurely closed connection ou connect() failed côté Nginx (PHP‑FPM a coupé la connexion ou est injoignable), ou server reached pm.max_children setting côté PHP‑FPM (toutes les instances PHP sont occupées). Si vous n’avez pas encore d’accès terminal, le guide se connecter en SSH chez Gandi vous donne la procédure complète.

Pour savoir quelle extension bloque PHP, activez le journal des requêtes lentes dans le pool PHP‑FPM. Selon le manuel PHP, request_slowlog_timeout vaut 0 par défaut (désactivé) ; au‑delà du délai choisi, une trace PHP est écrite dans le fichier slowlog. Un chemin en wp-content/plugins/ ou wp-content/themes/ dans cette trace vous donne un suspect :

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www.slow

WordPress sait aussi consigner ses propres erreurs. Avec WP_DEBUG_LOG, les erreurs sont enregistrées dans un fichier debug.log placé dans wp-content, à condition que WP_DEBUG soit aussi activé (source : WordPress Advanced Administration, 2026). Ajoutez ces lignes dans wp-config.php, avant la ligne /* That's all, stop editing! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_DISPLAY vaut true par défaut : la troisième ligne évite d’afficher les erreurs aux visiteurs. La même documentation déconseille ces outils sur un site en ligne : limitez‑les au temps du diagnostic. Si le fichier reste vide alors que la 502 continue, l’erreur se situe probablement avant WordPress, dans PHP‑FPM ou le serveur.

---

4. Redémarrez ou redimensionnez PHP‑FPM

Si les logs pointent vers PHP‑FPM, deux leviers.

Redémarrer le service (si vous avez un serveur dédié ou un VPS) :

sudo systemctl restart php8.2-fpm
sudo systemctl restart nginx

Adaptez php8.2 à votre version. Sur un hébergement mutualisé, vous n’avez pas cet accès : demandez le redémarrage au support.

Augmenter le nombre de workers : si le message est server reached pm.max_children setting, votre serveur n’a pas assez d’instances PHP pour absorber le trafic. Selon le manuel PHP sur la configuration de FPM, pm.max_children est une directive obligatoire qui fixe le nombre maximal de processus enfants, donc le nombre de requêtes servies en même temps. Le même manuel précise que request_terminate_timeout vaut 0 par défaut, c’est‑à‑dire désactivé. Dans le fichier de configuration du pool (www.conf), augmentez pm.max_children prudemment : chaque worker consomme de la RAM. Sur un mutualisé, c’est un signal qu’il faut monter en gamme d’hébergement.

---

5. Réglez les timeouts et les directives PHP

Quand un script WordPress est lent, l’une des couches abandonne avant les autres. max_execution_time désigne la durée maximale d’exécution accordée à un script, plafond fixé côté PHP : sa valeur par défaut est de 30 secondes (source : PHP Manual, 2026). Le suivi par défaut mesure le temps CPU : une extension qui attend une API externe peut donc durer bien plus longtemps sans l’atteindre. Côté Nginx, fastcgi_read_timeout vaut 60 secondes par défaut, d’après la documentation officielle de Nginx. Ces réglages doivent être cohérents entre eux.

Directive	Rôle	Symptôme si trop basse	Valeur de départ
max_execution_time	Durée max d’exécution d’un script PHP	502/504 sur import, sauvegarde, cron	120
max_input_time	Temps max pour recevoir les données d’une requête	Erreur sur upload lourd	120
memory_limit	RAM allouée par script PHP	Worker tué, 502 sous charge	256M
request_terminate_timeout (PHP‑FPM)	Délai avant que FPM tue un script bloqué	502 si le worker est tué avant la fin	120s
fastcgi_read_timeout (Nginx)	Délai d’attente de la réponse PHP par Nginx	504 sur pages lentes	120s

Où régler quoi :

• max_execution_time, max_input_time, memory_limit → dans php.ini, ou via le sélecteur de version PHP du panel hébergeur (méthode la plus propre).
• request_terminate_timeout → dans la config du pool PHP‑FPM (www.conf).
• fastcgi_read_timeout → dans la config Nginx du site.
• En cas de upstream sent too big header → augmentez fastcgi_buffer_size et fastcgi_buffers dans la config Nginx du site.

La règle d’or : le timeout du frontal (Nginx) doit être supérieur ou égal à celui de PHP. Sinon Nginx coupe avant que PHP ait le temps de finir proprement. La valeur de départ du tableau est un point de départ, pas une norme : une page qui met plus de deux minutes à se générer mérite d’être optimisée plutôt que d’attendre plus longtemps. Pour le détail complet de chaque directive PHP et les quatre endroits où les modifier, voir le guide directives PHP WordPress.

---

6. Neutralisez une extension, un thème ou un cache

Si la 502 est apparue juste après l’activation ou la mise à jour d’une extension, c’est probablement elle. Une extension qui appelle une API externe injoignable, ou qui exécute une requête de base de données très lourde, peut bloquer un worker PHP jusqu’à ce qu’il soit tué.

Extensions. Comme l’admin est souvent inaccessible en pleine 502, passez par FTP/SFTP ou le gestionnaire de fichiers. La procédure de WordPress.org : dans wp-content/, renommez le dossier plugins en plugins.hold, ouvrez /wp-admin/plugins.php, puis redonnez au dossier son nom plugins. Les extensions restent désactivées : réactivez‑les une par une en testant le site après chacune, jusqu’à trouver la coupable. Avec un accès SSH, la commande WP‑CLI fait la même chose. Pour la méthode complète, voir identifier un conflit d’extensions.

wp plugin deactivate --all

Thème. Si le problème persiste, la documentation WordPress conseille de revenir à un thème par défaut. Sans accès à l’admin, renommez le dossier du thème actif dans wp-content/themes/.

Cache. Renommer plugins ne suffit pas toujours. D’après le code de WordPress, le fichier wp-content/advanced-cache.php est chargé dès qu’il existe et que WP_CACHE vaut true, que l’extension qui l’a créé soit active ou non. Le cache objet fonctionne de la même façon avec wp-content/object-cache.php. Si la 502 survit à la désactivation des extensions, renommez temporairement ces deux fichiers.

---

wp-config.php : ce qu’il peut régler face à une 502

wp-config.php ne pilote ni PHP‑FPM ni Nginx. Il agit seulement sur le comportement de WordPress. Toutes les constantes ci‑dessous sont décrites dans la documentation de wp-config.php.

Constante	Effet	Quand l’utiliser
WP_DEBUG_LOG	Écrit les erreurs dans debug.log	Pendant le diagnostic
WP_MEMORY_LIMIT	Mémoire demandée pour PHP : 40 Mo par défaut en site unique, 64 Mo en multisite	Si les journaux montrent une mémoire épuisée
DISABLE_WP_CRON	Désactive entièrement le cron de WordPress	Si les 502 suivent les tâches planifiées, avec un vrai cron serveur à la place
WP_CACHE	N’active pas le cache à lui seul, il autorise le chargement de advanced-cache.php	À passer à false pour écarter ce fichier

Si les journaux parlent de mémoire, lisez aussi le guide sur la mémoire PHP épuisée. Sur un mutualisé, la documentation de WordPress précise qu’il peut être nécessaire de demander l’augmentation à l’hébergeur.

---

Erreur 502 et hébergeur : qui peut faire quoi

Votre marge de manœuvre dépend de votre type d’hébergement.

Action	Hébergement mutualisé	VPS ou serveur dédié
Lire les journaux	Panel de l’hébergeur, parfois partiels	SSH, accès complet
Redémarrer PHP‑FPM	Demande au support	systemctl restart
Modifier pm.max_children	Demande au support, ou offre supérieure	Fichier du pool
Modifier fastcgi_read_timeout	Demande au support	Config Nginx
Renommer plugins ou le thème	FTP ou gestionnaire de fichiers	FTP, SFTP ou SSH

Hostinger conseille lui aussi de demander au support les valeurs des limites PHP et si elles peuvent être relevées. Vérifiez au passage votre version de PHP : WordPress.org recommande PHP 8.3 ou supérieur. Testez ce changement sur une copie du site si possible, certaines extensions anciennes peuvent ne pas suivre.

---

Tableau récapitulatif : cause → solution

Cause probable	Premier test	Solution
Pic temporaire	Recharger après une minute	Souvent auto‑résolu
Couche Cloudflare	Page à ses couleurs ou blanche, puis pause Cloudflare	Vérifier SSL + délais de l’origine
PHP‑FPM tombé	Logs connect() failed	Redémarrer le service
Workers saturés	server reached pm.max_children setting	Augmenter pm.max_children ou monter en gamme
Script lent	Logs upstream prematurely closed connection	Aligner timeouts Nginx/PHP
Plugin en boucle	Renommer plugins en FTP	Réactiver un par un
En‑têtes trop gros	Logs upstream sent too big header	Augmenter fastcgi_buffer_size
Cache persistant	Renommer advanced-cache.php et object-cache.php	Reconfigurer ou changer d’extension de cache

---

Quand passer la main à un pro

Une 502 qui persiste après avoir vérifié Cloudflare, les logs et PHP‑FPM signale souvent un problème d’infrastructure : hébergement sous‑dimensionné, configuration serveur bancale, ressources partagées saturées. À ce stade, un prestataire peut accéder à la configuration serveur complète et chercher si le problème vient de votre hébergement ou de votre application. Et si vous découvrez au passage que vous n’avez pas accès à votre propre serveur, lisez sans attendre les 7 accès à exiger de votre agence. Une 502, ça se règle, encore faut‑il avoir la main sur l’infrastructure.

FAQ

Comment résoudre l'erreur 502 Bad Gateway sur mon site WordPress ?

Recharger après une minute, puis contourner le proxy ou Cloudflare pour savoir si l’erreur vient du serveur lui‑même. Si elle persiste, lire les journaux d’erreur du serveur, redémarrer PHP‑FPM ou demander à l’hébergeur de le faire, et désactiver la dernière extension ou le dernier thème modifié.

Une erreur 502 sur WordPress peut‑elle venir d'un plugin ?

Oui, quand un plugin ou un thème entre dans une boucle ou dépasse le temps d’exécution de PHP, le serveur applicatif ne répond plus correctement et le serveur frontal renvoie 502. Renommer le dossier plugins via FTP permet de tout neutraliser sans accès à l’administration.

502 Bad Gateway avec Nginx et PHP sur WordPress : que vérifier ?

Une page « 502 Bad Gateway » avec « nginx » en bas est la page d’erreur par défaut de Nginx, placé devant PHP‑FPM qui exécute WordPress. Dans /var/log/nginx/error.log, connect() failed signale un PHP‑FPM arrêté ou injoignable, upstream prematurely closed connection un processus PHP coupé en cours de route. Dans le journal de PHP‑FPM, server reached pm.max_children setting montre que tous les processus étaient occupés. Les correctifs sont aux étapes 3 à 5.

Les 502 reviennent tous les jours à la même heure, que faire ?

Une 502 récurrente à heure fixe fait penser à une tâche planifiée gourmande : sauvegarde automatique ou synchronisation d’une extension, lancée par le cron du serveur. Le cron de WordPress, lui, ne se déclenche qu’au chargement d’une page, donc pas à heure exacte. Repérez l’heure dans les logs, identifiez le script qui tourne à ce moment‑là, et décalez‑le en dehors des pics de trafic, ou allégez‑le. Si votre site est globalement lent, le guide site WordPress lent traite le diagnostic de fond.

Est‑ce que je risque de perdre des données pendant une 502 ?

Une 502 est une erreur de communication entre serveurs : elle ne supprime ni votre base de données ni vos fichiers. Les seules données à risque sont celles d’un formulaire qu’un visiteur soumettait, ou d’une modification que vous enregistriez, au moment exact du plantage. Aussi, vérifiez votre dernière sauvegarde quand les 502 se répètent.

Combien de temps dure une erreur 502 ?

Elle est souvent transitoire quand le serveur est saturé ou redémarre. Si elle dure plus d’un quart d’heure ou revient à intervalles réguliers, traitez‑la comme une cause à corriger, en général les ressources PHP ou une extension.

Le site marche pour moi mais pas pour mes visiteurs (ou l'inverse), pourquoi ?

Pensez à un cache ou à une propagation DNS. Si vous voyez le site et pas eux, votre navigateur a peut‑être servi une version en cache. Si eux le voient et pas vous, regardez votre cache local ou votre DNS. Testez toujours en navigation privée et depuis un réseau différent pour trancher.

502 et 504, c'est la même chose ?

Non, mais elles sont cousines. Une 504 Gateway Timeout désigne le cas où le serveur frontal a attendu la réponse de PHP et où le délai a expiré, le script étant juste trop lent (source : MDN Web Docs, 2026). Une 502 signifie que la réponse reçue était invalide ou que le service applicatif a coupé ou refusé la connexion (crash, worker tué). En pratique, les solutions se recoupent beaucoup : timeouts, ressources serveur, extension lente.

502 ou 504 : quelle différence ?

Une 502 signifie que le serveur applicatif a répondu quelque chose d’invalide ou s’est arrêté. Une 504 signifie qu’il n’a pas répondu du tout dans le délai imparti. Les causes se recoupent, mais la 504 oriente d’abord vers les délais d’attente. Voir l’erreur 504 Gateway Timeout sur WordPress.

« 502 Gateway Time‑out » sur WordPress : 502 ou 504 ?

Le libellé « Gateway Time‑out » est celui de la page 504 de Nginx : son code source titre la page 502 « 502 Bad Gateway » et la page 504 « 504 Gateway Time‑out ». Si vous lisez « Time‑out », le serveur frontal a attendu PHP trop longtemps : commencez par les délais de l’étape 5, puis voyez l’erreur 504 Gateway Timeout sur WordPress.

Que veut dire 502 Bad Gateway en français ?

« Bad Gateway » se traduit par « passerelle incorrecte » ou « mauvaise passerelle ». Sur WordPress, le serveur qui a mal répondu est presque toujours PHP‑FPM. Pour la définition générale, valable sur tout type de site, voir l’erreur 502 Bad Gateway expliquée.