502 Bad Gateway : le serveur n’a pas répondu, et voici pourquoi
Votre site affiche « 502 Bad Gateway » et vous ne comprenez pas : il fonctionnait il y a une heure. Bonne nouvelle, cette erreur n’est presque jamais liée à votre contenu WordPress. Vos articles, vos pages et votre base de données sont intacts. Le problème se situe dans la communication entre deux serveurs.
Concrètement, quand vous chargez une page WordPress, une chaîne de serveurs se relaie : un serveur frontal (souvent Nginx ou un proxy comme Cloudflare) reçoit la requête, puis la transmet à un serveur applicatif (PHP-FPM) qui exécute WordPress. Une 502 signifie que le serveur frontal a bien reçu votre demande, l’a transmise… mais la réponse renvoyée était invalide ou absente. La « passerelle » (gateway) a reçu une mauvaise réponse. D’où le nom.
C’est différent d’une erreur 500, où le serveur exécute votre code et plante à l’intérieur de WordPress. Ici, souvent, PHP n’a même pas fini de répondre. La distinction oriente le diagnostic : sur une 502, on regarde d’abord le serveur et le réseau, pas les plugins.
Pourquoi ça arrive : les causes fréquentes
- 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 dépasse le délai du proxy — le frontal attend la réponse de PHP, celle-ci n’arrive pas dans le temps imparti, le frontal abandonne et renvoie 502.
- Cloudflare ou un CDN entre les deux — si votre origine ne répond pas correctement, Cloudflare affiche sa propre page 502.
- Mémoire serveur épuisée — sur un mutualisé saturé, le serveur tue les processus PHP les plus gourmands pour survivre.
- Un plugin 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’au timeout.
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 temps de lire cette phrase, le problème peut déjà être résolu.
Attendez 30 secondes, videz le cache de votre navigateur (Ctrl+Shift+R ou Cmd+Shift+R), puis rechargez. Testez aussi depuis votre téléphone en 4G, hors Wi-Fi : si le site revient sur mobile mais pas sur votre poste, c’est un cache local, pas le 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 ?
Le test : mettez temporairement Cloudflare en mode « 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.
- Si le site revient → le problème était entre Cloudflare et votre origine (souvent un timeout ou un 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 serveur
C’est la source de vérité. Une 502 laisse toujours une trace côté serveur, généralement dans les logs de Nginx et de PHP-FPM.
Où les trouver :
- Via le panel de l’hébergeur : cherchez
JournauxouLogs→ erreurs serveur. - Via SSH :
tail -100 /var/log/nginx/error.logettail -100 /var/log/php*-fpm.log.
Ce que vous cherchez : des lignes comme upstream prematurely closed connection ou connect() failed (PHP-FPM injoignable), ou pool ... server reached max_children (toutes les instances PHP 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.
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 nginxAdaptez php8.2 à votre version. Sur un hébergement mutualisé, vous n’avez pas cet accès : demandez le redémarrage au support, ou changez de version PHP dans le panel (ce qui force un redémarrage du pool).
Augmenter le nombre de workers : si le message est max_children reached, votre serveur n’a pas assez d’instances PHP pour absorber le trafic. Dans le fichier de configuration du pool (www.conf), augmentez pm.max_children — mais 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, le proxy abandonne avant que PHP ait fini : 502. Deux réglages doivent être cohérents entre eux — le délai côté PHP et le délai côté serveur frontal.
| 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é | Workers saturés en boucle | 120s |
fastcgi_read_timeout (Nginx) | Délai d’attente de la réponse PHP par Nginx | 502 sur pages lentes | 120s |
Où régler quoi :
max_execution_time,max_input_time,memory_limit→ dansphp.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.
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. Pour le détail complet de chaque directive PHP et les quatre endroits où les modifier, voir le guide directives PHP WordPress.
6. Neutralisez un plugin ou un thème qui boucle
Si la 502 est apparue juste après l’activation ou la mise à jour d’un plugin, c’est probablement lui. Un plugin qui appelle une API externe injoignable, ou qui exécute une requête base de données monstrueuse, peut bloquer un worker PHP jusqu’au timeout.
Comme l’admin est souvent inaccessible en pleine 502, procédez par FTP/SFTP : dans wp-content/, renommez le dossier plugins en plugins_off, puis rechargez. Si le site revient, remettez plugins, entrez dedans, et désactivez les plugins un par un (en les renommant) jusqu’à identifier le coupable. Même logique pour le thème via wp-content/themes/.
Tableau récapitulatif : cause → solution
| Cause probable | Premier test | Solution |
|---|---|---|
| Pic temporaire | Recharger après 30 s | Souvent auto-résolu |
| Couche Cloudflare | Pause Cloudflare | Vérifier SSL + timeout origine |
| PHP-FPM tombé | Lire logs FPM | Redémarrer le service |
| Workers saturés | max_children reached | Augmenter pm.max_children ou monter en gamme |
| Script lent | Logs upstream timeout | Aligner timeouts Nginx/PHP |
| Plugin en boucle | Renommer plugins en FTP | Réactiver un par un |
502 et 504, c'est la même chose ?
Non, mais elles sont cousines. Une 504 Gateway Timeout signifie que le serveur frontal a attendu la réponse de PHP et que le délai a expiré (le script était juste trop lent). Une 502 signifie que la réponse reçue était invalide ou que le service applicatif ne répondait pas du tout (crash, connexion refusée). En pratique, les solutions se recoupent beaucoup : timeouts, ressources serveur, plugin lent.
Le site marche pour moi mais pas pour mes visiteurs (ou l'inverse) — pourquoi ?
C’est typique d’un problème de cache ou de propagation. 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, c’est probablement un cache local ou un souci DNS de votre côté. Testez toujours en navigation privée et depuis un réseau différent pour trancher.
Est-ce que je risque de perdre des données pendant une 502 ?
Non. Une 502 est une erreur de communication réseau, pas une corruption. Votre base de données et vos fichiers ne sont pas touchés. Les seules données à risque sont celles d’un formulaire qu’un visiteur soumettait au moment exact du plantage — d’où l’intérêt de fiabiliser l’infrastructure quand les 502 se répètent.
Les 502 reviennent tous les jours à la même heure — que faire ?
Une 502 récurrente à heure fixe trahit presque toujours une tâche planifiée gourmande : sauvegarde automatique, cron WordPress, synchronisation d’un plugin. 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.
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, s’acharner coûte plus cher que de déléguer. Un prestataire accède à la configuration serveur complète et identifie en quelques minutes 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.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy