Comment résoudre l'erreur nginx 502 Bad Gateway

nginx 502 conditions de déclenchement

L'occurrence la plus courante des erreurs 502 est lorsque l'hôte backend plante. Il existe une telle configuration dans la configuration en amont : proxy_next_upstream. Cette configuration spécifie le type d'erreurs que nginx rencontre lors de la récupération des données à partir d'un hôte back-end. Il ira à l'hôte back-end suivant. 502 qui apparaîtront. Selon la situation, la valeur par défaut est le délai d'attente d'erreur. L'erreur fait référence aux plantages, aux déconnexions, etc. Le délai d'attente fait référence au délai d'attente de blocage de lecture, qui est plus facile à comprendre. Je l'écris généralement en entier :

proxy_next_upstream error timeout invalid_header http_500 http_503; Mais maintenant, je devrai peut-être supprimer l'élément http_500 qui spécifie que lorsque le backend renvoie une erreur 500, il sera transféré vers un hôte. . Le backend S'il y a une erreur dans jsp, un tas de messages d'erreur stacktrace seront imprimés, mais ils sont maintenant remplacés par 502. Mais les programmeurs de l'entreprise ne le pensent pas. Ils pensent qu'il y a une erreur dans nginx. Je n'ai vraiment pas le temps de leur expliquer le principe du 502...

503 des erreurs peuvent être. conservé car le backend est généralement Apache Resin, si Apache plante, ce sera une erreur, mais si Resin plante, ce ne sera que 503, il faut donc quand même le conserver.

Solution

Si vous rencontrez un problème 502, vous pouvez en priorité suivre les deux étapes suivantes pour le résoudre.

1. Vérifiez si le nombre actuel de processus php fastcgi est suffisant :

Copiez le code Le code est le suivant :

netstat -anpo | grep "php- cgi" | wc -l

Si le "nombre de processus fastcgi" réel utilisé est proche du "nombre de processus fastcgi" prédéfini, cela signifie que le Le "nombre de processus fastcgi" n'est pas suffisant et doit être augmenté considérablement.

2. Le temps d'exécution de certains programmes PHP dépasse le temps d'attente de nginx Vous pouvez augmenter de manière appropriée le délai d'attente de fastcgi dans le fichier de configuration nginx.conf, par exemple :

#🎜. 🎜#Copier le code Code comme suit :

