Je mets à jour nginx en 1.4.7 et php en 5.5.12 , après cela, j'ai eu l' erreur 502 . Avant de mettre à jour, tout fonctionne bien.

nginx-error.log

2014/05/03 13:27:41 [crit] 4202#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xx.xx, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xx.xx.xx.xx"

nginx.conf

user  www www;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

J'ai eu une erreur similaire après la mise à jour php. PHP a corrigé un bogue de sécurité où oavait l' rwautorisation sur le fichier socket.

1. Ouvrez /etc/php5/fpm/pool.d/www.confou /etc/php/7.0/fpm/pool.d/www.conf, selon votre version.

2. Décommentez toutes les lignes d'autorisation, comme:

   listen.owner = www-data
   listen.group = www-data
   listen.mode = 0660

3. Redémarrez fpm - sudo service php5-fpm restartousudo service php7.0-fpm restart

Remarque : si votre serveur Web fonctionne en tant qu'utilisateur autre que www-data, vous devrez mettre à jour le www.conffichier en conséquence

Tous les correctifs actuellement mentionnés ici activent à nouveau le trou de sécurité.

J'ai fini par ajouter les lignes suivantes à mon fichier de configuration PHP-FPM.

listen.owner = www-data
listen.group = www-data

Assurez-vous que www-data est bien l'utilisateur sous lequel s'exécute le travailleur nginx. Pour Debian, c'est www-data par défaut.

Le faire de cette façon n'active pas le problème de sécurité que cette modification était censée résoudre .

La solution de @ Xander fonctionne, mais ne persiste pas après un redémarrage.

Je trouve que je devais changer listen.modeà 0660en /etc/php5/fpm/pool.d/www.conf.

Exemple de www.conf:

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions. 
; Default Values: user and group are set as the running user
;                 mode is set to 0660
;listen.owner = www-data
;listen.group = www-data
;listen.mode = 0660

Edit: Par @Chris Burgess, j'ai changé cela en une méthode plus sécurisée.

J'ai supprimé le commentaire pour listen.mode, .group et .owner:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

/ var / run Ne contient que des informations sur le système en cours d'exécution depuis le dernier démarrage, par exemple, les utilisateurs actuellement connectés et les démons en cours d'exécution. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Note latérale:

Mes php5-fpm -vrapports: PHP 5.4.28-1+deb.sury.org~precise+1. Le problème s'est également produit après une récente mise à jour.

Si vous avez tout essayé dans ce post mais que vous ne parvenez pas à faire fonctionner PHP, voici ce qui l'a corrigé pour mon cas:

Assurez-vous que ces lignes ne sont pas commentées dans /etc/php5/fpm/pool.d/www.conf:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Assurez-vous que / etc / nginx / fastcgi_params ressemble à ceci:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Ces deux lignes manquaient dans mes / etc / nginx / fastcgi_params, assurez-vous qu'elles sont là!

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_script_name;

Ensuite, redémarrez php5-fpm et nginx. Devrait faire l'affaire.

En fait, "listen.mode" devrait être: "0660" et non "0666" car Autre écriture ou Autre lecture n'est jamais un bon choix ici.

Essayez donc de déterminer sous quel utilisateur / groupe votre serveur Web s'exécute. J'utilise CentOs et il fonctionne en tant qu'utilisateur "nginx" Alors ajoutez à votre php-fpm.conf:

listen.owner = nginx
listen.group = nginx
listen.mode = 0660

enfin redémarrer php-fpm

Vérifiez quel utilisateur exécute nginx. Depuis Ubuntu 12.04, nginx est exécuté par l'utilisateur nginx qui n'est pas membre du groupe www-data.

usermod -a -G www-data nginx

et le redémarrage des démons nginx et php5-fpm résout le problème.

Alternative à l'élargissement des autorisations dans votre configuration php, vous pouvez changer l'utilisateur spécifié dans votre configuration nginx.

Sur la première ligne de votre extrait nginx.conf ci-dessus, l'utilisateur et le groupe sont spécifiés respectivement www et www.

user  www www;

Pendant ce temps, votre configuration php spécifie probablement un utilisateur et un groupe de www-data:

listen.owner = www-data
listen.group = www-data

Vous pouvez alors modifier la ligne de votre nginx.conf, par l'une des options suivantes:

user www-data www;
user www-data www-data; # or any group, really, since you have the user matching
user www www-data; # requires that your php listen.mode gives rw access to the group

Il faut également tenir compte de vos pools FPM individuels, le cas échéant.

Je ne pouvais pas comprendre pourquoi aucune de ces réponses ne fonctionnait pour moi aujourd'hui. Cela avait été un scénario de définition et d'oubli pour moi, où j'avais oublié que listen.user et listen.group étaient dupliqués sur une base par pool.

