Aggiornamento nginx a 1.4.7 e php a 5.5.12 , dopo di che ho ricevuto l' errore 502 . Prima di aggiornare tutto funziona bene.

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

Ho avuto un errore simile dopo l'aggiornamento di PHP. PHP ha corretto un bug di sicurezza in cui oaveva l' rwautorizzazione per il file socket.

1. Apri /etc/php5/fpm/pool.d/www.confo /etc/php/7.0/fpm/pool.d/www.conf, a seconda della versione.

2. Rimuovi dal commento tutte le righe di autorizzazione, come:

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

3. Riavvia fpm - sudo service php5-fpm restartoppuresudo service php7.0-fpm restart

Nota : se il server Web viene eseguito come utente diverso da www-data, sarà necessario aggiornare il www.conffile di conseguenza

Tutte le correzioni attualmente menzionate fondamentalmente abilitano nuovamente la falla di sicurezza.

Quello che ho finito è aggiungere le seguenti righe al mio file di configurazione di PHP-FPM.

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

Assicurati che www-data sia effettivamente l'utente su cui sta eseguendo il lavoratore nginx. Per debian sono i dati www per impostazione predefinita.

In questo modo non si abilita il problema di sicurezza che questa modifica avrebbe dovuto risolvere .

La soluzione di @ Xander funziona, ma non persiste dopo un riavvio.

Ho scoperto che ho dovuto cambiare listen.modea 0660in /etc/php5/fpm/pool.d/www.conf.

Esempio da 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

Modificare: Per @Chris Burgess, ho cambiato questo con il metodo più sicuro.

Ho rimosso il commento per Listen.mode, .group e .owner:

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

/ var / run contiene solo informazioni sul sistema in esecuzione dall'ultimo avvio, ad es. utenti attualmente connessi e daemon in esecuzione. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Nota a margine:

I miei php5-fpm -vrapporti: PHP 5.4.28-1+deb.sury.org~precise+1. Il problema si è verificato anche dopo un recente aggiornamento.

Se hai provato tutto in questo post ma non stai riuscendo a far funzionare PHP, questo è ciò che ha risolto il mio caso:

Assicurati di avere queste righe decommentate in /etc/php5/fpm/pool.d/www.conf:

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

Assicurati che / etc / nginx / fastcgi_params sia simile a questo:

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;

Queste due righe mancavano dal mio / etc / nginx / fastcgi_params, assicurati che siano lì!

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

Quindi, riavvia php5-fpm e nginx. Dovrebbe fare il trucco.

In effetti, "hear.mode" dovrebbe essere: "0660" e non "0666" come Altro scrivibile o Altro leggibile non è mai una buona scelta qui.

Quindi prova a scoprire quale utente / gruppo esegue il tuo server web. Uso CentOs e funziona come utente "nginx" Quindi aggiungi al tuo php-fpm.conf:

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

infine riavviare php-fpm

Controlla quale utente esegue nginx. A partire da Ubuntu 12.04 nginx viene eseguito dall'utente nginx che non è un membro del gruppo www-data.

usermod -a -G www-data nginx

e il riavvio dei demoni nginx e php5-fpm risolve il problema.

In alternativa all'ampliamento delle autorizzazioni nella tua configurazione php, potresti cambiare l'utente specificato nella tua configurazione nginx.

Nella prima riga del tuo estratto nginx.conf, l'utente e il gruppo sono specificati rispettivamente come www e www.

user  www www;

Nel frattempo, la tua configurazione php probabilmente specifica un utente e un gruppo di dati www:

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

È possibile modificare la riga in nginx.conf in uno dei seguenti, quindi:

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

È necessario considerare anche i singoli pool FPM, se presenti.

Non riuscivo a capire perché nessuna di queste risposte funzionasse per me oggi. Questo era stato uno scenario per me, in cui avevo dimenticato che hear.user e hear.group erano duplicati in base al pool.

Se hai usato pool per diversi account utente come ho fatto io, in cui ogni account utente possiede i propri processi e socket FPM, impostando solo le opzioni di configurazione di Listen.owner e Listen.group predefinite su 'nginx' semplicemente non funzionerà. E ovviamente, lasciare che 'nginx' li possieda tutti non è neanche accettabile.

Per ogni pool , assicurarsi che

listen.group = nginx

Altrimenti, puoi lasciare la proprietà del pool e simili.

Ho appena ricevuto di nuovo questo errore oggi mentre ho aggiornato la mia macchina (con aggiornamenti per PHP) con Ubuntu 14.04 . Il file di configurazione della distribuzione/etc/php5/fpm/pool.d/www.conf va bene e al momento non richiede alcuna modifica.

Ho trovato i seguenti errori:

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 cosa strana è che ho 2 siti in esecuzione che utilizzano PHP-FPM su questa macchina uno funzionava bene e l'altro (un'installazione RSS Tiny Tiny) mi ha dato un 502, dove entrambi hanno funzionato bene prima .

Ho confrontato entrambi i file di configurazione e ho scoperto che fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;mancava per il sito interessato.

Entrambi i file di configurazione ora contengono il seguente blocco e funzionano di nuovo correttamente:

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

Aggiornare

Va notato che Ubuntu spedisce due file di parametri relativi a fastcgi e anche uno snippet di configurazione che è disponibile da Vivid e anche nella versione PPA . La soluzione è stata aggiornata di conseguenza.

Diff dei file dei parametri 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;

Snippet di configurazione in /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;

La seguente semplice correzione ha funzionato per me, aggirando possibili problemi di autorizzazioni con il socket.

Nella tua configurazione nginx, imposta fastcgi_pass su:

fastcgi_pass   127.0.0.1:9000;

Invece di

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

Deve corrispondere al parametro hear = in /etc/php5/fpm/pool.d/www.conf, quindi imposta anche questo su:

