Je reçois un 502 Bad Gateway avec nginx lors de l’utilisation de spawn fcgi pour engendrer php5-cgi.
J’utilise ceci pour étendre une instance sur le serveur en utilisant la ligne suivante dans rc.local
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid
Je suppose que j’obtiens l’erreur car le spawn-fcgi / php5-cgi meurt et il n’y a plus d’écoute pour parsingr PHP.
Je ne vois rien dans les journaux que je puisse voir nulle part, je suis à court d’idées (et de nouveautés pour cette configuration avec nginx)
J’ai exécuté mon localhost
et la page affiche le message 502 bad gateway
. Cela m’a aidé:
/etc/php5/fpm/pool.d/www.conf
listen = /var/run/php5-fpm.sock
à listen = 127.0.0.1:9000
sudo service php5-fpm restart
Peut-être que cela vous aidera.
Source de: http://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm
L’erreur 502 apparaît car nginx ne peut pas passer à php5-cgi. Vous pouvez essayer de reconfigurer php5-cgi pour utiliser des sockets unix par opposition à tcp .. puis ajustez la configuration du serveur pour pointer vers le socket au lieu du tcp …
ps auxww | grep php5-cgi #-- is the process running? netstat -an | grep 9000 # is the port open?
Allez dans /etc/php5/fpm/pool.d/www.conf
et si vous utilisez des sockets ou si cette ligne n’est pas commentée
listen = /var/run/php5-fpm.sock
Définissez également deux autres valeurs: –
listen.owner = www-data listen.group = www-data listen.mode = 0660
N’oubliez pas de redémarrer php-fpm et nginx. Assurez-vous d’utiliser le même nom de propriétaire et de groupe nginx.
Vous devez faire correspondre les parameters de PHP-FPM et de Nginx pour communiquer sur des sockets ou TCP.
Alors allez sur /etc/php5/fpm/pool.d/www.conf
et cherchez cette ligne:
listen = /var/run/php5-fpm.sock
Ensuite, allez dans /etc/nginx/nginx.conf
Cherchez ceci:
upstream php { server unix:/var/run/php5-fpm.socket; }
Faites correspondre ces valeurs et vous devriez être tous ensemble.
Si vous utilisez un serveur Linux, assurez-vous que votre configuration IPTABLES est correcte.
Exécutez sudo iptables -L -n
, vous recevrez une liste de vos ports ouverts. S’il n’y a pas de règle Iptables pour ouvrir le port servant au script fcgi, vous recevrez une erreur 502. La règle Iptables qui ouvre le port correct doit être répertoriée avant toute règle qui rejette catégoriquement tous les paquets (c’est-à-dire une règle de la forme "REJECT ALL -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
ou similaire)
Sur ma configuration, pour ouvrir correctement le port, je devais exécuter cette commande (supposons que mon serveur fcgi s’exécute sur le port 4567):
sudo iptables -I INPUT 1 -p tcp --dport 4567 -j ACCEPT
ATTENTION: Cela ouvrira le port 4567 au monde entier.
Donc, il serait peut-être préférable de faire quelque chose comme ceci:
sudo iptables-save >> backup.iptables sudo iptables -D INPUT 1 #Delete the previously entered rule sudo iptables -I INPUT 1 -p tcp --dport 8080 -s localhost -j ACCEPT # Add new rule
Faire cela a supprimé l’erreur 502 pour moi.
changement
fastcgi_pass unix:/var/run/php-fpm.sock;
à
fastcgi_pass unix:/var/run/php5-fpm.sock;
Quand j’ai fait sudo /etc/init.d/php-fpm start
j’ai eu l’erreur suivante:
Starting php-fpm: [28-Mar-2013 16:18:16] ERROR: [pool www] cannot get uid for user 'apache'
Je suppose que /etc/php-fpm.d/www.conf
besoin de savoir que le serveur Web est exécuté et suppose qu’il est apache lorsque, pour nginx, il est réellement modifié et doit être modifié.
J’ai eu le même problème lors de la configuration d’un serveur Ubuntu. Il s’avère que j’avais le problème en raison des permissions incorrectes sur le fichier de socket.
Si vous rencontrez le problème à cause d’un problème de permission, vous pouvez annuler le commentaire des lignes suivantes à partir de: /etc/php5/fpm/pool.d/www.conf
listen.owner = www-data listen.group = www-data listen.mode = 0660
Bien que je ne le recommande pas, vous pouvez également accorder des permissions de lecture et d’écriture à tous les groupes à l’aide de la commande suivante.
sudo chmod go+rw /var/run/php5-fpm.sock
Vous pouvez faire en sorte que nginx ignore les avortements de clients en utilisant:
location / { proxy_ignore_client_abort on; }
Essayez de désactiver les modules xcache ou apc. Semble causer un problème avec certaines versions: enregistrer des objects dans une variable de session.
J’espère que cette astuce sauvera la vie de quelqu’un d’autre. Dans mon cas, le problème était que je manquais de mémoire, mais seulement légèrement, il était difficile d’y penser. 3 heures après ça. Je recommande de courir:
sudo htop
ou
sudo free -m
… avec des requêtes problématiques sur le serveur pour voir si votre mémoire n’est pas épuisée. Et si c’est le cas dans mon cas, vous devez créer un fichier d’échange (sauf si vous en avez déjà un).
J’ai suivi ce tutoriel pour créer un fichier d’échange sur Ubuntu Server 14.04 et cela fonctionnait très bien: http://www.cyberciti.biz/faq/ubuntu-linux-create-add-swap-file/
Si vous êtes sur Ubuntu et que tout ce qui précède vous a échoué, AppArmor est probablement responsable.
Voici un bon guide pour y remédier: https://www.digitalocean.com/community/tutorials/how-to-create-an-apparmor-profile-for-nginx-on-ubuntu-14-04
Longue histoire courte:
vi /etc/apparmor.d/nginx
Ou
sudo aa-complain nginx sudo service nginx restart
Voir tout fonctionne bien … alors
sudo aa-logprof
J’avais toujours des problèmes avec le fait que Nginx ne soit pas capable de lire error.log, même s’il avait toutes les permissions possibles, y compris dans Apparomor. Je suppose que cela a quelque chose à voir avec l’ordre des entrées, ou une interaction avec Passenger ou PHP-Fpm … Je n’ai plus de temps pour résoudre ce problème et je suis revenu à Apache pour le moment. (Apache fonctionne beaucoup mieux que FYI.)
AppArmor permet simplement à Nginx de faire ce qu’il veut si vous supprimez simplement le profil:
rm /etc/apparmor.d/nginx service apparmor reload
Étonnamment, mais guère surprenant, de nombreux articles sur la correction des erreurs Nginx ont recours à la désactivation complète de SELinux ou à la suppression d’AppArmor. C’est une mauvaise idée car vous perdez la protection de beaucoup de logiciels. La simple suppression du profil Nginx est un meilleur moyen de dépanner vos fichiers de configuration. Une fois que vous savez que le problème ne se trouve pas dans vos fichiers de configuration Nginx, vous pouvez prendre le temps de créer un profil AppArmor approprié.
Sans profil AppArmor, surtout si vous exécutez quelque chose comme Passenger, je donne environ un mois à votre serveur pour obtenir une porte dérobée.
Configuration similaire ici et ressemble à un bug dans mon code. Au début de mon application, j’ai recherché l’URL incriminée et cela a fonctionné: echo 'test'; exit();
echo 'test'; exit();
Dans mon cas, il s’avère que le problème était une variable non initialisée qui n’a échoué que dans des circonstances particulières.