http {

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......# 🎜🎜# }#🎜 🎜# ......


Si la limite de mémoire dans php.ini est basse, une erreur se produira. J'ai modifié la limite de mémoire dans php.ini. à 64 m, j'ai redémarré nginx et j'ai constaté que tout allait bien. Il s'est avéré que PHP manquait de mémoire.

　

Si cette modification ne parvient toujours pas à résoudre le problème, vous pouvez vous référer aux solutions suivantes :

1. #🎜 🎜# Un serveur exécute nginx php (fpm) xcache, avec un volume de visites quotidien moyen d'environ 300w pv.

Récemment, cette situation se produit souvent : la page PHP s'ouvre très lentement, l'utilisation du processeur tombe soudainement à un niveau très bas, la charge du système monte soudainement à un niveau très élevé, et si vous vérifiez le trafic de la carte réseau, vous constaterez également qu'elle est soudainement tombée à Très bas. Cette condition ne dure que quelques secondes avant de revenir.

La vérification du fichier journal de php-fpm a trouvé quelques indices.

Copier le code Le code est le suivant :

sep 30 08:32:23.289973 [avis] fpm_unix_init_main(), ligne 271 : getrlimit(nofile): max:51200, cur:51200 30 septembre 08:32:23.290212 [avis] fpm_sockets_init_main(), ligne 371 : utilisation du socket hérité fd=10, « 127.0.0.1:9000″ 30 septembre 08:32:23.290342 [avis] fpm_event_init_main(), ligne 109 : libevent: using epoll sep 30 08:32:23.296426 [notice] fpm_init(), ligne 47 : fpm is running, pid 30587　

Devant ces phrases, il y a plus de 1 000 lignes de fermeture des enfants et activation du journal des enfants.

Il s'avère que php-fpm a un paramètre max_requests, qui spécifie le nombre maximum de requêtes que chaque enfant peut traiter avant d'être fermé. Le paramètre par défaut est 500. Étant donné que PHP interroge les requêtes de chaque enfant, en cas de trafic intense, chaque enfant met à peu près le même temps pour atteindre max_requests, ce qui entraîne la fermeture de tous les enfants pratiquement en même temps.

Pendant cette période, nginx ne peut pas transférer le fichier php vers php-fpm pour le traitement, donc le processeur tombera à un niveau très bas (pas besoin de traiter php, encore moins d'exécuter sql), et le la charge atteindra un niveau très élevé (Fermer et activer les enfants, nginx attend php-fpm), et le trafic de la carte réseau sera également réduit à très faible (nginx ne peut pas générer de données et les transmettre au client)

# 🎜🎜# La solution au problème est très simple, augmentez le nombre d'enfants et définissez max_requests Définissez une valeur inférieure à 0 ou une valeur relativement grande :

Ouvrir /usr/local/php/etc/php -fpm.conf et augmentez les deux paramètres suivants (selon la situation réelle du serveur, trop grand ne fonctionnera pas)

Copier le code Le code est le suivant :

5120

600　

Puis redémarrez php- fpm.

2. Augmentez la capacité du tampon

Ouvrez le journal des erreurs nginx et recherchez un message d'erreur du type "pstream a envoyé un en-tête trop gros lors de la lecture de l'en-tête de réponse depuis l'amont". Après vérification des informations, l'idée générale est qu'il y a un bug dans le tampon nginx. Le tampon occupé par la consommation des pages de notre site web est peut-être trop volumineux. En référence à la méthode de modification écrite par des étrangers, le paramètre de capacité tampon est augmenté et le problème 502 est complètement résolu. Plus tard, l'administrateur système a ajusté les paramètres et n'a conservé que deux paramètres de configuration : le tampon principal du client et la taille du tampon fastcgi.

3. request_terminate_timeout

　Si 502 se produit principalement lors de certaines publications ou opérations de base de données, plutôt que commun dans les opérations de page statique, alors vous pouvez vérifier l'un des paramètres de php-fpm.conf :

request_terminate_timeout

Cette valeur est max_execution_time est le temps d'exécution du script de fast -cgi.

0s

0s est fermé, ce qui signifie qu'il continuera à s'exécuter indéfiniment. (J'ai changé un numéro sans bien regarder lors de l'installation) Le problème est résolu et l'exécution sera sans erreur pendant longtemps. En optimisant fastcgi, vous pouvez également modifier cette valeur pendant 5 secondes pour voir l'effet.

Si le nombre de processus php-cgi n'est pas suffisant, que le temps d'exécution de php est long ou que le processus php-cgi s'arrête, une erreur 502 se produira.

Solution d'erreur de passerelle incorrecte nginx 502 2

Aujourd'hui, mon vps a fréquemment provoqué une erreur de passerelle nginx 502 incorrecte. Après avoir redémarré le vps, elle est réapparue, ce qui était très ennuyeux. Je suis un peu confus. Le site Web a reçu 1 290 visites sans aucun problème au cours des deux derniers jours. Pourquoi une mauvaise passerelle 502 est-elle apparue cette fois-ci ? Déprimant! ! ! Après de longues recherches, j'ai finalement trouvé beaucoup de réponses pertinentes. J'espère que cette erreur ne se reproduira plus après modification. Hélas, comme je cherche des réponses sur Internet depuis si longtemps, je dois bien sûr enregistrer les choses utiles pour ne pas avoir à retourner sur Google la prochaine fois~

Depuis que j'utilise le lnmp en un clic paquet d'installation, s'il y a un problème, je dois venir en premier. J'ai cherché sur le forum officiel, c'est génial. Il y a un message officiel épinglé comme celui-ci.

Officiel du package d'installation en un clic lnmp :

La première raison : Actuellement, le problème le plus courant avec le package d'installation en un clic lnmp est 502 mauvaise passerelle. Dans la plupart des cas, la raison est qu'avant d'installer php, certains packages lib dans. le script peut ne pas être installé, ce qui fait que php n'est pas compilé et installé correctement.
Solution : vous pouvez essayer de l'installer manuellement selon le script contenu dans le package d'installation en un clic lnmp pour voir la cause de l'erreur.

La deuxième raison :

Dans php.ini, l'élément de configuration eaccelerator doit être placé avant la configuration de l'optimiseur zend, sinon cela peut également provoquer une mauvaise passerelle 502

La troisième raison :

Apparaît lors de l'installation et de l'utilisation Le problème 502 est généralement dû au fait que le processus php-cgi par défaut est 5. Le 502 peut être dû à des processus phpcgi insuffisants. Vous devez modifier /usr/local/php/etc/php-fpm.conf pour augmenter la valeur max_children de manière appropriée.

Quatrième raison :

Délai d'exécution de PHP, modifiez /usr/local/php/etc/php.ini pour changer max_execution_time à 300

Cinquième raison :

Espace disque insuffisant, tel qu'un journal MySQL occupant beaucoup d'espace

La sixième raison :

Vérifiez si le processus php-cgi est en cours d'exécution

Certains internautes ont également donné une autre solution :

nginx 502 bad gateway signifie que le php-cgi demandé a été exécuté, mais pour une raison quelconque La raison (généralement un problème de lecture des ressources) est que le processus php-cgi est terminé car l'exécution n'est pas terminée. De manière générale, la mauvaise passerelle nginx 502 est liée aux paramètres de php-fpm.conf.

php-fpm.conf a deux paramètres cruciaux, l'un est max_children et l'autre est request_terminate_timeout, mais cette valeur n'est pas universelle et doit être calculée par vous-même.
Un problème 502 survient lors de l'installation et de l'utilisation. Généralement, c'est parce que le processus php-cgi par défaut est 5. Cela peut être dû à des processus phpcgi insuffisants. Vous devez modifier /usr/local/php/etc/php-fpm. conf. La valeur max_children est augmentée de manière appropriée.

La méthode de calcul est la suivante :

Si les performances de votre serveur sont suffisamment bonnes, que les ressources haut débit sont suffisantes et qu'il n'y a pas de boucles ou de bugs dans le script php, vous pouvez directement définir request_terminate_timeout sur 0s. La signification des 0 est de laisser php-cgi continuer à s'exécuter sans limite de temps. Et si vous n'y parvenez pas, c'est-à-dire que votre php-cgi a peut-être un bug, ou que votre bande passante n'est pas suffisante, ou que d'autres raisons provoquent le blocage de votre php-cgi, alors il est recommandé d'attribuer une valeur à request_terminate_timeout. Cette valeur peut être définie en fonction des performances du serveur. De manière générale, plus les performances sont bonnes, plus vous pouvez les régler à un niveau élevé, entre 20 et 30 minutes.
Et comment est calculée la valeur de max_children ? En principe, plus la valeur est grande, mieux c'est. S'il y a plus de processus php-cgi, ils seront traités rapidement et il y aura moins de requêtes en file d'attente. Le paramètre max_children doit également être défini en fonction des performances du serveur. De manière générale, la mémoire consommée par chaque php-cgi sur un serveur est d'environ 20 min dans des circonstances normales.

Selon les réponses officielles, nous avons vérifié les possibilités associées, et combinées avec les réponses des internautes, nous avons trouvé les solutions suivantes.

1. Vérifiez le nombre de processus de php fastcgi (valeur max_children)

Code : netstat -anpo | grep "php-cgi" | wc -l

5 (si 5 est affiché)

2. process

Code :top
Observez le nombre de processus fastcgi. Si le nombre de processus utilisés est égal ou supérieur à 5, cela signifie qu'il doit être augmenté (en fonction de la situation réelle de votre machine)

3. Ajustez les paramètres liés à /usr/local/php/etc/php-fpm. conf

10
60s
max_children peut avoir jusqu'à 10 processus, avec 20 Mo de mémoire par processus, jusqu'à 200 Mo.
Le temps d'exécution de request_terminate_timeout est de 60 secondes, soit 1 minute.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!