nginx 502 mauvaise passerelle

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é:

  1. Modifier /etc/php5/fpm/pool.d/www.conf
  2. Change listen = /var/run/php5-fpm.sock à listen = 127.0.0.1:9000
  3. Assurez-vous que l’emplacement est correctement défini dans nginx.conf .
  4. Exécuter 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.