NouveauBlack Friday : 50 % de réduction sur votre premier paiement
Dépannage WordPress

504 Délai d'arrêt de la passerelle

PHP fonctionnait encore quand le serveur web a abandonné l'attente. Rien n'a crashé - il a simplement fallu plus de temps que le temps de sortie le permet.

504 Gateway Timeout

Réponse rapide

Quelque chose dans la requête est lent, et soulever le délai de sortie signifie seulement attendre plus longtemps pour la même page. Identifiez d'abord l'étape lente : une requête, un appel API sortant, ou une importation courant dans une requête web.

Diagnostic

Les causes les plus probables d’abord.

Parcourez la liste dans l’ordre. Vérifiez chaque cause avant de modifier quoi que ce soit : les correctifs diffèrent et une supposition coûte plus cher qu’une commande.

CauseComment vérifierCorrectif
Une requête HTTP sortante sans délaiL'URL lente appelle un tiers - un contrôle de licence, un flux, une passerelle de paiement. Il est rapide lorsque ce service est rapide.Définissez un timeout explicite sur l'appel sortant et cachez la réponse. WordPress attend beaucoup plus par défaut que tout visiteur ne le fera.
Une requête sans index derrière elleLa page lente est une archive filtrée ou un rapport, et la base de données affiche la même requête en haut sous charge.Ajouter l'index dont la requête a besoin. Un scan qui était parfait à dix mille lignes est un timeout à un million.
Une importation ou une exportation qui se déroule dans une demande webLe timeout ne se produit que sur une action d'administration que vous avez commencée, et il échoue à peu près au même moment écoulé chaque tentative.Déplacez le travail vers WP-CLI ou un parcours de fond en morceaux. Un onglet navigateur est le mauvais endroit pour le travail mesuré en minutes.
Cron s'accumulant sur les charges de pageLe retard se situe sur les URL front-end ordinaires, sporadiquement, sur un site avec une liste d'événements en retard de longue date.Désactivez WP-Cron et conduisez-le à partir du planificateur système, de sorte que les travaux programmés cessent d'être chargés à chaque visiteur qui arrive en premier.
Le temps de travail est vraiment trop court pour le travailTout ce qui précède est exclu et l'opération est légitimement longue - une grande sauvegarde, une grande conversion des médias.Relever le délai pour ce chemin seulement. L'élever globalement supprime le plafond qui arrête une mauvaise demande occupant un travailleur.
Guide

Corriger l’erreur, étape par étape.

Les commandes supposent un accès à WP-CLI et au terminal. Si vous n’en disposez pas, chaque étape explique comment procéder depuis le tableau de bord ou via SFTP.

  1. Découvrez quelle URL est lente

    Le journal d'accès enregistre le temps que chaque demande a pris. Trier par cela et la réponse est généralement une ligne.

    awk '{print $NF, $7}' /var/log/nginx/access.log | sort -rn | head -n 10
  2. Demandez à la base de données sur quoi elle consacre du temps

    Une requête à long terme apparaît ici alors que la page est toujours en cours de chargement.

    mysql -e 'SHOW FULL PROCESSLIST;' | head -n 20
  3. Vérifier si cron est le passager

    Une liste en retard depuis longtemps signifie que les travaux programmés sont gérés par les visiteurs.

    wp cron event list --status=due --fields=hook,next_run_relative
  4. Déplacer le travail long hors de la demande

    La même importation que les heures dehors dans un navigateur complète généralement de la ligne de commande, parce que rien n'attend dessus.

    wp import large-file.xml --authors=create
  5. Seulement maintenant, considérez le délai

    Et le soulever pour le chemin qui en a besoin plutôt que partout.

    wp config set WP_MAX_MEMORY_LIMIT '512M'
Sur MagicWP

Ce que la plateforme prend en charge.

Les travaux programmés sont exécutés sur un véritable planificateur de système plutôt que sur le visiteur qui arrive, de sorte que la cause accidentelle la plus courante d'une page lente est absente dès le début. Les longs travaux ont leurs propres limites dans le contexte cron plutôt que d'emprunter celles destinées aux demandes web, et les conteneurs par site signifient une demande qui fonctionne longtemps occupe vos travailleurs seulement.

Questions fréquentes

Questions fréquentes.

Devrais-je augmenter le temps de congé ?
Rarement, et jamais en premier. Un temps d'arrêt plus élevé signifie que le visiteur attend plus longtemps avant de voir la même défaillance, et il enlève le plafond qui arrête une seule demande liant indéfiniment un travailleur.
Pourquoi la même page se charge bien parfois ?
Parce que l'ingrédient lent n'est pas toujours lent. Une API tierce ayant une mauvaise minute, ou une requête qui est bien jusqu'à ce que le cache soit froid, les deux produisent une page qui fonctionne jusqu'à ce qu'il ne fonctionne pas.
Mes importations sont exactement au même moment.
C'est une limite plutôt qu'une coïncidence. Exécutez-la du WP-CLI, ou en morceaux qui enregistrent leur position, donc une course interrompue reprend plutôt que de répéter.
Est-ce qu'un 504 est causé par le lien entre mes visiteurs?
Non. Il est généré entre le serveur web et PHP, tous deux du côté serveur. Un visiteur avec une connexion lente voit une page lente, pas une 504.
Erreurs associées

Si le problème vient d’ailleurs.

Ces erreurs peuvent se présenter de façon similaire dans le navigateur.