Nginx ou Apache ? Guide de dépannage exclusif pour les erreurs 502 dans différents environnements de serveur

introductif

Lorsque vous rencontrez dans votre navigateur le symbole "502 Mauvaise passerelle"Cela signifie généralement qu'il y a eu une défaillance dans les communications internes du serveur web. Dans le cas d'uneWordPressEn ce qui concerne les utilisateurs, le site web fonctionne principalement surNginxpeut-êtreApachel'environnement. Bien que les deux types d'erreurs 502 puissent se produire, la cause première et les méthodes de dépannage varient. Cet article servira de guide de diagnostic précis pour la résolution des problèmes en fonction du logiciel serveur utilisé pour rétablir rapidement l'accès à votre site web.

Chapitre 1 : Comprendre la nature commune des erreurs 502

Avant de nous pencher sur les différences, nous devons d'abord établir une perception uniforme : qu'est-ce qu'une erreur 502 Bad Gateway ?

Par sa nature même, une erreur 502 est uneHTTPUn code d'état qui indique que le serveur agissant en tant que passerelle ou proxy (c'est-à-dire le serveur web qui fait directement face à l'utilisateur) a reçu une réponse invalide du serveur en amont (c'est-à-dire le service back-end qui gère réellement la logique de l'application). En d'autres termes, lorsqu'un utilisateur visite votre site WordPress, la requête arrive d'abord à Nginx ou Apache.

Ensuite, ce serveur web doit transmettre la requête au processus qui gère PHP (le plus souvent PHP-FPM) pour exécuter le code du noyau, des thèmes et des plugins de WordPress. Si ce processus de transmission échoue, ou si PHP-FPM ne renvoie aucun contenu valide, le serveur web envoie une erreur 502 à l'utilisateur.

Ainsi, qu'il s'agisse de Nginx ou d'Apache, ils jouent tous deux le même rôle :intermédiaire de communicationLe problème est que cet "intermédiaire" n'est pas le même que le "travailleur" du back-end (le "travailleur"). Le problème est que cet "intermédiaire" et le "travailleur" du back-end (le "travailleur") sont les mêmes.PHP-FPM) a une approche différente du dialogue.

Chapitre 2 : Dépannage de l'erreur 502 dans un environnement Nginx

Nginx est connu pour ses hautes performances et son architecture événementielle. Lorsqu'il communique avec PHP-FPM, il le fait généralement par le biais d'un protocole spécifique (FastCGI) à effectuer. Comprendre cela est la clé d'un dépannage réussi.

2.1 Examen du journal d'erreurs de Nginx pour trouver les premiers indices

Le journal des erreurs de Nginx est le point de départ de l'investigation. L'emplacement des journaux varie d'un système à l'autre, mais les chemins les plus courants sont les suivants /var/log/nginx/error.log. L'examen de ce fichier, en particulier des enregistrements proches du moment où l'erreur s'est produite, est une première étape cruciale.

Les entrées les plus courantes dans les journaux de Nginx concernant les erreurs 502 sont les suivantes :

• connecter() failed : Cela signifie que Nginx n'a pas pu se connecter au pool de processus PHP-FPM spécifié dans la configuration.
• Scénario primaire inconnu: Cela signifie que Nginx n'a pas été en mesure de trouver ou d'exécuter le script PHP spécifié (par ex.index.php).

2.2 Examen approfondi du message "connect() failed".

Lorsque les journaux indiquent des erreurs d'échec de connexion, le cœur du problème est que la connexion physique entre Nginx et PHP-FPM n'a pas pu être établie.

2.2.1 Vérification du statut du pool de processus de PHP-FPM

Le service PHP-FPM peut ne pas fonctionner ou s'être arrêté. Son état peut être vérifié à l'aide de la commande suivante :

sudo systemctl status php-fpm # Pour les systèmes utilisant systemctl
# ou
sudo service php-fpm status

Si le service n'est pas en cours d'exécution, essayez de le démarrer :sudo systemctl start php-fpm. Si le démarrage échoue, ou si le service se bloque de manière répétée, vous devez vérifier la configuration et les journaux de PHP-FPM lui-même.

