Todas las correcciones mencionadas aquí básicamente habilitan el agujero de seguridad de nuevo.

Lo que terminé haciendo es agregar las siguientes líneas a mi archivo de configuración PHP-FPM.

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

Asegúrese de que www-data es realmente el usuario con el que se está ejecutando nginx worker. Para debian es www-data por defecto.

Hacerlo de esta manera no habilita el problema de seguridad que este cambio se suponía que solucionaría.

La solución de@Xander funciona, pero no persiste después de un reinicio.

Encontré que tenía que cambiar listen.mode a 0660 en /etc/php5/fpm/pool.d/www.conf.

Muestra 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: Por @Chris Burgess, he cambiado esto al método más seguro.

Eliminé el comentario para escuchar.modo, .grupo y .propietario:

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

/var/run Solo contiene información sobre el sistema en ejecución desde el último arranque, por ejemplo, los usuarios actualmente registrados y los demonios en ejecución. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure).

Nota al margen:

Mis php5-fpm -v Informes: PHP 5.4.28-1+deb.sury.org~precise+1. El problema ocurrió después de una actualización reciente también.

Si ha intentado todo en este post pero no está teniendo éxito en hacer que PHP funcione, esto es lo que lo arregló para mi caso:

Asegúrese de tener estas líneas sin comentar en /etc/php5/fpm/pool.d / www.conf:

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

Asegúrese de que /etc/nginx/fastcgi_params se vea así:

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;

Estas dos líneas faltaban en mi /etc/nginx / fastcgi_params, ¡asegúrate de que estén ahí!

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

Luego, reinicie php5-fpm y nginx. Debería funcionar.

De hecho, "escucha.mode "debe ser:" 0660 "y no" 0666", ya que Otra opción de Escritura u Otra Legible nunca es una buena opción aquí.

Así que intenta averiguar como usuario/grupo se ejecuta tu servidor web. Yo uso CentOS y se ejecuta como usuario " nginx" Así que añade a tu php-fpm.conf:

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

Finalmente reiniciar php-fpm

Compruebe qué usuario ejecuta nginx. A partir de Ubuntu 12.04 nginx corre por el usuario nginx que no es miembro del grupo www-data.

Usermod-a-G www-data nginx

Y reiniciar los demonios nginx y php5-fpm resuelve el problema.

Alternativa a ampliar los permisos en su configuración de php, puede cambiar el usuario especificado en su configuración de nginx.

En la primera línea de su nginx.anteriormente, el usuario y el grupo se especifican como www y www, respectivamente.

user  www www;

Mientras tanto, su configuración de php probablemente especifica un usuario y un grupo de datos www:

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

Puede cambiar la línea en su nginx.conf, a cualquiera de los siguientes, entonces:

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

También se debe tener en cuenta sus grupos de FPM individuales, si los hay.

No podía entender por qué ninguna de estas respuestas estaba funcionando para mí hoy. Este había sido un escenario de establecer y olvidar para mí, donde había olvidado que escuchar.usuario y escucha.los grupos se duplicaron por grupo.

Si ha utilizado grupos para diferentes cuentas de usuario como lo hice yo, donde cada cuenta de usuario posee sus procesos FPM y sockets, configurando solo el listen predeterminado.propietario y escuchar.grupo las opciones de configuración de 'nginx' simplemente no funcionarán. Y obviamente, dejar que' nginx ' los posea todos tampoco es aceptable.

Para cada grupo, asegúrese de que

listen.group = nginx

De lo contrario, puede dejar la propiedad del grupo y demás.

Acabo de recibir este error de nuevo hoy al actualizar mi máquina (con actualizaciones para PHP) ejecutando Ubuntu 14.04. El archivo de configuración de distribución /etc/php5/fpm/pool.d/www.conf está bien y no requiere ningún cambio actualmente.

Encontré los siguientes errores:

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]

Lo extraño fue que tengo 2 sitios en ejecución que utilizan PHP-FPM en esta máquina uno se estaba ejecutando bien y el otro (una pequeña instalación RSS Diminuta) me dio un 502, donde ambos se han estado ejecutando bien antes de.

Comparé ambos archivos de configuración y encontré que fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; faltaba para el sitio afectado.

Ambos archivos de configuración ahora contienen el siguiente bloque y se están ejecutando bien de nuevo:

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

Actualización

Debe tenerse en cuenta que Ubuntu incluye dos archivos de parámetros relacionados con fastcgi y también un fragmento de configuración que está disponible desde Vivid y también en la versión PPA. La solución se actualizó en consecuencia.

Diff de los archivos de parámetros 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;

Fragmento de configuración en /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 siguiente solución simple funcionó para mí, evitando posibles problemas de permisos con el socket.

En su configuración de nginx, establezca fastcgi_pass en:

fastcgi_pass   127.0.0.1:9000;

