Cet article peut vous aider à résoudre les problèmes liés aux erreurs 504/502/gateway. Lors du dépannage, il peut être utile de comprendre comment fonctionne le traitement entre nginx et PHP, qui est souvent utilisé pour l'hébergement d'applications Web hautes performances, comme WordPress.
Erreurs courantes liées à cette configuration :
- 504 Délai d'expiration de la passerelle
- Délai d'expiration de la passerelle (504)
- Erreur HTTP 504 – Expiration de la passerelle
- Erreur d'expiration du délai de la passerelle
- 502 passerelle incorrecte
- Mauvaise passerelle
Pourquoi y a-t-il une passerelle ?
Lorsqu'une demande passe par un navigateur Web, elle atteint d'abord nginx, notre serveur Web frontal léger et nginx décide ensuite où la demande doit aller à partir de là, comme un conducteur de train. Nginx gère généralement lui-même les demandes de ressources plus simples (comme les images et les pages en cache), tout en envoyant des demandes de pages dynamiques (comme une page d'administration WordPress ou un panier d'achat) à apache (pour le traitement modsecurity et .htaccess), puis à PHP. Il ressemble à ceci :
nginx -> apache -> php -fpm
nginx agit comme une passerelle envoyant les bons types de requêtes à apache et PHP. S'il y a un problème "en aval", comme avec apache ou php, vous obtiendrez une passerelle erreur, comme 502 Bad Gateway ou 504 Gateway Timeout .
Ce problème peut être un code d'exécution extrêmement lent, ou un problème réel avec le service apache ou PHP, bien qu'avec notre hébergement, le problème soit le plus souvent un problème de code.
Utilisez les journaux du serveur pour obtenir plus d'informations
Pour aider à identifier la cause de l'erreur de passerelle, consultez les journaux pour voir ce qui est signalé. parfois, les journaux signaleront simplement une erreur 502 ou 504 - comme vous le voyez dans le navigateur - ce qui ne sera pas utile. Mais parfois, vous pouvez voir une erreur ou un avertissement enregistré juste avant l'erreur de passerelle qui identifiera le plug-in ou le thème à l'origine de l'erreur.
Vous pouvez apprendre à utiliser Plesk pour afficher les journaux ici. Si vous pouvez utiliser ces erreurs pour aller au fond du problème, alors faites-le définitivement ! Sinon, poursuivez votre lecture pour découvrir d'autres moyens d'affiner les choses.
Aider! Je ne peux même pas accéder à la zone d'administration de mon site ! (Comme wp-admin pour WordPress)
Parfois, lorsque vous recevez des erreurs de passerelle constantes, vous ne parvenez pas à accéder à la zone d'administration de votre site Web (comme wp-admin de WordPress), mais vous constatez que vous devez le faire pour aider à résoudre ce problème. La seule façon de retrouver l'accès est de bloquer l'accès jusqu'à ce que vous puissiez résoudre le problème.
Pour bloquer l'accès, vous pouvez procéder de l'une des deux manières suivantes :1) bloquer l'accès à la partie particulière du site qui consomme des ressources, ou 2) vous pouvez bloquer temporairement l'accès à toutes les adresses IP sauf la vôtre pour retrouver l'accès.
Pour bloquer l'accès à toutes les adresses IP sauf la vôtre (plus facile)
Connectez-vous à Plesk et accédez aux paramètres apache et nginx page. Sous "Refuser l'accès au site ” entrez une valeur personnalisée et faites-en "* " (sans les guillemets). Puis sous "Hors ” entrez votre propre adresse IP et enregistrez les modifications. Vous devrez peut-être attendre jusqu'à 3 minutes après avoir enregistré vos modifications pour que le serveur redémarre (~1 m) et que tous les processus PHP en cours d'exécution atteignent leur délai d'expiration (~2 m).
Assurez-vous de supprimer ce bloc lorsque vous avez terminé le dépannage.
Pour bloquer l'accès à la demande gourmande en ressources (plus complexe)
S'il n'y a qu'une seule page ou ressource sur le site qui crée ce problème (comme une seule page qui se charge lentement), utilisez les journaux pour identifier cet URI de requête particulier. Ajoutez ensuite l'extrait de code suivant en haut de votre fichier .htaccess pour bloquer la ressource problématique (même temporairement) afin que vous puissiez accéder au panneau d'administration. Remplacer filename\.php avec l'URI de requête réel affiché dans les journaux (il s'agit de la partie qui vient après le domaine). S'il y a des points dans le chemin du fichier, assurez-vous de les faire précéder d'une barre oblique inverse, comme indiqué dans l'exemple.
<FilesMatch filename\.php> Order Allow,Deny Deny from all </FilesMatch>
Raisons courantes des erreurs de passerelle
La solution rapide possible :
Si le problème n'était qu'un événement ponctuel (comme si vous exécutiez un script et qu'il ne s'arrêtait pas de s'exécuter), la solution consiste à redémarrer directement les services sous-jacents , ce qui force l'arrêt de ce script.
Si vous ne disposez pas d'un accès root au serveur ou d'un accès administrateur à Plesk, vous pouvez souvent déclencher un tel redémarrage en modifiant la configuration de votre site Web dans Plesk. Par exemple, essayez d'aller sur le bouton "Paramètres PHP" de votre domaine, puis d'y apporter une petite modification (comme augmenter la mémoire de 32 Mo à 48 Mo), puis enregistrez vos modifications. Cette mise à jour déclenche un redémarrage du traitement apache et PHP et pourrait résoudre votre erreur !
Cela peut prendre jusqu'à 3 minutes (ou plus selon votre fournisseur) pour que les modifications prennent effet.
Si cela ne suffit pas ou si le problème réapparaît, vous devrez passer en revue les causes/symptômes possibles suivants pour déterminer celui qui correspond le mieux à votre cas.
J'essaie d'exécuter une exportation, une importation ou un rapport volumineux qui prend un certain temps
Si votre site fonctionne normalement, mais que chaque fois que vous essayez d'exécuter une exportation, une importation ou un rapport volumineux pour les données de votre site, vous obtenez des erreurs de passerelle, c'est parce que vous atteignez des délais d'attente avant que le rapport puisse être traité. Bien qu'il n'y ait pas de moyen très simple de résoudre ce problème à long terme, il existe un moyen de le résoudre à court terme :augmenter temporairement les délais d'attente.
Vous pouvez le faire dans le panneau de configuration de Plesk en suivant les étapes de notre guide sur la façon de modifier un paramètre PHP. Vous devrez modifier les valeurs (elles sont en secondes) pour max_execution_time et max_input_time à quelque chose comme 300 pour permettre aux processus de s'exécuter pendant 5 minutes. N'oubliez pas de modifier ces valeurs après avoir terminé votre action de longue durée.
Pourquoi ne pouvez-vous pas simplement augmenter les délais d'attente de manière permanente ?
Techniquement, vous pouvez, mais l'augmentation permanente des délais d'attente affectera très probablement les performances de votre site . Les délais d'attente par défaut sont des valeurs telles que 30 ou 60 secondes avec intention :si un processus prend autant de temps à se terminer et que vous déclenchez trop de processus longs, ils peuvent monopoliser tous les créneaux de traitement disponibles et faire tomber l'ensemble de votre site pour tous les visiteurs. Par conséquent, conserver vos valeurs de délai d'attente autour de 30 à 60 secondes garantit que cela ne peut se produire que pendant au plus ce laps de temps.
Presque toutes les demandes adressées à mon site ou à ma page d'accueil prennent beaucoup de temps à traiter
Vous saurez si c'est le problème si une ou plusieurs pages du site mettent plus de 10 s pour commencer à se charger, votre navigateur n'affichant rien avant que cette période de 10 secondes ne se soit écoulée.
Cela peut se produire pour deux raisons courantes :
1) Problèmes de performances du code :vous avez du code en cours d'exécution sur le site qui n'est pas optimisé pour les performances ou qui rencontre un problème. Un exemple de ceci serait une boucle infinie dans le code, ou quelque chose qui essaie d'extraire des millions d'enregistrements de base de données en une seule requête (plutôt que de les récupérer par lots). La première chose à vérifier est tout code qui a été récemment ajouté au site, comme des plugins, un nouveau thème, un code personnalisé, etc. Vous voudrez probablement impliquer votre développeur pour aider à affiner cela. Nous avons un article de la base de connaissances avec certaines versions communément reconnues de cela, mais si vous n'êtes pas en mesure de déterminer la cause avec ces suggestions, votre option restante est un dépannage exhaustif. Nous avons un guide de dépannage exhaustif avec WordPress ici.
2) Demandes de ressources externes lentes ou ne répondant pas : Certains codes PHP tentent de communiquer avec une ressource externe (hébergée ailleurs) qui met trop de temps à répondre ou qui ne répond pas du tout. Pour résoudre les problèmes liés aux ressources externes, vous devez rechercher quelles parties du code PHP de votre site Web (code personnalisé ou plugins/code de thème) tentent de récupérer des ressources externes. Il s'agit le plus souvent d'un code qui se connecte à un service tiers comme un processeur de paiement ou la récupération de données météorologiques via une API ou un scraping. Voici quelques exemples :
- Certaines passerelles de paiement ou services d'API XML utilisent des ports non standard (bien que cela soit très rare de nos jours, car les ports standard sont désormais beaucoup plus fréquemment utilisés). S'il n'utilise pas le port 80 ou 443, il essaie probablement de communiquer sur un port bloqué et échoue.
- Les widgets Twitter plus anciens sont connus pour récupérer les tweets à l'aide de code back-end, puis les échecs de connexion aux serveurs Twitter provoquent des blocages comme celui-ci. Cela ne s'applique pas aux propres intégrations de flux de Twitter qui fonctionnent via Javascript de manière asynchrone.
Si vous utilisez WordPress ou tout autre CMS avec des plugins, assurez-vous d'essayer de désactiver tout plugin qui pourrait communiquer avec l'extérieur pour voir s'il résout le problème.
Si vous n'êtes pas en mesure de déterminer intuitivement quel plugin pourrait être en faute, votre option restante est un dépannage exhaustif. Nous avons un guide de dépannage exhaustif avec WordPress ici.
Cause :Trop de processus PHP nécessaires pour traiter les requêtes
Si votre nécessite beaucoup de processus PHP en raison d'une grande quantité de trafic créant des demandes de traitement dynamiques, votre objectif principal devrait être de réduire la quantité de traitement dynamique qui doit se produire à chaque chargement de page. Voici comment :
- Si vous utilisez WordPress, cliquez ici pour savoir comment installer et optimiser votre cache.
- Si la mise en cache est déjà activée, l'étape suivante consiste à détecter et à réduire les cas de traitement dynamique.
Cause :tampons limités
Les processus Apache ou PHP peuvent générer des tailles de données plus importantes que nginx est autorisé à traiter. Étant donné qu'apache et PHP ont tous deux besoin de transmettre ces données via nginx pour atteindre le visiteur du site Web, il génère une erreur 502 indiquant "En amont envoyé un en-tête trop gros". Nous avons vu cette erreur avec des clients utilisant le plugin WordPress OptInMonster, mais n'importe quel logiciel pourrait le faire.
Notre hébergement partagé devrait déjà être optimisé avec des tampons plus grands pour nginx, cependant si vous avez votre propre VPS, ou n'êtes pas hébergé chez nous, vous devrez appliquer vous-même ces valeurs à la configuration nginx :
fastcgi_buffers 128 4096k; fastcgi_buffer_size 4096k;
Cela indique à nginx qu'il peut accepter des en-têtes volumineux (4 Mo). Vous pouvez les insérer dans un fichier comme :/etc/nginx/conf.d/increase_buffers.conf puis redémarrez nginx pour appliquer les modifications. Exemple :
echo 'fastcgi_buffers 128 4096k; fastcgi_buffer_size 4096k;' > /etc/nginx/conf.d/increase_buffers.conf
Cause :PHP-FPM mal configuré ou nécessite un réglage (VPS/serveur dédié uniquement)
Parfois, si vous obtenez des erreurs constantes de délai d'expiration de la passerelle et que la seule chose qui les efface est le redémarrage de PHP (comme décrit ci-dessus), ou si vous êtes sur un VPS et que vous voyez vos processus PHP continuer à fonctionner à haute CPU et durer longtemps plus longtemps qu'ils ne le devraient (ou les techniciens du serveur vous ont dit que c'est ce qui se passe), vous devrez prendre certaines mesures pour les maîtriser.
Remarque :si vous utilisez notre hébergement mutualisé, notre configuration PHP-FPM est déjà optimisée pour un environnement d'hébergement mutualisé. Par conséquent, si vous rencontrez des erreurs de passerelle, cette solution ne s'appliquera pas.
Voici quelques options qui ont fonctionné pour nous, mais il est très important de noter que ce sont des solutions de contournement au vrai problème. Identifier le code qui ne répond pas assez vite et optimiser ses performances est la vraie solution.
- PHP-FPM vous permet d'ajuster le gestionnaire de processus PHP (FastCGI Process Manager =FPM) en apportant quelques modifications dans Plesk. Si vous utilisez le processus PHP-FPM de style "à la demande", vous souhaiterez peut-être réduire le nombre de requêtes que chaque processus gère avant de quitter/redémarrer correctement un nouveau processus. Ceci est étiqueté comme pm.max_requests. Essayez 100 ou 150 si vous rencontrez des problèmes de performances
- Si vos processus PHP ne meurent pas, vous devrez peut-être les *faire* mourir. Il y a quelques bonnes façons de le faire. La première consiste à définir définitivement un délai d'inactivité pour les processus PHP-FPM en définissant pm.process_idle_timeout – essayez de le régler sur 10s (vous pouvez le faire dans le champ sous les paramètres FPM.
- Si votre PHP traite toujours ne meurent pas, vous devrez peut-être devenir encore plus agressif avec eux. Essayez de définir request_terminate_timeout à quelques secondes de plus que votre paramètre max_execution_time. Si max_execution_time ne tue pas le processus, request_terminate_timeout le fera certainement.
Si vous avez trouvé ce guide utile, consultez les autres guides et publications disponibles. Si vous avez besoin d'un hébergeur Web ou d'un partenaire d'hébergement VPS canadien performant, consultez nos services !