Comprendre ce que la 504 indique, et ce qu’elle ne prouve pas
Vous ouvrez une page ou lancez une opération dans WordPress, l’attente se prolonge, puis une page « 504 Gateway Timeout » apparaît. Le résultat recherché n’est pas seulement de faire disparaître ce message : il faut retrouver une réponse normale et déterminer ce qu’est devenue l’opération initiale.
Une passerelle, aussi appelée proxy, reçoit une demande puis la transmet à un autre serveur. Le code HTTP 504 signifie qu’elle n’a pas reçu à temps la réponse attendue de ce serveur en amont. Celui-ci peut lui-même attendre PHP, une base de données ou un service extérieur. Le numéro ne désigne donc pas, à lui seul, une extension responsable.
Ce guide concerne principalement WordPress auto-hébergé, avec un accès administrateur et un accès autorisé au panneau d’hébergement ou à son support. Il ne suppose aucune nouvelle extension. Un simple visiteur doit relever le message et contacter le site ; il ne peut pas corriger les délais du serveur.
Relever le contexte avant de toucher à la configuration
Notez l’adresse concernée, l’action effectuée, l’heure avec son fuseau et la durée approximative avant l’erreur. Conservez une capture nettoyée du message et l’éventuel identifiant de requête. Précisez si le problème suit une mise à jour, une migration ou une hausse de fréquentation. Ces indices permettent de rapprocher votre essai des journaux du serveur.
Si l’administration reste accessible, ouvrez Outils, Santé du site, puis Informations. Relevez les versions de WordPress et de PHP, le serveur web et les composants concernés. Cet écran renseigne sur l’installation ; il ne permet pas de modifier directement les paramètres du serveur. Si l’écran ne s’ouvre pas, demandez ces informations à l’hébergeur sans multiplier les chargements.
Pour délimiter la panne, consultez une page publique ordinaire et, si vous y êtes autorisé, un écran administratif sans lancer d’action. Une page déjà en cache peut fonctionner alors que PHP ne répond plus correctement. À l’inverse, une panne limitée à un import ne signifie pas que tout le site est indisponible.
Si les outils de développement du navigateur étaient déjà ouverts, consultez Réseau et sélectionnez la requête enregistrée : relevez son statut et sa durée sans la renvoyer. Cet écran ne reconstitue pas forcément un échange antérieur à son ouverture. Un message mentionnant 504 dans l’application peut décrire un appel secondaire, pas toute la page. Ne partagez pas un journal réseau contenant des secrets.
Avant toute relance, vérifier si l’opération a déjà produit un résultat
Après un paiement, une importation ou un envoi, ne rechargez pas le formulaire et ne cliquez pas une seconde fois sur son bouton. Une erreur reçue par le navigateur ne garantit ni l’annulation du travail ni son absence de résultat. Selon l’application et la configuration, un traitement peut continuer, s’arrêter ou avoir déjà enregistré une partie des données.
Ouvrez séparément l’écran de suivi prévu par le composant, sans relancer sa commande. Pour un import, recherchez son historique, son identifiant de tâche et les éléments effectivement créés. Pour une boutique WooCommerce, ouvrez WooCommerce, puis Commandes avec un compte autorisé ; consultez la commande, ses notes et la référence du paiement chez le prestataire. Ce suivi commercial appartient à WooCommerce, pas au cœur de WordPress.
Si les informations divergent, demandez au support de rapprocher les références avant de décider d’une reprise. L’absence de courriel ne prouve pas qu’un paiement a échoué. Ne marquez pas artificiellement une commande comme payée et ne déclenchez pas de remboursement pour résoudre une simple incertitude d’affichage.
Choisir entre les trois approches
Utilisez l’approche passerelle lorsque plusieurs pages sont touchées, qu’un proxy est présent ou que la panne a commencé après une modification de l’hébergement. Elle sert à situer le refus avant toute modification de WordPress.
Choisissez l’approche PHP et composants lorsqu’une action précise est lente, que les ressources saturent ou que les journaux orientent vers un traitement local. Préparez alors une reproduction maîtrisée sur une copie.
Prenez l’approche API externe si une fonction attend un service distant : livraison, traduction, paiement ou synchronisation, par exemple. Plusieurs couches peuvent être impliquées. Passez d’une approche à l’autre selon les preuves recueillies, sans appliquer toutes les corrections en même temps.
Approche 1 : localiser la passerelle qui a cessé d’attendre
Depuis le panneau d’hébergement, vérifiez le domaine sélectionné et l’état des services. Consultez aussi la page officielle d’incidents de l’hébergeur et, si vous en utilisez un, du service de proxy ou de diffusion. Une interruption déclarée permet d’éviter une modification inutile du site. Notez sa période et les services réellement concernés.
Sur la page d’erreur, le nom d’un serveur ou le logo d’un prestataire constitue un indice, pas une preuve suffisante de responsabilité. Demandez au support de comparer les réponses à l’entrée du proxy et celles du serveur d’origine, c’est-à-dire le serveur qui héberge effectivement le site. Une erreur d’origine peut être retransmise par un intermédiaire.
Si un contrôle direct de l’origine est nécessaire, faites-le organiser par le prestataire avec le bon domaine, le certificat et les restrictions d’accès. Ne remplacez pas simplement le domaine par une adresse IP : le résultat pourrait concerner un autre site. Ne désactivez pas globalement le proxy ou le pare-feu pour obtenir un essai.
Le résultat attendu est l’identification du maillon qui expire. Si cette information manque, passez aux journaux avant de choisir une valeur de délai.
Rapprocher les journaux d’un seul essai identifiable
Dans le panneau, recherchez les journaux d’accès et d’erreurs du domaine concerné ; leur emplacement dépend de l’offre. Demandez au support les entrées correspondant à l’heure relevée si vous ne disposez pas de ces écrans. Précisez le fuseau utilisé, le chemin demandé et l’identifiant disponible, sans envoyer vos cookies ou vos identifiants de connexion.
Faites distinguer une attente de connexion vers l’amont d’une attente de réponse déjà commencée. Demandez également si l’origine a enregistré la demande et quelle durée elle a observée. L’objectif est de reconstruire le trajet de cet essai, non de déduire une cause d’une ligne ancienne sans rapport avec lui.
Une réponse 504 à l’entrée et une opération finalement terminée à l’origine ne racontent pas la même chose qu’un processus arrêté. Conservez cette différence dans le diagnostic. L’absence d’entrée dans un journal ne prouve rien tant que son périmètre, sa période de conservation et son activation ne sont pas confirmés.
Approche 2 : examiner PHP et les ressources réellement utilisées
PHP exécute une grande partie du travail de WordPress. Sur de nombreux hébergements, PHP-FPM répartit les demandes entre plusieurs processus de travail. Dans les statistiques du domaine, regardez les limites atteintes et les périodes de forte consommation. Demandez au support si les demandes patientent faute de processus disponible ou si un traitement occupe anormalement les ressources.
Une limite de processus n’est pas une invitation à doubler sa valeur. Chaque processus consomme aussi de la mémoire ; un réglage excessif peut aggraver la panne. Faites dimensionner une modification à partir des ressources de l’offre et des mesures. Demandez quel domaine ou groupe de sites serait affecté.
Si la lenteur suit une extension, notez son nom, sa version et l’action concernée. Une coïncidence temporelle est un point de départ, pas une preuve. Si plusieurs traitements lourds se chevauchent, demandez lesquels peuvent être décalés normalement, après vérification de leur état, plutôt que de tuer des tâches au hasard.
Ne pas confondre le temps PHP et le temps de la passerelle
Le réglage PHP max_execution_time et le délai du proxy mesurent des choses différentes. Sous les systèmes autres que Windows, le calcul du temps d’exécution PHP n’inclut pas nécessairement l’attente de certaines opérations externes, notamment des requêtes de base de données. Sous Windows, la mesure inclut le temps réel. Un nombre affiché dans PHP ne décrit donc pas toute l’attente du navigateur.
PHP-FPM possède aussi des réglages propres. request_terminate_timeout peut arrêter un processus après un délai ; request_slowlog_timeout sert à consigner la pile d’exécution d’une requête lente. Leur nom ressemble à une solution immédiate, mais leur rôle diffère. Faites exploiter temporairement le journal des lenteurs par l’administrateur de l’hébergement, avec un stockage privé et une durée de collecte limitée.
Le résultat utile est un traitement ou une attente identifiés. Sans cela, augmenter le temps autorisé peut simplement prolonger l’occupation des ressources. Ne cherchez pas une valeur universelle à copier dans tous les fichiers.
Isoler un composant sans casser le site en production
Avant une modification, préparez une sauvegarde des fichiers et de la base, ainsi qu’un moyen de restauration indépendant du tableau de bord. Créez si possible une copie séparée. Vérifiez qu’elle possède sa propre base et neutralisez les paiements, courriels et intégrations externes : une copie peut encore appeler des services réels.
Avec les droits administrateur de cette copie, ouvrez Extensions, puis Extensions installées. Désactivez seulement le composant suspect si son rôle permet cet essai. Reproduisez une opération non sensible et comparable, relevez le résultat, puis réactivez le composant avant d’en examiner un autre. Une disparition du symptôme doit être confirmée, pas extrapolée à toutes les fonctions.
Si le composant gère l’accès, les commandes ou une fonction essentielle, préparez l’intervention avec son responsable. Sans copie fiable, demandez une fenêtre adaptée ou une analyse par l’hébergeur. Ne renommez pas tout le dossier des extensions comme premier réflexe.
Pour revenir en arrière, rétablissez l’état exact noté avant l’essai. Si des données ont changé, examinez leur récupération séparément ; réactiver une extension ne restaure pas automatiquement ces données.
Recueillir une erreur WordPress sans la rendre publique
Commencez par les journaux privés déjà disponibles. Si un débogage WordPress supplémentaire est nécessaire, demandez une activation temporaire et ciblée, de préférence sur la copie. Les constantes WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY ne sont pas interchangeables : l’une active le débogage, une autre la journalisation, la dernière l’affichage dans les pages.
Faites conserver les messages hors de l’affichage public et utilisez un emplacement de journal protégé. Le fichier habituel dans wp-content ne doit pas être supposé privé parce que son nom est peu visible. Recueillez uniquement la période utile, masquez les données personnelles et remettez les réglages antérieurs après la collecte.
Un journal WordPress vide n’exclut pas une panne de proxy, une attente réseau ou une saturation. Ne créez pas de fichier public de diagnostic pour compenser cette absence. Transmettez les indices obtenus et les limites de la collecte à la personne qui examine PHP.
Approche 3 : vérifier une API externe sans répéter son action
Une API est une interface par laquelle WordPress ou une extension échange avec un autre service. Si seule une fonction intégrée échoue, consultez l’état officiel de ce service et l’historique disponible dans le composant. Relevez le nom du service, l’heure, la référence d’opération et le message, en masquant les clés et les données personnelles.
Distinguez une réponse HTTP 504 réellement reçue de l’API d’une erreur locale indiquant que WordPress n’a pas reçu de réponse à temps. L’API HTTP de WordPress possède son propre délai et peut retourner une erreur sans réponse HTTP exploitable. Une extension peut également employer un autre client réseau ; son réglage n’est pas forcément celui de WordPress.
Demandez à l’éditeur de rapprocher la référence distante des journaux locaux et de préciser le mécanisme de reprise prévu. Si le service a accepté l’action, poursuivez son suivi au lieu d’en créer une seconde. Si aucun état fiable n’est disponible, maintenez l’opération comme non confirmée.
Ne supprimez pas la vérification des certificats et n’autorisez pas toutes les connexions sortantes pour masquer le symptôme. Une modification doit viser le service et la cause démontrés.
Pour les imports longs, préférer une reprise prévue par l’outil
Quand le problème concerne un import, consultez sa documentation et son écran de suivi avant de le fractionner. Cherchez si l’outil conserve une progression, reconnaît les éléments déjà traités et permet de reprendre un lot. Un fichier plus petit n’évite pas les doublons si chaque relance recrée les mêmes contenus.
Sur la copie sécurisée, choisissez un lot limité et identifiable. Conservez le fichier source et les identifiants des éléments attendus. Après l’essai autorisé, contrôlez les créations, les mises à jour et les rejets. Si le traitement dépasse encore le délai, arrêtez les nouveaux essais et transmettez ces résultats au support de l’outil.
Un traitement en arrière-plan ou par les outils de l’hébergeur peut convenir lorsqu’il est expressément prévu. Il ne garantit pas l’absence de limite et doit toujours être suivi. Ne transformez pas une commande d’import complète en tâche répétée pour contourner la page d’erreur.
Modifier un délai seulement après avoir identifié sa portée
Si l’hébergeur confirme qu’un traitement légitime dépasse une limite trop courte, demandez un ajustement ciblé et borné. Sous Nginx, proxy_read_timeout concerne la lecture depuis le serveur HTTP en amont ; fastcgi_read_timeout concerne la lecture depuis FastCGI, souvent utilisé pour PHP. Ces délais s’appliquent entre lectures successives, pas automatiquement à la durée totale de la réponse.
Sous Apache utilisé comme proxy, ProxyTimeout relève d’un autre emplacement de configuration. Un ajout dans .htaccess ou dans WordPress ne remplace pas nécessairement le réglage de la passerelle. Faites préciser le fichier réellement chargé, le domaine et les limites du service placé devant lui.
Avant application, consignez l’ancienne valeur, la nouvelle, le motif et le retour arrière. Faites valider la configuration par l’administrateur puis observez une opération autorisée. Si la panne persiste ou que les ressources se dégradent, rétablissez la valeur antérieure. Ne laissez pas de durée illimitée pour une cause encore inconnue.
Adapter la procédure à WordPress.com et au multisite
Sur WordPress.com, commencez par le support et les fonctions réellement accessibles dans votre compte. Les fichiers et paramètres serveur d’une installation auto-hébergée ne sont pas forcément modifiables sur cette plateforme. Transmettez la page concernée et les observations ; n’installez pas une extension uniquement pour tenter de changer un délai imposé par l’hébergement.
Dans un réseau multisite, comparez le sous-site affecté avec un autre, sans lancer d’opération commerciale. Certaines extensions sont administrées au niveau réseau et plusieurs sites partagent les ressources. Faites intervenir l’administrateur du réseau avant toute désactivation ou modification commune. Une correction doit préserver les autres sous-sites, pas seulement l’adresse qui a servi au diagnostic.
Contrôler le résultat et remettre les protections en place
Après la correction ciblée, ouvrez d’abord les pages ordinaires concernées. Contrôlez ensuite, avec autorisation, une opération comparable et non sensible. Relevez sa durée, son résultat enregistré et les éventuelles nouvelles erreurs. Une page d’accueil accessible ne suffit pas à valider un import qui échouait dans l’administration.
Pour un paiement resté incertain, terminez d’abord le rapprochement de l’opération initiale. Ne faites pas un nouvel achat réel pour vérifier la disparition du message. Sur une copie, utilisez seulement le mode de test officiellement prévu et vérifiez l’absence d’effets réels.
Rétablissez les composants nécessaires, fermez le débogage temporaire et gardez une trace de la modification retenue. Si la correction ne tient qu’avec une protection désactivée, le diagnostic n’est pas terminé. L’objectif reste une fonction normale avec les protections habituelles.
Transmettre un dossier utile et prévenir la récidive
Si vous devez escalader, rassemblez le domaine, les versions, l’heure et le fuseau, le chemin concerné, la durée d’attente et les références d’opération. Ajoutez les extraits nettoyés et les modifications essayées avec leur résultat. Précisez ce qui demeure inconnu, notamment l’état d’un import ou d’un paiement.
Demandez quelle couche a produit la 504, si le traitement est encore actif et quelle action peut être reprise sans doublon. Si l’hébergeur et l’éditeur interviennent ensemble, transmettez les mêmes références aux deux interlocuteurs pour éviter deux diagnostics portant sur des essais différents.
Enfin, conservez un relevé des limites et des fenêtres de traitements lourds. Testez les changements importants sur une copie protégée et vérifiez régulièrement les sauvegardes. Une 504 maîtrisée se résout par une cause identifiée et un résultat contrôlé, pas par une succession de relances.