2.2.2 Confirmation des méthodes et de l'autorité de communication

Nginx et PHP-FPM peuvent communiquer de deux manières principales :Socket Unix peut-être Socket TCP/IP.

• Vérification des sockets Unix : Si votre configuration Nginx utilise quelque chose comme fastcgi_pass unix:/var/run/php/php-fpm.sock ; des instructions qui doivent être vérifiées :
  • Si ce fichier de socket existe :ls -l /var/run/php/php-fpm.sock
  • L'utilisateur qui exécute le processus Nginx (généralement l'utilisateurwww-datapeut-êtrenginx) s'il a la permission de lire et d'écrire dans le fichier de la socket. Les erreurs de permission sont une cause fréquente d'échec de la connexion.
• Vérification des sockets TCP/IP : S'il est configuré comme fastcgi_pass 127.0.0.1:9000 ;doit être vérifié :
  • Si PHP-FPM écoute sur le port :netstat -tulpn | grep 9000
  • Si le pare-feu du système bloque la communication sur ce port à l'adresse de bouclage locale (127.0.0.1).

2.3 Épuisement des ressources et blocage des processus

Une autre raison fréquente pour laquelle Nginx renvoie 502 est que le processus enfant PHP-FPM s'arrête pendant le traitement de la requête ou se termine en raison d'un manque de ressources.

