Wszystkie poprawki, o których tu mowa, w zasadzie umożliwiają ponowne usunięcie luki w zabezpieczeniach.

Skończyło się na dodaniu następujących linii do mojego pliku konfiguracyjnego PHP-FPM.

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

Upewnij się, że www-data jest rzeczywiście użytkownikiem, którego nginx worker jest uruchomiony. Dla Debiana domyślnie jest to www-data.

Robienie tego w ten sposób nie włącza problemu bezpieczeństwa, który ta zmiana miała naprawić.

Rozwiązanie@Xander działa, ale nie utrzymuje się po ponownym uruchomieniu.

Stwierdziłem, że muszę zmienić listen.mode na 0660 w /etc/php5/fpm/pool.d/www.conf.

Próbka z 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: Per @ Chris Burgess, zmieniłem to na bardziej bezpieczną metodę.

Usunąłem komentarz do słuchania.mode,Grupa Iwłaściciel:

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

/ var / run przechowuje tylko informacje o uruchomionym systemie od ostatniego rozruchu, np. aktualnie zalogowanych użytkownikach i uruchomionych demonach. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure).

Uwaga boczna:

Moje php5-fpm -v Raporty: PHP 5.4.28-1+deb.sury.org~precise+1. Problem wystąpił również po ostatniej aktualizacji.

Jeśli próbowałeś wszystkiego w tym poście, ale nie odniosłeś sukcesu w uruchomieniu PHP, to jest to, co naprawiło to w moim przypadku:

Upewnij się, że te linie są nieakcentowane w /etc / php5 / fpm / pool.d / www.conf:

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

Upewnij się, że /etc/nginx/fastcgi_params wygląda tak:

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;

Tych dwóch linii brakowało w moim / etc/nginx / fastcgi_params, upewnij się, że tam są!

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

W rzeczywistości, "słuchaj.tryb "powinien być: "0660", a nie "0666", ponieważ inny Zapisywalny lub inny czytelny nigdy nie jest dobrym wyborem.

Więc spróbuj dowiedzieć się, który użytkownik / grupa działa twój serwer WWW. Używam CentOs i działa jako użytkownik " nginx" Więc dodaj do swojego php-fpm.conf:

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

Wreszcie restart php-fpm

Sprawdź, który użytkownik uruchamia nginx. Od Ubuntu 12.04 nginx działa przez użytkownika nginx, który nie jest członkiem grupy www-data.

Usermod-A-G www-data nginx

I ponowne uruchomienie demonów nginx i php5-fpm rozwiązuje problem.

Alternatywą dla rozszerzenia uprawnień w konfiguracji php, możesz zmienić użytkownika określonego w konfiguracji nginx.

user  www www;

Tymczasem Twój PHP Config prawdopodobnie określa użytkownika i grupę danych www:

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

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

Należy również wziąć pod uwagę poszczególne pule FPM, jeśli takie istnieją.

Nie mogłem zrozumieć, dlaczego żadna z tych odpowiedzi nie działa dla mnie dzisiaj. To był dla mnie scenariusz "set-and-forget", w którym zapomniałem o słuchaniu.user and listen.grupa była dublowana na zasadzie per-pool.

Jeśli używałeś PUL dla różnych kont użytkowników, tak jak ja, gdzie każde konto użytkownika posiada swoje procesy i gniazda FPM, ustawiając tylko domyślny listen.właściciel i posłuchaj.Grupa opcje konfiguracji "nginx" po prostu nie będą działać. I oczywiście pozwolenie na posiadanie ich wszystkich przez "nginx" jest również niedopuszczalne.

Dla każdej puli , upewnij się, że

listen.group = nginx

W przeciwnym razie możesz zostawić własność basenu i tym podobne.

Właśnie dostałem ten błąd ponownie dzisiaj, jak zaktualizowałem mój komputer (z aktualizacjami dla PHP) uruchomiony Ubuntu 14.04. Plik konfiguracyjny dystrybucji /etc/php5/fpm/pool.d/www.conf jest w porządku i nie wymaga obecnie żadnych zmian.

Znalazłem następujące błędy:

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]

Dziwne było to, że mam uruchomione 2 strony, które wykorzystują PHP-FPM na tej maszynie jeden działał dobrze, a drugi (maleńka instalacja RSS) dał mi 502, gdzie oba działają dobrze przed .

Porównałem oba pliki konfiguracyjne i stwierdziłem, że fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; brakowało w danej witrynie.

Oba pliki konfiguracyjne zawierają teraz następujący blok i działają ponownie poprawnie:

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

Update

Należy zauważyć, że Ubuntu zawiera dwa pliki parametrów związanych z fastcgi, a także fragment konfiguracji, który jest dostępny od Vivid, a także w wersji PPA . Rozwiązanie zostało odpowiednio zaktualizowane.

Diff of pliki parametrów 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;

Urywek konfiguracji w /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;

Następująca prosta poprawka zadziałała dla mnie, pomijając możliwe problemy z uprawnieniami z gniazdem.

