Eu atualizo o nginx para 1.4.7 e o php para 5.5.12 . Depois disso, recebi o erro 502 . Antes de atualizar tudo funciona bem.

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

Eu tive um erro semelhante após a atualização do php. O PHP corrigiu um erro de segurança onde ohavia rwpermissão para o arquivo de soquete.

1. Abra /etc/php5/fpm/pool.d/www.confou /etc/php/7.0/fpm/pool.d/www.conf, dependendo da sua versão.

2. Remova o comentário de todas as linhas de permissão, como:

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

3. Reinicie o fpm - sudo service php5-fpm restartousudo service php7.0-fpm restart

Nota : se o servidor da web for executado como usuário que não seja www-data, você precisará atualizar o www.confarquivo de acordo

Todas as correções atualmente mencionadas aqui ativam basicamente a falha de segurança novamente.

O que acabei fazendo foi adicionar as seguintes linhas ao meu arquivo de configuração PHP-FPM.

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

Certifique-se de que www-data seja realmente o usuário em que o trabalhador nginx está executando. Para debian, é www-data por padrão.

Fazer dessa maneira não habilita o problema de segurança que essa alteração deveria corrigir .

A solução do @ Xander funciona, mas não persiste após uma reinicialização.

Eu descobri que eu tinha que mudar listen.modepara 0660no /etc/php5/fpm/pool.d/www.conf.

Amostra 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, eu mudei isso para o método mais seguro.

Eu removi o comentário para listen.mode, .group e .owner:

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

/ var / run Somente contém informações sobre o sistema em execução desde a última inicialização, por exemplo, usuários atualmente conectados e daemons em execução. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Nota:

Meus php5-fpm -vRelatórios: PHP 5.4.28-1+deb.sury.org~precise+1. O problema aconteceu após uma atualização recente também.

Se você tentou de tudo neste post, mas não está conseguindo fazer o PHP funcionar, é isso que o corrigiu no meu caso:

Certifique-se de ter estas linhas não comentadas em /etc/php5/fpm/pool.d/www.conf:

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

Certifique-se de que o / etc / nginx / fastcgi_params seja assim:

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;

Essas duas linhas estavam ausentes no meu / etc / nginx / fastcgi_params, verifique se estão lá!

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

Em seguida, reinicie o php5-fpm e o nginx. Deve fazer o truque.

De fato, "listen.mode" deve ser: "0660" e não "0666" como Outro gravável ou Outro legível nunca é uma boa opção aqui.

Portanto, tente descobrir qual usuário / grupo seu servidor Web executa. Eu uso o CentOs e ele roda como usuário "nginx". Portanto, adicione ao seu php-fpm.conf:

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

finalmente reinicie o php-fpm

Verifique qual usuário executa o nginx. A partir do Ubuntu 12.04, o nginx é executado pelo usuário do nginx, que não é membro do grupo www-data.

usermod -a -G www-data nginx

e reiniciar os daemons nginx e php5-fpm resolve o problema.

Alternativa à ampliação de permissões em sua configuração php, você pode alterar o usuário especificado em sua configuração nginx.

Na primeira linha do seu trecho nginx.conf acima, o usuário e o grupo são especificados como www e www, respectivamente.

user  www www;

Enquanto isso, sua configuração php provavelmente especifica um usuário e um grupo de www-data:

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

Você pode alterar a linha no seu nginx.conf para qualquer um dos seguintes:

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

Também é necessário considerar seus pools individuais do FPM, se houver.

Eu não conseguia descobrir por que nenhuma dessas respostas estava funcionando para mim hoje. Esse foi um cenário de esquecer e esquecer, onde esqueci que o listen.user e o listen.group eram duplicados por pool.

Se você usou pools para diferentes contas de usuário como eu, onde cada conta de usuário possui seus processos e soquetes do FPM, definir apenas as opções padrão de configuração listen.owner e listen.group para 'nginx' simplesmente não funcionará. E, obviamente, deixar que o 'nginx' possua todos eles também não é aceitável.

Para cada piscina , verifique se

listen.group = nginx

Caso contrário, você pode deixar a propriedade da piscina e tal sozinha.

Acabei de receber este erro novamente hoje quando atualizei minha máquina (com atualizações para PHP) executando o Ubuntu 14.04 . O arquivo de configuração da distribuição /etc/php5/fpm/pool.d/www.confestá bom e não requer nenhuma alteração atualmente.

Encontrei os seguintes erros:

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]

O estranho é que eu tenho dois sites em execução que utilizam o PHP-FPM nesta máquina, um estava funcionando bem e o outro (uma instalação Tiny Tiny RSS) me deu um 502, onde ambos estavam funcionando bem antes .

Comparei os dois arquivos de configuração e descobri que fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;estava faltando no site afetado.

Os dois arquivos de configuração agora contêm o seguinte bloco e estão funcionando corretamente novamente:

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

Atualizar

Deve-se notar que o Ubuntu envia dois arquivos de parâmetros relacionados ao fastcgi e também um trecho de configuração que está disponível desde o Vivid e também na versão PPA . A solução foi atualizada de acordo.

Diferença dos arquivos de parâmetro 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 de configuração em /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;

A seguinte correção simples funcionou para mim, ignorando possíveis problemas de permissões no soquete.

Na sua configuração nginx, defina fastcgi_pass como:

fastcgi_pass   127.0.0.1:9000;

Ao invés de

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

Isso deve corresponder ao parâmetro listen = em /etc/php5/fpm/pool.d/www.conf, portanto, configure-o também para:

