Aktualizuję nginx do 1.4.7 i php do 5.5.12 , po czym dostałem błąd 502 . Przed aktualizacją wszystko działa dobrze.

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;
        }

Miałem podobny błąd po aktualizacji php. PHP naprawiło błąd bezpieczeństwa, który omiał rwuprawnienia do pliku gniazda.

1. Otwórz /etc/php5/fpm/pool.d/www.conflub /etc/php/7.0/fpm/pool.d/www.conf, w zależności od wersji.

2. Odkomentuj wszystkie linie uprawnień, takie jak:

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

3. Uruchom ponownie fpm - sudo service php5-fpm restartlubsudo service php7.0-fpm restart

Uwaga : jeśli twój serwer działa jako użytkownik inny niż www-data, musisz odpowiednio zaktualizować www.confplik

Wszystkie wspomniane obecnie poprawki zasadniczo powodują ponowne otwarcie dziury w zabezpieczeniach.

Skończyło się na tym, że dodałem następujące wiersze do mojego pliku konfiguracyjnego PHP-FPM.

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

Upewnij się, że dane www to tak naprawdę użytkownik, na którym działa pracownik nginx. W przypadku Debiana domyślnie są to dane www.

Wykonanie 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.

Okazało się, że musiałem zmienić listen.modesię 0660w /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

Edycja: Na @Chris Burgess zmieniłem to na bezpieczniejszą metodę.

Usunąłem komentarz dla Listen.mode, .group i .owner:

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

/ var / run Przechowuje tylko informacje o systemie uruchomionym od ostatniego uruchomienia, np. aktualnie zalogowani użytkownicy i uruchomione demony. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Dygresja:

Moje php5-fpm -vraporty: PHP 5.4.28-1+deb.sury.org~precise+1. Problem pojawił się również po ostatniej aktualizacji.

Jeśli wypróbowałeś już wszystko w tym poście, ale nie udało ci się uzyskać PHP do pracy, to naprawiło to w moim przypadku:

Upewnij się, że te wiersze nie są komentowane 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 następująco:

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;

Następnie zrestartuj php5-fpm i nginx. Powinien załatwić sprawę.

W rzeczywistości „Listen.mode” powinno brzmieć: „0660”, a nie „0666”, ponieważ Inne zapisywalne lub inne czytelne nigdy nie są tutaj dobrym wyborem.

Spróbuj więc dowiedzieć się, który użytkownik / grupa działa na twoim serwerze. Używam CentO i działa jako użytkownik „nginx”. Dodaj więc do swojego php-fpm.conf:

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

w końcu zrestartuj php-fpm

Sprawdź, który użytkownik uruchamia nginx. Począwszy od Ubuntu 12.04 nginx jest uruchamiany przez użytkownika nginx, który nie jest członkiem grupy danych www.

usermod -a -G www-data nginx

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

Alternatywnie do rozszerzania uprawnień w konfiguracji php, możesz zmienić użytkownika określonego w konfiguracji nginx.

W pierwszym wierszu fragmentu nginx.conf powyżej użytkownik i grupa są określone odpowiednio jako www i www.

user  www www;

Tymczasem twoja konfiguracja php prawdopodobnie określa użytkownika i grupę danych www:

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

Możesz zmienić wiersz w pliku nginx.conf na dowolny z poniższych, a następnie:

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ę ewentualne indywidualne pule FPM.

Nie mogłem zrozumieć, dlaczego żadna z tych odpowiedzi nie działała dzisiaj dla mnie. Był to dla mnie scenariusz „ustaw i zapomnij”, w którym zapomniałem, że listen.user i listen.group zostały zduplikowane dla poszczególnych pul.

Jeśli używałeś pul dla różnych kont użytkowników, tak jak ja, gdzie każde konto użytkownika ma swoje procesy i gniazda FPM, ustawienie tylko domyślnych opcji konfiguracji nasłuchiwania i nasłuchiwania grupy na „nginx” po prostu nie zadziała. I oczywiście, pozwolenie, by „nginx” był ich właścicielem, jest również nie do przyjęcia.

Upewnij się, że dla każdej puli

listen.group = nginx

W przeciwnym razie możesz zostawić własność puli i takie w spokoju.

Właśnie dostałem ten błąd dzisiaj, kiedy zaktualizowałem swój komputer (z aktualizacjami dla PHP) z Ubuntu 14.04 . Plik konfiguracyjny dystrybucji /etc/php5/fpm/pool.d/www.confjest w porządku i obecnie nie wymaga ż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]

Dziwną rzeczą było to, że mam uruchomione 2 strony wykorzystujące PHP-FPM na tej maszynie, jedna działała dobrze, a druga (instalacja Tiny Tiny RSS) dała mi 502, przy czym obie działały wcześniej dobrze .

Porównałem oba pliki konfiguracyjne i okazało się, że fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;brakowało tej witryny.

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

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

Aktualizacja

Należy zauważyć, że Ubuntu dostarcza dwa pliki parametrów związane 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.

Zróżnicowane 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;

Fragment 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;