listen = 127.0.0.1:9000;

Quindi riavviare php5-fpm e nginx

service php5-fpm restart

E

service nginx restart

Per maggiori informazioni, consultare: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

Nel mio caso il problema era che il server Web Nginx era in esecuzione come nginx utente e il pool era in esecuzione come www-data utente.

Ho risolto il problema cambiando l'utente in cui Nginx è in esecuzione nel /etc/nginx/nginx.conffile (potrebbe essere diverso sul tuo sistema, il mio è Ubuntu 16.04.1)

Modificare: user nginx;

per: user www-data;

quindi riavvia Nginx: service nginx restart

Semplice ma funziona ..

listen.owner = nginx
listen.group = nginx

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

Ho risolto lo stesso problema su Amazon Linux AMI 2016.09 (Centos 7) procedendo come segue.

Apri i tuoi file www.conf (Esempio: sudo nano /etc/php-fpm.d/www.conf) Infine, trova le linee che impostano hear.owner e Listen.group e cambia i loro valori da "nobody" a "nginx ":

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

Infine, trova le righe che impostano l'utente e il gruppo e cambiano i loro valori da "apache" a "nginx":

user = nginx
group = nginx

Riavvia php-fpm (riavvio php-fpm del servizio sudo)

La cosa più importante qui è quale utente sta usando nginx, quindi è necessario specificarlo pure

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

nel tuo www.conf

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

nel tuo caso l'utente e il gruppo sono "www", quindi basta sostituirlo.

• riavvia nginx e php fpm

Se si dispone di un pool diverso per utente, assicurarsi che l'utente e il gruppo siano impostati correttamente nel file di configurazione. Puoi trovare l'utente nginx nel file /etc/nginx/nginx.conf. Il gruppo nginx è uguale all'utente nginx.

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

Controlla anche SELINUX (/ etc / selinux):

# getenforce

spegnilo:

# setenforce 0

Nel mio caso php-fpm non funzionava affatto, quindi dovevo solo avviare il servizio 😂

service php7.3-fpm start
#on ubuntu 18.04

Basta vedere il /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidfile IS PID

Nel file /etc/php5/fpm/pool.d/www.conf

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

se pidi uguale hear ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> impostazioni errate e finisci sett/etc/php5/fpm/pool.d/www.conf

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

Solo per aggiungere, su CentOS (e probabilmente Red Hat e Fedora) il file in cui cambiare i permessi è su:

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

Dopo l'aggiornamento da Ubuntu 14.04 a Ubuntu 16.04 ho trovato un motivo in più per questo errore che non avevo mai visto prima.

Durante il processo di aggiornamento avevo in qualche modo perso il mio eseguibile php5-fpm. Tutti i file di configurazione erano intatti e mi ci è voluto un po 'di tempo per rendermene contoservice php5-fpm start realtà non ha avviato un processo, in quanto non ha mostrato alcun errore.

Il mio momento di risveglio è stato quando ho notato che non c'erano file socket /var/run/php5-fpm.sock, come dovrebbe esserlo, e nemmeno cosìnetstat -an mostrato processi di ascolto sulla porta che ho provato come alternativa mentre cercavo di risolvere questo problema. Dato che il file / usr / sbin / php5-fpm era anche inesistente, ero finalmente sulla buona strada.

Per risolvere questo problema ho aggiornato php dalla versione 5.5 alla 7.0. apt-get install php-fpmha fatto il trucco come effetto collaterale. Dopo quello e l'installazione di altri pacchetti necessari tutto è tornato alla normalità.

Questa soluzione di aggiornamento può tuttavia presentare problemi propri . Poiché php si è evoluto un po ', è possibile che il software si rompa in modi inimmaginabili. Quindi, anche se ho seguito questa strada, potresti voler mantenere la versione a cui tieni solo per un po 'di più.

Fortunatamente, sembra che ci sia un modo pulito per farlo , come descritto nel sito The Customize Windows:

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

Per quanto possa essere una soluzione più ordinata, non ci ho provato. Mi aspetto che i prossimi due giorni mi diranno se avrei dovuto.

Ho avuto l'errore simile.

Tutti i consigli non sono stati d'aiuto.

L'unico dato www di sostituzione con nginx ha aiutato:

$ 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

Ho cambiato il sistema operativo sul mio server parecchie volte cercando di ottenere il sistema più comodo.

In passato funzionava molto bene, ma alla fine ho riscontrato questo errore 502 Gateway.

Uso un socket php fpm per ogni account invece di mantenere lo stesso per tutti. Quindi se uno si arresta in modo anomalo, almeno le altre applicazioni continuano a funzionare.

Avevo i dati www dell'utente e del gruppo. Ma questo è cambiato sul mio Debian 8 con l'ultimo Nginx 1.8 e php5-fpm.

L'utente predefinito è nginx, così come il gruppo. Per sicurezza, il modo migliore è controllare i file / etc / group e / etc / passwd. Questi non possono mentire.

È lì che ho scoperto che ora ho nginx in entrambi e non più i dati www.

Forse questo può aiutare alcune persone che stanno ancora cercando di scoprire perché il messaggio di errore continua a comparire.

Ha funzionato per me.

A coloro che hanno provato tutto in questo thread e sono rimasti bloccati: questo ha risolto il mio problema. Ho aggiornato /usr/local/nginx/conf/nginx.conf

1. Scomincia la frase dicendo user

2. fallo in www-datamodo che diventi:user www-data;

3. Salvalo (accesso root richiesto)

4. Riavvia nginx

Se hai dichiarazioni

pid = /run/php-fpm.pid

e

ascolta = /run/php-fpm.pid

in diversi file di configurazione, quindi root sarà il proprietario di questo file.