Erreurs 502/504 sur WordPress : diagnostic rapide côté CDN, serveur et PHP-FPM

Tu viens de tomber sur une erreur 502 ou 504 et ton site WordPress est indisponible ? Respire. Dans 80% des cas, le problème est traçable en quelques minutes si tu suis une méthode claire. Dans cette introduction, on pose le cadre : on va traiter spécifiquement les pannes “erreur 502 WordPress”, “erreur 504 WordPress”, “bad gateway WordPress”, les codes Cloudflare “cloudflare 522 524” et tout ce qui touche aux “timeout PHP FPM”. L’objectif : un dépistage rapide, propre, reproductible — et des correctifs qui tiennent. Chez WP Builders, on intervient tous les jours sur du dépannage WordPress 502 504. Cette check-list condense nos meilleures pratiques de terrain pour que tu puisses reprendre la main, même sans être admin système confirmé.

Pourquoi ces erreurs arrivent-elles ? En simplifiant : 502 Bad Gateway = un proxy (CDN, Nginx, Load Balancer) n’a pas obtenu une réponse valide en amont. 504 Gateway Timeout = la réponse a trop tardé. Les causes typiques : timeouts trop courts, workers saturés côté PHP-FPM, goulots d’étranglement réseau entre le CDN et l’origine, ou une requête WordPress trop lourde (plugin, requête SQL lente, API externe). On va donc remonter la chaîne de traitement : client → CDN/reverse proxy → serveur web → PHP-FPM → base de données → services externes. Tu vas trouver ci-dessous des commandes à copier-coller, les logs exacts à regarder et des réglages sécurisés pour reprendre le contrôle pas à pas.

Erreurs 502/504, 522/524 : comprendre le signal et le contexte

Avant de corriger, il faut distinguer les codes :

• 502 Bad Gateway (souvent côté Nginx/Load Balancer) : l’amont renvoie une réponse invalide ou rien du tout.
• 504 Gateway Timeout : l’amont met trop longtemps à répondre (ex. script PHP lent, I/O bloqués).
• Cloudflare 522 : le CDN n’arrive pas à établir la connexion TCP avec l’origine (connect timeout).
• Cloudflare 524 : la connexion est établie mais l’origine met trop de temps à répondre (request timeout).

Cloudflare propose une bonne base de diagnostic sur ses erreurs 5xx. Pour aller plus loin : Guide Cloudflare sur les erreurs 5xx.

Check-list express (10 minutes) pour isoler la zone en faute

1. Le site est-il KO pour tout le monde ? Teste depuis un autre réseau, un mobile en 4G, et exécute :
   

   curl -I https://ton-domaine.tldcurl -I --resolve ton-domaine.tld:443:IP_ORIGINE https://ton-domaine.tld

   Si le second fonctionne et pas le premier, suspecte le CDN/proxy/DNS.
2. CDN actif ? Bypass temporaire en pointant le DNS vers l’IP directe ou en activant le mode “Développement” du CDN. Sur Cloudflare, désactive l’orange cloud (proxy) pour tester.
3. Reverse proxy OK ? Regarde les logs d’erreur du serveur web :
   

   # Nginxsudo tail -n 200 /var/log/nginx/error.log# Apachesudo tail -n 200 /var/log/apache2/error.log

4. PHP-FPM sature ? Vérifie l’état et les erreurs :
   

   sudo systemctl status php8.2-fpmsudo tail -n 200 /var/log/php8.2-fpm.log

5. Base de données : détecte les requêtes lentes ou bloquées :
   

   sudo tail -n 200 /var/log/mysql/error.logmysql -e "SHOW PROCESSLIST;"

6. Charge système : CPU, RAM, I/O :
   

   htopvmstat 2 10iostat -x 2 5

7. Test page simple PHP : crée /health.php :
   

   <?php echo "OK ".date('c');

   Si /health.php répond vite mais pas WordPress, l’app est en cause (plugins, requêtes).
8. WP-CLI :

   wp plugin list --path=/var/www/htmlwp option get home --path=/var/www/html