listen = 127.0.0.1:9000;

Em seguida, reinicie o php5-fpm e o nginx

service php5-fpm restart

E

service nginx restart

Para obter mais informações, consulte: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

O problema no meu caso era que o servidor da web Nginx estava sendo executado como usuário nginx e o pool estava sendo executado como usuário www-data.

Resolvi o problema alterando o usuário em que o Nginx está executando no /etc/nginx/nginx.confarquivo (pode ser diferente no seu sistema, o meu é o Ubuntu 16.04.1)

Mudança: user nginx;

para: user www-data;

reinicie o Nginx: service nginx restart

Simples, mas funciona ..

listen.owner = nginx
listen.group = nginx

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

Corrigi o mesmo problema no Amazon Linux AMI 2016.09 (Centos 7), executando as seguintes etapas.

Abra seus arquivos www.conf (Exemplo: sudo nano /etc/php-fpm.d/www.conf) Por fim, encontre as linhas que definem o listen.owner e o listen.group e altere seus valores de "nobody" para "nginx ":

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

Por fim, encontre as linhas que definem o usuário e o grupo e altere seus valores de "apache" para "nginx":

user = nginx
group = nginx

Reinicie o php-fpm (serviço sudo reinicie o php-fpm)

A coisa mais importante aqui é qual usuário está usando o nginx, então você precisa especificá-lo também

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

no seu www.conf

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

no seu caso, o usuário e o grupo são "www"; basta substituí-lo.

• reinicie o nginx e o php fpm

Se você tiver um pool diferente por usuário, verifique se o usuário e o grupo estão definidos corretamente no arquivo de configuração. Você pode encontrar o usuário nginx no arquivo /etc/nginx/nginx.conf. O grupo nginx é igual ao usuário nginx.

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

Verifique também o SELINUX (/ etc / selinux):

# getenforce

Desligue isso:

# setenforce 0

No meu caso, o php-fpm não estava funcionando, então tive que iniciar o serviço?

service php7.3-fpm start
#on ubuntu 18.04

Basta ver o /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidarquivo IS PID

No arquivo /etc/php5/fpm/pool.d/www.conf

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

se você ouvir igual listen ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> configurações erradas e terminar o ajuste/etc/php5/fpm/pool.d/www.conf

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

Apenas para adicionar, no CentOS (e provavelmente Red Hat e Fedora) o arquivo para o qual alterar as permissões está em:

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

Após a atualização do Ubuntu 14.04 lts para o Ubuntu 16.04 lts, ​​encontrei mais uma razão para esse erro que não havia visto antes.

Durante o processo de atualização, de alguma forma, perdi meu executável php5-fpm por completo. Todos os arquivos de configuração estavam intactos e demorei um pouco para perceber queservice php5-fpm start realmente não iniciamos um processo, pois não mostrava nenhum erro.

Meu momento de despertar foi quando notei que não havia arquivo de soquete /var/run/php5-fpm.sock, como deveria haver, nemnetstat -an mostrava processos ouvindo a porta que tentei como alternativa enquanto tentava resolver esse problema. Como o arquivo / usr / sbin / php5-fpm também não existia, eu finalmente estava no caminho certo.

Para resolver esse problema, atualizei o php da versão 5.5 para 7.0. apt-get install php-fpmfez o truque como um efeito colateral. Depois disso e instalando outros pacotes necessários, tudo voltou ao normal.

Essa solução de atualização pode ter problemas próprios , no entanto. Como o php evoluiu bastante, é possível que o software se quebre de maneiras inimagináveis. Portanto, mesmo que eu tenha seguido esse caminho, você pode manter a versão de que gosta por mais algum tempo.

Felizmente, parece haver uma maneira legal de fazer isso , conforme descrito no site The Customize Windows:

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

Melhor solução, por mais que eu não tentei isso. Espero que os próximos dias me digam se devo.

Eu tive o erro semelhante.

Todas as recomendações não ajudaram.

A única substituição de www-data pelo nginx ajudou:

$ 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

Eu mudei o SO no meu servidor várias vezes tentando obter o sistema mais confortável.

Costumava funcionar muito bem na maioria das vezes, mas por fim recebi esse erro do 502 Gateway.

Eu uso um soquete php fpm para cada conta, em vez de manter o mesmo para todos. Portanto, se um travar, pelo menos os outros aplicativos continuarão em execução.

Eu costumava ter usuário e grupo www-data. Mas isso mudou no meu Debian 8 com o mais recente Nginx 1.8 e php5-fpm.

O usuário padrão é nginx e o grupo também. Para ter certeza disso, a melhor maneira é verificar os arquivos / etc / group e / etc / passwd. Estes não podem mentir.

Foi lá que descobri que agora tenho o nginx nos dois e não mais em www-data.

Talvez isso possa ajudar algumas pessoas ainda tentando descobrir por que a mensagem de erro continua aparecendo.

Funcionou para mim.

Para aqueles que tentaram de tudo neste tópico e ainda travaram: Isso resolveu meu problema. Atualizei /usr/local/nginx/conf/nginx.conf

1. Remova o comentário da linha dizendo user

2. faça com que www-datase torne:user www-data;

3. Salve (é necessário acesso root)

4. Reinicie o nginx

Se você tiver declarações

pid = /run/php-fpm.pid

e

listen = /run/php-fpm.pid

em diferentes arquivos de configuração, o root será o proprietário desse arquivo.