• Vérifiez les paramètres de ressources de PHP-FPM : Editez le fichier de configuration du pool de processus de PHP-FPM (généralement situé dans le répertoire/etc/php/7.x/fpm/pool.d/www.conf(le numéro de version peut être différent), faites attention aux paramètres suivants :
  • pm.max_childrenSi le nombre de demandes simultanées dépasse cette valeur, les nouvelles demandes seront rejetées, ce qui entraînera un message 502.
  • délai_de_termination_de_la_demandeSi le temps de traitement d'une seule requête PHP dépasse ce délai, le processus sera forcé de se terminer, ce qui entraînera probablement une erreur 502. Il est possible d'augmenter cette valeur de manière appropriée, mais il est plus important d'optimiser les scripts ou les requêtes qui prennent trop de temps à s'exécuter.

Chapitre 3 : Résolution des erreurs de l'environnement Apache 502

Apache utilise généralementmod_phpou par le biais du modulemod_proxy_fcgicombiné à PHP-FPM pour gérer les requêtes PHP. Cette dernière solution (Apache + PHP-FPM) devient de plus en plus courante dans les déploiements modernes, et notre dépannage se concentrera également sur ce point.

3.1 Analyse des journaux d'erreurs d'Apache

Comme pour Nginx, le journal des erreurs d'Apache est la principale source d'information. Les chemins d'accès les plus courants sont les suivants /var/log/apache2/error.log peut-être /var/log/httpd/error_log.

Dans les journaux d'Apache, vous pouvez voir des entrées concernant des erreurs de proxy, car elles sont généralement signalées par le biais de la fonctionmod_proxycommunique avec PHP-FPM.

3.2 Configuration du module Proxy et problèmes de permissions

Lorsque Apache est utilisé comme proxy pour communiquer avec PHP-FPM, la configuration est sensiblement différente de celle de Nginx.

3.2.1 Vérification des modules mod_proxy et mod_proxy_fcgi

Assurez-vous que les modules Apache nécessaires sont activés. Cela peut être vérifié à l'aide de la commande suivante :

sudo a2enmod proxy_fcgi # sur les systèmes Debian/Ubuntu
# ou regarder la sortie de httpd -M

3.2.2 Examen de la configuration de l'hôte virtuel

Apache définit généralement la manière de transmettre les requêtes PHP à PHP-FPM dans son fichier de configuration de l'hébergement web. Un extrait de configuration typique peut ressembler à ceci :

SetHandler "proxy:fcgi://127.0.0.1:9000"
    # ou utiliser la socket Unix : SetHandler "proxy:unix:/var/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch

Confirmation requise :

• SetHandlerLe chemin de la directive (soit le chemin IP:Port ou Unix Socket) est exactement le même que l'adresse d'écoute de PHP-FPM.
• Si l'on utilise un socket Unix, l'utilisateur du runtime Apache (typiquement l'utilisateurwww-datapeut-êtreapache) doit avoir les droits de lecture et d'écriture sur ce fichier socket.

3.3 Conflits de modules et contraintes de ressources

Les conflits de modules sont un problème qui nécessite une attention particulière dans l'environnement Apache.

• Éviter les conflits entre les gestionnaires de modules : Si les deux chargésmod_php(traitement à l'ancienne) etmod_proxy_fcgi(traitement moderne), et mal configurés, ils peuvent entrer en compétition pour les droits de traitement sur les fichiers PHP, conduisant à des comportements imprévisibles, y compris des erreurs 502. Après avoir configuré PHP-FPM, vous devez généralement désactiver l'optionmod_phpou s'assurer qu'il n'interfère pas avec la nouvelle configuration de l'agent.
• Ajuster les limites de ressources d'Apache et de PHP : ApacheDélai d'attenteet la directivetemps_d'exécution_maxpeuvent affecter les scripts de longue durée. De la même manière, les paramètres de ressources de PHP-FPM (tels que l'optionpm.max_children) s'applique également à cet environnement et doit être raisonnablement adapté à la charge du serveur.

Chapitre 4 : Mesures de dépannage et de prévention communes à toutes les plateformes

Bien que Nginx et Apache soient configurés différemment, certaines étapes de dépannage sont universellement applicables car elles ciblent un amont commun - PHP-FPM et WordPress lui-même.

4.1 Diagnostiquer l'état de santé de PHP-FPM

Quel que soit le type de serveur web sur le front-end, l'état de PHP-FPM est déterminant.

• Redémarrez le service PHP-FPM : Pour une récupération rapide, redémarrer PHP-FPM peut éliminer les processus morts ou les fuites de mémoire qui peuvent exister. Des commandes telles que :sudo systemctl restart php-fpm.
• Analyser les journaux de PHP-FPM : PHP-FPM a son propre fichier journal (dans le fichier de configuration du pool).sortie_capture_travailleursrépondre en chantantphp_admin_flag[log_errors]). L'affichage de ces journaux peut fournir des informations précieuses sur la raison exacte de l'échec d'un script PHP, comme l'épuisement de la mémoire, le dépassement du délai d'exécution ou l'erreur fatale.

4.2 Dépannage des conflits liés aux thèmes et aux plugins WordPress

Les plugins ou thèmes WordPress défectueux sont souvent à l'origine de l'interruption du processus PHP.

• Entrez dans le mode de dépannage : Accédez aux fichiers de votre site web via FTP ou SSH.
• Renommer le répertoire du plugin : commandant en chef (militaire)wp-content/pluginsRenommer le répertoire enplugins.désactivés. Tous les plugins seront alors désactivés.
• Consultez le site web : Rafraîchissez le frontend de votre site. Si l'erreur 502 disparaît, cela signifie que le problème est causé par l'un des plugins. Vous pouvez réactiver les plugins un par un jusqu'à ce que vous trouviez celui qui est à l'origine du problème.
• Sujet à bascule : Si le problème n'est pas lié au plugin, essayez de remplacer le thème actif par le thème par défaut de WordPress (par exemple, Twenty Twenty-Four) afin d'exclure tout problème de compatibilité entre les thèmes.

résumés

L'erreur 502 Bad Gateway, bien qu'ennuyeuse, n'est pas introuvable. Pour les utilisateurs de Nginx, le dépannage doit se concentrer sur les connexions FastCGI à PHP-FPM, les permissions des fichiers socket et les limites de ressources des processus. Pour les utilisateurs d'Apache, vous devez examiner attentivement le fichiermod_proxy_fcgila configuration de l'agent, les problèmes de conflit de modules et les autorisations de fichiers associées.

La maîtrise de ce processus de diagnostic ciblé vous permettra de rester calme la prochaine fois que vous serez confronté à une erreur 502, de localiser les lésions et de mettre en œuvre les correctifs comme un médecin système expérimenté, pour finalement restaurer la santé et la vitalité de votre site WordPress.

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : [email protected]
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.