Poniższa prosta poprawka zadziałała dla mnie, omijając możliwe problemy z uprawnieniami w gnieździe.

W konfiguracji nginx ustaw fastcgi_pass na:

fastcgi_pass   127.0.0.1:9000;

Zamiast

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

Musi to zgadzać się z parametrem listen = w /etc/php5/fpm/pool.d/www.conf, więc ustaw także:

listen = 127.0.0.1:9000;

Następnie uruchom ponownie php5-fpm i nginx

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/

Problem w moim przypadku polegał na tym, że serwer WWW Nginx działał jako użytkownik nginx, a pula działała jako dane www użytkownika.

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

Zmiana: user nginx;

do: user www-data;

następnie uruchom ponownie Nginx: service nginx restart

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 pliki www.conf (przykład: sudo nano /etc/php-fpm.d/www.conf) Na koniec znajdź linie, które ustawiają listen.owner i listen.group i zmień ich wartości z „nobody” na „nginx” „:

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

Na koniec znajdź linie, które ustawiają użytkownika i grupę, i zmień ich wartości z „apache” na „nginx”:

user = nginx
group = nginx

Uruchom ponownie php-fpm (usługa sudo php-fpm restart)

Najważniejszą rzeczą tutaj jest to, który użytkownik używa nginx, a następnie musisz go również podać

w twoim 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;
        }

w twoim www.conf

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

w twoim przypadku użytkownik i grupa to „www”, więc po prostu go zastąp.

• zrestartuj nginx i php fpm

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

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

Sprawdź także SELINUX (/ etc / selinux):

# getenforce

Wyłącz to:

# setenforce 0

Zobacz /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidplik IS PID

W pliku /etc/php5/fpm/pool.d/www.conf

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

jeśli pid równa nasłuchiwanie ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> złe ustawienia i zakończenie ustawiania/etc/php5/fpm/pool.d/www.conf

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

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

Podczas procesu aktualizacji jakoś straciłem mój plik wykonywalny php5-fpm. Wszystkie pliki konfiguracyjne były nienaruszone i zajęło mi to trochę czasuservice php5-fpm start tak naprawdę nie uruchomiłem procesu, ponieważ nie pokazałem żadnych błędów.

Mój moment przebudzenia nastąpił, gdy zauważyłem, że nie ma pliku gniazda /var/run/php5-fpm.sock, tak jak powinien, ani nie netstat -anpokazałem procesów nasłuchujących na porcie, które próbowałem alternatywnie, próbując rozwiązać ten problem. 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-fpmzrobił lewę jako efekt uboczny. Po zainstalowaniu innych niezbędnych pakietów wszystko wróciło do normy.

To rozwiązanie uaktualniające może mieć własne problemy . Ponieważ php ewoluował całkiem sporo, oprogramowanie może się zepsuć w niewyobrażalny sposób. Tak więc, mimo że podążyłem tą ścieżką, możesz chcieć dłużej zachować wersję, którą lubisz.

Na szczęście wydaje się, że jest na to dobry sposób , jak opisano na stronie The Customize Windows:

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

Choć może to być lepsze rozwiązanie, nie próbowałem tego. Oczekuję, że następne kilka dni powie mi, czy powinienem.

W moim przypadku php-fpm wcale nie działało, więc musiałem tylko uruchomić usługę 😂

service php7.3-fpm start
#on ubuntu 18.04

Miałem podobny błąd.

Wszystkie rekomendacje nie pomogły.

Jedyne zastępcze dane www z nginx pomogły:

$ 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

Aby dodać, w CentOS (i prawdopodobnie w Red Hat i Fedorze) plik do zmiany uprawnień to:

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

Kilka razy zmieniłem system operacyjny na moim serwerze, starając się uzyskać najwygodniejszy system.

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

Korzystam z php fpm dla każdego konta zamiast tego samego dla wszystkich. Więc jeśli jedna z nich ulegnie awarii, przynajmniej inne aplikacje będą nadal działać.

Kiedyś miałem dane użytkowników i grup www. Ale zmieniło się to w moim Debianie 8 z najnowszym Nginx 1.8 i php5-fpm.

Domyślnym użytkownikiem jest nginx, podobnie jak grupa. Aby być tego pewnym, najlepszym sposobem jest sprawdzenie plików / etc / group i / etc / passwd. Nie mogą kłamać.

To tam odkryłem, że teraz mam nginx zarówno w danych www, jak i nie.

Może to może pomóc niektórym osobom nadal próbować dowiedzieć się, dlaczego komunikat o błędzie wciąż się pojawia.

To zadziałało dla mnie.

Dla tych, którzy próbowali wszystkiego w tym wątku i nadal utknęli: to rozwiązało mój problem. Zaktualizowałem /usr/local/nginx/conf/nginx.conf

1. Odkomentuj powiedzenie linii user

2. spraw, www-dataaby stało się:user www-data;

3. Zapisz (wymagany dostęp root)

4. Uruchom ponownie nginx

Jeśli masz deklaracje

pid = /run/php-fpm.pid

i

Listen = /run/php-fpm.pid

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