Si vous avez utilisé des pools pour différents comptes d'utilisateurs comme je l'ai fait, où chaque compte d'utilisateur possède ses processus et sockets FPM, définir uniquement les options de configuration par défaut listen.owner et listen.group sur 'nginx' ne fonctionnera tout simplement pas. Et évidemment, laisser «nginx» les posséder tous n'est pas non plus acceptable.

Pour chaque piscine , assurez-vous que

listen.group = nginx

Sinon, vous pouvez laisser seul la propriété de la piscine.

Je viens de recevoir à nouveau cette erreur aujourd'hui alors que je mettais à jour ma machine (avec des mises à jour pour PHP) exécutant Ubuntu 14.04 . Le fichier de configuration de distribution /etc/php5/fpm/pool.d/www.confest correct et ne nécessite aucune modification actuellement.

J'ai trouvé les erreurs suivantes:

dmesg | grep php
[...]
[ 4996.801789] traps: php5-fpm[23231] general protection ip:6c60d1 sp:7fff3f8c68f0 error:0 in php5-fpm[400000+800000]
[ 6788.335355] traps: php5-fpm[9069] general protection ip:6c5d81 sp:7fff98dd9a00 error:0 in php5-fpm[400000+7ff000]

La chose étrange était que j'ai 2 sites en cours d'exécution qui utilisent PHP-FPM sur cette machine, l'un fonctionnait bien et l'autre (une installation Tiny Tiny RSS) m'a donné un 502, où les deux fonctionnaient bien auparavant .

J'ai comparé les deux fichiers de configuration et j'ai constaté qu'il fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;manquait pour le site affecté.

Les deux fichiers de configuration contiennent désormais le bloc suivant et fonctionnent à nouveau correctement:

location ~ \.php$ {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        include /etc/nginx/snippets/fastcgi-php.conf;
}

Mettre à jour

Il convient de noter qu'Ubuntu expédie deux fichiers de paramètres liés à fastcgi et également un extrait de configuration qui est disponible depuis Vivid et également dans le PPA version . La solution a été mise à jour en conséquence.

Diff des fichiers de paramètres fastcgi:

$ diff -up fastcgi_params fastcgi.conf
--- fastcgi_params      2015-07-22 01:42:39.000000000 +0200
+++ fastcgi.conf        2015-07-22 01:42:39.000000000 +0200
@@ -1,4 +1,5 @@

+fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
 fastcgi_param  QUERY_STRING       $query_string;
 fastcgi_param  REQUEST_METHOD     $request_method;
 fastcgi_param  CONTENT_TYPE       $content_type;

Extrait de configuration dans /etc/nginx/snippets/fastcgi-php.conf

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

Le correctif simple suivant a fonctionné pour moi, en contournant les problèmes d'autorisations possibles avec le socket.

Dans votre configuration nginx, définissez fastcgi_pass sur:

fastcgi_pass   127.0.0.1:9000;

Au lieu de

fastcgi_pass   /var/run/php5-fpm.sock;

Cela doit correspondre au paramètre listen = dans /etc/php5/fpm/pool.d/www.conf, alors définissez-le également sur:

listen = 127.0.0.1:9000;

Redémarrez ensuite php5-fpm et nginx

service php5-fpm restart

Et

service nginx restart

Pour plus d'informations, voir: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

Le problème dans mon cas était que le serveur Web Nginx s'exécutait en tant qu'utilisateur nginx et que le pool s'exécutait en tant qu'utilisateur www-data.

J'ai résolu le problème en modifiant l'utilisateur sur lequel Nginx s'exécute dans le /etc/nginx/nginx.conf fichier (peut être différent sur votre système, le mien est Ubuntu 16.04.1)

Changement: user nginx;

à: user www-data;

puis redémarrez Nginx: service nginx restart

Simple mais fonctionne ..

listen.owner = nginx
listen.group = nginx

chown nginx:nginx /var/run/php-fpm/php-fpm.sock

J'ai résolu le même problème sur Amazon Linux AMI 2016.09 (Centos 7) en suivant les étapes suivantes.

Ouvrez vos fichiers www.conf (Exemple: sudo nano /etc/php-fpm.d/www.conf) Enfin, recherchez les lignes qui définissent listen.owner et listen.group et modifiez leurs valeurs de "personne" à "nginx ":

listen.owner = nginx
listen.group = nginx
listen.mode = 0666

Enfin, recherchez les lignes qui définissent l'utilisateur et le groupe et modifiez leurs valeurs de "apache" à "nginx":

user = nginx
group = nginx

Redémarrez php-fpm (redémarrage du service sudo php-fpm)

La chose la plus importante ici est de savoir quel utilisateur utilise nginx, devez-vous également le spécifier

dans votre nginx.conf

user www-data;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

dans votre www.conf

listen.owner = www-data
listen.group = www-data
;listen.mode = 0660

dans votre cas, l'utilisateur et le groupe sont "www" alors remplacez-le simplement.

• redémarrer nginx et php fpm