9. Logs réseau/pare-feu : vérifie que le port 443/80 est ouvert depuis le CDN vers l’origine (Security Group, iptables, fail2ban).
10. Si 522/524 : traceroute depuis l’origine vers les IP Cloudflare, et augmente temporairement les timeouts côté Nginx/PHP-FPM pour confirmer.

Diagnostic côté CDN et reverse proxy

Étapes rapides sur Cloudflare, Fastly & co.

• Mode développement (bypass cache/minification) pour écarter un bug de transformation.
• Désactiver temporairement le proxy (Cloudflare orange → gris) et pointer directement l’IP d’origine pour tester.
• Firewall/WAF : vérifie les événements bloqués. Les règles trop strictes ou un rate limiting agressif coupent parfois les requêtes admin-ajax.php.
• Origine accessible ? Depuis l’extérieur :
  

  curl -I https://IP_ORIGINEcurl --connect-timeout 5 -I https://ton-domaine.tld

• 522 = connect timeout : problème de routage, firewall, saturation TCP, ou serveur down.
• 524 = request timeout : l’origine répond mais trop lentement (requête PHP/SQL lourde).

Si tu utilises des règles spécifiques de cache pour WordPress (exclusion de /wp-admin/, no-cache sur cookies de session), valide-les. Un cookie mal géré peut provoquer des MISS systématiques et charger l’origine inutilement.

Reverse proxy Nginx devant Apache/PHP-FPM

Un 502/504 survient souvent car Nginx n’a pas obtenu la réponse de PHP-FPM à temps. Regarde les messages “upstream timed out”, “connect() to unix:/run/php/php8.2-fpm.sock failed”.

sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 50sudo grep -i "connect() to unix" /var/log/nginx/error.log | tail -n 50

Paramètres de tolérance (à ajuster prudemment) :

http {  send_timeout 15s;  proxy_connect_timeout 5s;  proxy_read_timeout 60s;  proxy_send_timeout 60s;}server {  location ~ \.php$ {    include fastcgi_params;    fastcgi_pass unix:/run/php/php8.2-fpm.sock;    fastcgi_connect_timeout 5s;    fastcgi_read_timeout 60s;    fastcgi_send_timeout 60s;    fastcgi_buffers 32 32k;    fastcgi_busy_buffers_size 64k;  }}

Référence utile sur les directives FastCGI : Documentation Nginx FastCGI.

Diagnostic côté PHP-FPM : timeouts et workers saturés

Quand PHP-FPM n’a plus de workers disponibles (pm.max_children atteint) ou qu’un script monopolise le CPU/IO, Nginx finit par timeouter → 504. Si PHP-FPM est down ou l’Unix socket introuvable → 502.

Vérifier l’état et le slowlog

sudo systemctl status php8.2-fpmsudo tail -n 200 /var/log/php8.2-fpm.logsudo grep -i "slow" /var/log/php8.2-fpm.log | tail -n 50

Active le slowlog si nécessaire :

; /etc/php/8.2/fpm/pool.d/www.confrequest_slowlog_timeout = 5sslowlog = /var/log/php8.2-fpm.slow.log

Expose un statut (local uniquement) pour mesurer l’occupation :

; /etc/php/8.2/fpm/pool.d/www.confpm.status_path = /fpm-statuspm = dynamicpm.max_children = 20pm.start_servers = 4pm.min_spare_servers = 2pm.max_spare_servers = 8

# Accès local via Nginxlocation ~ ^/(fpm-status|fpm-ping)$ {  allow 127.0.0.1; deny all;  include fastcgi_params;  fastcgi_pass unix:/run/php/php8.2-fpm.sock;  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;}

curl -s http://127.0.0.1/fpm-status | sed -n '1,20p'

Si “max children reached” augmente, tes workers saturent. Augmente pm.max_children avec méthode, ou passe en pm.ondemand pour des pics irréguliers.

Dimensionner correctement PHP-FPM

Calcule la RAM par worker (en moyenne 60–120 Mo selon extensions). Règle pm.max_children ≈ RAM_disponible_PHP / RAM_par_worker, en gardant une marge pour le système et MySQL.