fastcgi_pass   127.0.0.1:9000;

Zamiast

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

To musi pasować do parametru listen = w /etc/php5/fpm / pool.d / www.conf, więc również ustaw to na:

listen = 127.0.0.1:9000;

service php5-fpm restart

I

service nginx restart

Aby uzyskać więcej informacji, zobacz: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

Proste, ale działa..

listen.owner = nginx
listen.group = nginx

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

Naprawiłem ten sam problem na Amazon Linux AMI 2016.09 (Centos 7), wykonując następujące kroki.

Otwórz swoją www.pliki conf (przykład: sudo nano / etc / php-fpm.d / www.conf) Na koniec znajdź linie, które ustawiają listen.właściciel i posłuchaj.Grupa I zmiana ich wartości z" NIKT "NA"nginx":

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

user = nginx
group = nginx

Restart php - FPM (sudo service PHP-FPM restart)

Problem w moim przypadku polegał na tym, że serwer WWW Nginx działał jako użytkownik nginx, a Pula działała jako użytkownik www-data.

Rozwiązałem problem zmieniając użytkownika nginx działa w pliku /etc/nginx/nginx.conf (może być inny w systemie, mój jest Ubuntu 16.04.1)

Change: user nginx;

Do: user www-data;

Po aktualizacji z Ubuntu 14.04 LTS do Ubuntu 16.04 lts znalazłem kolejny powód tego błędu, którego wcześniej nie widziałem.

Podczas procesu aktualizacji zgubiłem w jakiś sposób mój plik wykonywalny php5-fpm. Wszystkie pliki konfiguracyjne były nienaruszone i zajęło mi trochę czasu, aby zdać sobie sprawę, że service php5-fpm start tak naprawdę nie rozpoczął procesu, ponieważ nie wykazał żadnych błędów.

Mój moment przebudzenia był wtedy, gdy zauważyłem, że nie ma pliku socket w /var/run/php5-fpm.sock, tak jak powinno być, ani netstat -an Pokaż procesy nasłuchujące na porcie, które wypróbowałem jako alternatywę podczas próby rozwiązania tego problemu. Ponieważ plik/usr/sbin / php5-fpm również nie istniał, w końcu byłem na dobrej drodze.

Aby rozwiązać ten problem zaktualizowałem php z wersji 5.5 do 7.0. apt-get install php-fpm zrobił sztuczkę jako efekt uboczny. Po tym i zainstalowaniu innych niezbędnych pakietów wszystko wróciło do normy.

to rozwiązanie może mieć własne problemy , jednak. Ponieważ php ewoluował dość dużo, możliwe jest, że oprogramowanie złamie się w niewyobrażalny sposób. Więc, mimo, że poszedłem tą ścieżką, możesz chcieć zachować wersję, którą lubisz, tylko przez chwilę.

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

Sprawdź również SELINUX (/etc / selinux):

# getenforce

Wyłącz to:

# setenforce 0

Aby dodać, na CentOS (i prawdopodobnie Red Hat i Fedora) plik do zmiany uprawnień jest w:

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

Zmieniałem OS na moim serwerze kilka razy starając się uzyskać jak najwygodniejszy system.

Kiedyś działało bardzo dobrze przez większość czasu, ale w końcu dostałem ten błąd bramki 502.

Używam gniazda php fpm dla każdego konta zamiast utrzymywania tego samego dla wszystkich. Więc jeśli jedna się zawiesi, przynajmniej inne aplikacje będą działać.

Kiedyś miałem dane użytkownika i grupy www. Ale to się zmieniło na moim Debianie 8 z najnowszym Nginx 1.8 i php5-fpm.

Domyślnym użytkownikiem jest nginx i tak jest grupa. Aby mieć pewność, najlepszym sposobem jest sprawdzenie plików /etc /group i/etc / passwd. To nie może kłamać.

To tam znalazłem, że teraz mam nginx w obu i nie ma już danych www.

Może to pomoże niektórym osobom, które nadal próbują dowiedzieć się, dlaczego komunikat o błędzie wciąż się pojawia.

U mnie zadziałało.

Jeśli masz inną pulę na użytkownika, upewnij się, że użytkownik i grupa są ustawione poprawnie w pliku konfiguracyjnym. Możesz znaleźć użytkownika nginx w /etc/nginx/nginx.plik conf. Grupa nginx jest taka sama jak użytkownik nginx.

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

Do tych, którzy próbowali wszystkiego w tym wątku i nadal tkwili: to rozwiązało mój problem. W tym celu należy skontaktować się z naszym biurem obsługi klienta.conf

1. Uncomment the line saying user

2. Make it www-data so it becomes: user www-data;

3. Save it (root access required)

4. Restart nginx

Jeśli masz deklaracje

Pid = / run / php-fpm.pid

I

Listen = / run / php-fpm.pid

W różnych plikach konfiguracyjnych, wtedy root będzie właścicielem tego pliku.