En lugar de

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

Esto debe coincidir con el parámetro listen = en /etc/php5/fpm/pool.d / www.conf, así que también establece esto en:

listen = 127.0.0.1:9000;

Luego reinicie php5-fpm y nginx

service php5-fpm restart

Y

service nginx restart

Para más información, ver: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm /

Simple pero funciona..

listen.owner = nginx
listen.group = nginx

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

He solucionado el mismo problema en Amazon Linux AMI 2016.09 (Centos 7) siguiendo los siguientes pasos.

Abra su www.archivos conf (Ejemplo : sudo nano /etc/php-fpm.d / www.conf) Por último, encuentra las líneas que establecen la escucha.propietario y escuchar.grupo y cambiar sus valores de "nadie" a "nginx":

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

Por último, busque las líneas que establecen el usuario y el grupo y cambie sus valores de "apache" a "nginx":

user = nginx
group = nginx

Restart php-fpm (sudo service php-fpm restart)

El problema en mi caso fue que el servidor web Nginx se estaba ejecutando como usuario nginx y el grupo se estaba ejecutando como usuario www-data.

Resolví el problema cambiando el usuario en el que Nginx se está ejecutando en el archivo /etc/nginx/nginx.conf (podría ser diferente en su sistema, el mío es Ubuntu 16.04.1)

Cambio: user nginx;

A: user www-data;

Luego reinicie Nginx: service nginx restart

Después de actualizar de Ubuntu 14.04 lts a Ubuntu 16.04 lts encontré una razón más para este error que no he visto antes.

Durante el proceso de actualización de alguna manera había perdido mi ejecutable php5-fpm por completo. Todos los archivos de configuración estaban intactos y me tomó un tiempo darme cuenta de que service php5-fpm start realmente no iniciaba un proceso, ya que no mostraba ningún error.

Mi momento de despertar fue cuando noté que no había ningún archivo de socket en /var/run/php5-fpm.sock, como debería haber, ni netstat -an mostrar procesos escuchando en el puerto que probé como alternativa al intentar resolver este problema. Dado que el archivo /usr/sbin/php5-fpm tampoco existía, finalmente estaba en el camino correcto.

Para resolver este problema he actualizado php de la versión 5.5 a la 7.0. apt-get install php-fpm hizo el truco como un efecto secundario. Después de eso e instalar otros paquetes necesarios, todo volvió a la normalidad.

Esta solución de actualización puede tener problemas propios, obstante. Dado que php ha evolucionado bastante, es posible que el software se rompa de maneras inimaginables. Así que, a pesar de que fui por ese camino, es posible que desee mantener la versión que le gusta sólo por un tiempo más.

Afortunadamente, parece haber una manera ordenada para eso, como se describe en El sitio Personalizar Windows:

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

Solución más ordenada como podría ser, no lo intenté. Espero que los próximos días me digan si debería haberlo hecho.

También compruebe SELINUX (/etc / selinux):

# getenforce

Apágalo:

# setenforce 0

Solo para agregar, en CentOS (y probablemente en Red Hat y Fedora) el archivo al que cambiar los permisos está en:

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

Cambié el sistema operativo en mi servidor varias veces tratando de obtener el sistema más cómodo.

Solía funcionar muy bien la mayor parte del tiempo, pero por último obtuve este error de puerta de enlace 502.

Utilizo un socket php fpm para cada cuenta en lugar de mantener el mismo para todas. Así que si una falla, al menos las otras aplicaciones siguen ejecutándose.

Solía tener datos www de usuarios y grupos. Pero esto cambió en mi Debian 8 con la última Nginx 1.8 y php5-fpm.

El usuario predeterminado es nginx y también el grupo. Para estar seguro de esto, la mejor manera es comprobar los archivos /etc/group y /etc/passwd. Estos no pueden mentir.

Es allí que encontré que ahora tengo nginx en ambos y ya no www-data.

Tal vez esto pueda ayudar a algunas personas que todavía están tratando de averiguar por qué el mensaje de error sigue apareciendo.

Funcionó para mí.

Si tiene un grupo diferente por usuario, asegúrese de que el usuario y el grupo estén configurados correctamente en el archivo de configuración. Puede encontrar el usuario de nginx en / etc/nginx / nginx.archivo conf. nginx group es igual que nginx user.

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

Para aquellos que probaron todo en este hilo y todavía se pegaron: Esto resolvió mi problema. He actualizado /usr/local/nginx/conf / nginx.conf

1. Descomentar la línea diciendo user

2. Que sea www-data para que se convierta: user www-data;

3. Guárdalo (se requiere acceso root)

4. Reiniciar nginx

Si tiene declaraciones

Pid = /run/php-fpm.pid

Y

Listen = /run/php-fpm.pid

En diferentes archivos de configuración, entonces root será el propietario de este archivo.