Si vous avez un pool différent par utilisateur, assurez-vous que l'utilisateur et le groupe sont correctement définis dans le fichier de configuration. Vous pouvez trouver un utilisateur nginx dans le fichier /etc/nginx/nginx.conf. Le groupe nginx est identique à l'utilisateur nginx.

user = [pool-user]
group = [pool-group]
listen.owner = [nginx-user]
listen.group = [nginx-group]

Vérifiez également SELINUX (/ etc / selinux):

# getenforce

éteignez-le:

# setenforce 0

Dans mon cas, php-fpm ne fonctionnait pas du tout, donc je devais juste démarrer le service 😂

service php7.3-fpm start
#on ubuntu 18.04

Voir simplement le /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidfichier IS PID

Dans le fichier /etc/php5/fpm/pool.d/www.conf

listen = /var/run/php5-fpm.sock Fichier IS SOCKET

si vous pid égale écouter ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> mauvais réglages et terminer le réglage/etc/php5/fpm/pool.d/www.conf

user = nginx
group = nginx
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Juste pour ajouter, sur CentOS (et probablement Red Hat et Fedora), le fichier pour modifier les autorisations est à:

/etc/php-fpm.d/www.conf

Après la mise à niveau d'Ubuntu 14.04 lts vers Ubuntu 16.04 lts, ​​j'ai trouvé une autre raison à cette erreur que je n'ai jamais vue auparavant.

Pendant le processus de mise à niveau, j'avais complètement perdu mon exécutable php5-fpm. Tous les fichiers de configuration étaient intacts et il m'a fallu un certain temps pour réaliser que service php5-fpm startcela ne démarrait pas vraiment un processus, car il ne montrait aucune erreur.

Mon moment d'éveil a été quand j'ai remarqué qu'il n'y avait pas de fichier socket /var/run/php5-fpm.sock, comme il se doit, ni netstat -anmontré les processus d'écoute sur le port que j'ai essayé comme alternative tout en essayant de résoudre ce problème. Le fichier / usr / sbin / php5-fpm étant également inexistant, j'étais enfin sur la bonne voie.

Afin de résoudre ce problème, j'ai mis à niveau php de la version 5.5 à 7.0. apt-get install php-fpma fait l'affaire en tant qu'effet secondaire. Après cela et l'installation d'autres packages nécessaires, tout était revenu à la normale.

Cette solution de mise à niveau peut cependant avoir ses propres problèmes . Depuis php a évolué un peu, il est possible que le logiciel se brise de manière inimaginable. Donc, même si j'ai suivi cette voie, vous souhaiterez peut-être conserver la version que vous aimez juste un peu plus longtemps.

Heureusement, il semble y avoir un bon moyen pour cela , comme décrit sur le site Windows Personnaliser:

add-apt-repository ppa:ondrej/php
apt-get purge php5-common
apt-get update
apt-get install php5.6

Une solution plus soignée que ce soit, je n'ai pas essayé ça. Je m'attends à ce que les prochains jours me disent si j'aurais dû.

J'ai eu l'erreur similaire.

Toutes les recommandations n'ont pas aidé.

Le seul www-data de remplacement avec nginx a aidé:

$ sudo chmod nginx:nginx /var/run/php/php7.2-fpm.sock

/var/www/php/fpm/pool.d/www.conf

user = nginx
group = nginx
...
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

J'ai changé d'OS sur mon serveur à plusieurs reprises en essayant d'obtenir le système le plus confortable.

Cela fonctionnait très bien la plupart du temps, mais j'ai finalement eu cette erreur 502 Gateway.

J'utilise un socket php fpm pour chaque compte au lieu de garder le même pour tous. Donc, si l'un plante, au moins les autres applications continuent de fonctionner.

J'avais l'habitude d'avoir des utilisateurs et des groupes www-data. Mais cela a changé sur mon Debian 8 avec les derniers Nginx 1.8 et php5-fpm.

L'utilisateur par défaut est nginx, tout comme le groupe. Pour en être sûr, le meilleur moyen est de vérifier les fichiers / etc / group et / etc / passwd. Ils ne peuvent pas mentir.

C'est là que j'ai trouvé que maintenant j'ai nginx dans les deux et non plus www-data.

Peut-être que cela peut aider certaines personnes à essayer de découvrir pourquoi le message d'erreur continue de s'afficher.

Ça a marché pour moi.

À ceux qui ont tout essayé dans ce fil et qui sont toujours restés: cela a résolu mon problème. J'ai mis à jour /usr/local/nginx/conf/nginx.conf

1. Décommentez la ligne en disant user

2. faites en www-datasorte qu'il devienne:user www-data;

3. Enregistrez-le (accès root requis)

4. Redémarrez nginx

Si vous avez des déclarations

pid = /run/php-fpm.pid

et

listen = /run/php-fpm.pid

dans différents fichiers de configuration, alors root sera propriétaire de ce fichier.