# Estimer la mémoire PHP par processps -ylC php-fpm8.2 --sort:rss | awk '{sum+=$8} END {print sum/NR/1024 " MB moyen"}'# Voir l’occupation mémoire totale et le swapfree -m

Si ton serveur a 2 Go de RAM et que chaque worker consomme ~90 Mo, pm.max_children ne doit pas dépasser ~15 (en laissant de la marge pour Nginx/MySQL). Sur des sites à trafic soutenu, ajoute un cache d’objets (Redis) pour soulager PHP.

Base de données MySQL/MariaDB : faux coupable ou vraie cause ?

Une base lente entraîne des requêtes PHP longues → 504. Cherche les “slow queries”.

mysql -e "SHOW VARIABLES LIKE 'slow_query_log%';"mysql -e "SET GLOBAL slow_query_log=ON; SET GLOBAL long_query_time=1;"# Après quelques minutessudo tail -n 200 /var/lib/mysql/$(hostname)-slow.log

Indicateurs à surveiller :

• long_query_time trop haut (descends à 0.5–1s pour capturer les pires requêtes).
• max_connections insuffisant (erreurs “Too many connections”).
• innodb_buffer_pool_size trop petit (vise 50–70% de la RAM si MySQL dédié).

# Ajustements de base (exemple)[mysqld]innodb_buffer_pool_size = 1Gmax_connections = 200innodb_flush_log_at_trx_commit = 2slow_query_log = 1long_query_time = 1

Dans WordPress, cible les plugins générant des requêtes lourdes (statistiques, recherche, constructeurs). L’extension Query Monitor aide à identifier les hooks et requêtes lentes.

Niveau application WordPress : cron, plugins, thèmes et API externes

Tester sans plugins et thème enfant

# En staging idéalementwp plugin deactivate --all --path=/var/www/htmlwp theme activate twentytwentyfour --path=/var/www/htmlwp cache flush --path=/var/www/html

Si le 502/504 disparaît, réactive par paquets de 5 plugins pour trouver le coupable. Pense aux modules de sécurité pouvant bloquer admin-ajax.php ou REST API.

wp-cron et tâches planifiées

Sur des sites à trafic important, wp-cron à chaque requête est coûteux et peut déclencher des 504 sous charge.

# wp-config.phpdefine('DISABLE_WP_CRON', true);# Crontab système (toutes les 5 minutes)*/5 * * * * www-data wp cron event run --due-now --path=/var/www/html >/dev/null 2>&1

Appels API externes

Un appel bloquant à une API (paiement, email, géolocalisation) peut provoquer un 504. Loggue les timeouts via le WP_HTTP et impose des délais raisonnables (5–10 s) et des retries intelligents.

Réseau, DNS et sécurité : éliminer les goulots invisibles

• DNS : enregistrements A/AAAA pointent-ils bien vers l’origine active ? TTL réduit pendant l’incident (120s) pour pivoter rapidement.
• Firewall : Security Groups, iptables, fail2ban n’étranglent-ils pas les IP du CDN ? Autorise explicitement les ranges si nécessaire.
• MTU/Path : rare mais possible sur tunnels/VPN. Diagnostic :
  

  mtr -rwzbc100 ton-domaine.tldtraceroute ton-domaine.tld

Correctifs immédiats (stabiliser en moins de 30 minutes)

1. Bypass temporaire le CDN et pointe le DNS vers l’origine stable. Si nécessaire, active une page statique de secours.
2. Augmente prudemment les timeouts côté Nginx/PHP-FPM (ex. +30s) pour absorber le pic le temps de corriger la cause.
3. Redémarre proprement :
   

   sudo systemctl reload nginxsudo systemctl reload php8.2-fpmsudo systemctl restart mysql

4. Met en maintenance 503 pendant les tests pour éviter de surcharger :

   if (-f $document_root/maintenance.enable) { return 503; }error_page 503 @maintenance;location @maintenance { try_files /maintenance.html =503; }

5. Désactive le plugin fautif si identifié, ou reviens à une version stable.
6. Scale vertical/Horizontal si tu es en conteneurs/VM (ajoute des workers, plus de RAM/CPU).

Actions préventives durables (éviter la rechute)

Surveillance proactive

• Uptime + temps de réponse (1 min) avec alertes Slack/Email.
• Metrics système : CPU, RAM, I/O, saturation PHP-FPM (max_children reached), erreurs 5xx/min.
• Logs centralisés (ELK, Loki) avec règles sur “upstream timed out”, “connect() failed”.

Performance applicative

• Object cache (Redis) pour réduire la charge PHP/SQL.
• Page cache (Nginx microcache, plugin de cache adapté à l’hébergeur).
• Images/Assets optimisés, HTTP/2/3, preloading critique.
• DB : index pertinents, nettoyage transients/options autoloaded.

Process et outillage

• Staging systématique pour tester les mises à jour.
• Backups complets + restaurations testées.
• Audit trimestriel de sécurité/performance.
• Budget de performance (TTFB, P95). Si on dépasse, on agit.

Un partenaire maintenance comme WP Builders peut piloter ce dispositif, te fournir des rapports mensuels lisibles et intervenir en moins de 2h en cas d’alerte 5xx.

Cas pratiques et recettes de terrain

Pic de trafic → 504 sur checkout WooCommerce

• Symptôme : 504 aléatoires pendant les pics.
• Cause : pm.max_children trop bas, MySQL saturé, absence de cache d’objets.
• Fix : Redis Object Cache, pm.max_children +30%, microcache Nginx 60s pour pages non-auth, index DB sur meta requise.

502 après mise à jour PHP

• Symptôme : 502 immédiat.
• Cause : socket PHP-FPM différent, fastcgi_pass non mis à jour.
• Fix : ajuster fastcgi_pass vers /run/php/php8.2-fpm.sock, recharger Nginx + PHP-FPM.

Cloudflare 522 récurrent le matin

• Symptôme : 522 sur certaines POP.
• Cause : fenêtre de sauvegarde chez l’hébergeur saturant I/O, connect timeout.
• Fix : décaler backups, autoriser IP Cloudflare, monitorer iostat, augmenter proxy_connect_timeout à 10s.

Matrice décisionnelle (où agir en premier)

• Erreur affichée par le CDN (522/524) → Réseau/pare-feu/latence origine OU lenteur applicative. Test direct IP, traceroute, logs CDN.
• 502 Nginx avec “connect() failed” → PHP-FPM down/sock erroné.
• 504 Nginx avec “upstream timed out” → PHP-FPM saturé/DB lente. Vérifie fpm-status, slowlog, slow queries.
• Seulement en admin → AJAX/REST/API externe. Inspecte Query Monitor et WP-CLI.

Commandes utiles (mémo)

# Nginx/Apachesudo nginx -t && sudo systemctl reload nginxsudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log# PHP-FPMsudo systemctl status php8.2-fpmsudo tail -f /var/log/php8.2-fpm.log# MySQLmysql -e "SHOW PROCESSLIST;"# WP-CLIwp plugin list --path=/var/www/htmlwp option get siteurl --path=/var/www/html# Connexions et socketsss -lpn | grep php-fpmlsof -U | grep php-fpm

Aller plus loin

Tu veux creuser les codes 5xx côté CDN, les causes d’upstream Nginx et les bons réglages PHP-FPM/Redis pour WordPress ? Ce guide te donne la trame, mais chaque stack a ses nuances (hébergeur, réseau, plugins). Chez WP Builders, on combine diagnostic bas-niveau et bonnes pratiques WordPress pour un résultat fiable et durable. Contacte-nous si tu veux une reprise en main complète ou un plan de maintenance préventive.

Conclusion

Les erreurs 502/504 ne sont pas une fatalité. En partant du CDN/reverse proxy, en vérifiant les timeouts et la saturation PHP-FPM, puis en inspectant la base et l’application, tu peux isoler la cause, poser un correctif immédiat et éviter la rechute. Garde cette check-list à portée de main, et pense à institutionnaliser la prévention (monitoring, audits, staging, sauvegardes). Si tu préfères déléguer l’urgence et la méthode, l’équipe WP Builders peut intervenir rapidement et te laisser un socle pérenne pour la suite.