Все исправления, упоминаемые здесь, в основном позволяют снова включить дыру в системе безопасности.

В результате я добавил следующие строки в свой конфигурационный файл PHP-FPM.

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

Убедитесь, что www-data на самом деле является пользователем, с которым работает nginx. Для debian это www-data по умолчанию.

Выполнение этого способа не включает проблему безопасности которую должно было исправить это изменение.

Решение @Xander работает, но не сохраняется после перезагрузки.

Я обнаружил, что мне пришлось изменить listen.mode на 0660 в /etc/php5/fpm/pool.d/www.conf.

Пример из 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

Изменить: В @Chris Burgess я изменил это на более безопасный метод.

Я удалил комментарий для listen.mode,.group и .owner:

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

/var/run Только содержит информацию о запущенной системе с момента последней загрузки, например, в настоящее время вошедшие в систему пользователи и запущенные демоны. (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure).

Боковое примечание:

My php5-fpm -v Отчеты: PHP 5.4.28-1+deb.sury.org~precise+1. Проблема также возникла после недавнего обновления.

Если вы пробовали все в этом посте, но не добились успеха в работе PHP, это то, что исправлено для моего случая:

Удостоверьтесь, что эти строки не указаны в файле /etc/php 5/fpm/pool.d/www.conf:

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

Убедитесь, что /etc/nginx/fastcgi _params выглядит следующим образом:

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;

Эти две строки отсутствовали в моем /etc/nginx/fastcgi _params, убедитесь, что они там!

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

Затем перезапустите php5-fpm и nginx. Должен сделать трюк.

Фактически, "listen.mode" должен быть: "0660", а не "0666", поскольку Other Writable или Other Readable никогда не является хорошим выбором здесь.

Итак, попробуйте выяснить, какой пользователь/группа запускает ваш веб-сервер. Я использую CentOs и работает как пользовательский "nginx" Поэтому добавьте в свой php-fpm.conf:

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

наконец перезапустить php-fpm

Проверьте, какой пользователь запускает nginx. Начиная с Ubuntu 12.04 nginx запускается пользователем nginx, который не является членом группы www-data.

usermod -a -G www-data nginx

и перезапуск демонов nginx и php5-fpm решает проблему.

Альтернатива расширению разрешений в вашем php config, вы можете изменить пользователя, указанного в вашей конфигурации nginx.

В первой строке выдержки из nginx.conf выше пользователь и группа указаны как www и www соответственно.

user  www www;

Между тем, ваш php config, вероятно, указывает пользователя и группу www-данных:

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

Вы можете изменить строку в своем nginx.conf на любое из следующих, а затем:

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

Я снова получил эту ошибку сегодня, когда обновляю свою машину (с обновлениями для PHP) с Ubuntu 14.04. Конфигурационный файл дистрибутива /etc/php5/fpm/pool.d/www.conf в порядке и не требует изменений.

Я обнаружил следующие ошибки:

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]

Странно, что у меня есть 2 сайта, на которых используется PHP-FPM на этом компьютере, и все работает нормально, а другая (установка Tiny Tiny для RSS) дала мне 502, где оба раньше работали.

Я сравнил оба файла конфигурации и обнаружил, что fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; отсутствует для затронутого сайта.

Оба файла конфигурации теперь содержат следующий блок и снова работают нормально:

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

Update

Следует отметить, что Ubuntu отправляет два файла параметров связанных с fastcgi, а также фрагмент конфигурации, который доступен с Vivid, а также в PPA, Решение было соответствующим образом обновлено.

Diff файлов параметров 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;

фрагмент конфигурации в /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 скрипт 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;

Следует учитывать также ваши индивидуальные пулы FPM, если они есть.

Я не мог понять, почему ни один из этих ответов не работал на меня сегодня. Для меня это был сценарий "забыл" и "забыл", когда я забыл, что listen.user и listen.group были дублированы для каждого пула.

Если вы использовали пулы для разных учетных записей пользователей, как я, где каждая учетная запись пользователя владеет их процессами и сокетами FPM, установка только параметров конфигурации listen.owner и listen.group по умолчанию для "nginx" просто не будет работать. И, очевидно, не допустим, чтобы "nginx" принадлежал им всем.

Для каждого пула убедитесь, что

listen.group = nginx

В противном случае вы можете оставить пул и один.

В моем случае проблема заключалась в том, что веб-сервер Nginx работал как пользователь nginx, а пул работал как пользовательские www-данные.

Я решил проблему, изменив пользовательский Nginx, запущенный в файле /etc/nginx/nginx.conf (может быть другим в вашей системе, мой Ubuntu 16.04.1)

Изменение: user nginx;

to: user www-data;

затем перезапустите Nginx: service nginx restart

Следующее простое исправление работало для меня, минуя возможные проблемы с разрешениями сокета.

В вашей конфигурации nginx установите fastcgi_pass для:

fastcgi_pass   127.0.0.1:9000;

Вместо

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

Это должно соответствовать параметру listen = в /etc/php 5/fpm/pool.d/www.conf, поэтому также установите для этого значение:

listen = 127.0.0.1:9000;

Затем перезапустите php5-fpm и nginx

service php5-fpm restart

и

service nginx restart

Для получения дополнительной информации см. https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

У меня исправлена ​​такая же проблема на Amazon Linux AMI 2016.09 (Centos 7), выполнив следующие шаги.

Откройте файлы www.conf (пример: sudo nano/etc/php-fpm.d/www.conf) Наконец, найдите строки, которые устанавливают listen.owner и listen.group и изменяют их значения от "nobody" до "nginx":

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

Наконец, найдите строки, которые устанавливают пользователя и группу, и изменяют их значения от "apache" до "nginx":

user = nginx
group = nginx

Перезапустить php-fpm (перезагрузка sudo service php-fpm)

Просто, но работает.

listen.owner = nginx
listen.group = nginx

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

Также проверьте SELINUX (/etc/selinux):

# getenforce

выключи:

# setenforce 0

После обновления с Ubuntu 14.04 lts до Ubuntu 16.04 lts я нашел еще одну причину этой ошибки, которую я раньше не видел.

Во время процесса обновления я каким-то образом полностью потерял исполняемый файл php5-fpm. Все конфигурационные файлы были неповрежденными, и мне потребовалось некоторое время, чтобы понять, что service php5-fpm start действительно не запускал процесс, так как он не показывал никаких ошибок.

Мой момент пробуждения состоял в том, что я заметил, что в /var/run/php5-fpm.sock не было файла сокета, как и должно было быть, а также netstat -an показывать процессы, прослушивающие порт, которые я пытался в качестве альтернативы, пытаясь решить эту проблему, Так как файл /usr/sbin/php 5-fpm также не существовал, я, наконец, оказался на правильном пути.

Чтобы решить эту проблему, я обновил php с версии 5.5 до 7.0. apt-get install php-fpm сделал трюк как побочный эффект. После этого и установки других необходимых пакетов все было в порядке.

Однако это решение для модернизации может иметь проблемы. Поскольку php развивается совсем немного, возможно, что программное обеспечение будет немыслимым. Итак, хотя я и пошел по этому пути, вы можете захотеть сохранить версию, которую вы любите, на какое-то время.

К счастью, кажется, для этого оптимальный способ, как описано в разделе "Настроить Windows":

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

Neater решение, как могло бы быть, я этого не делал. Я ожидаю, что следующие пару дней скажут мне, должен ли я иметь.

Самое главное, что пользователь использует nginx, тогда вам нужно также указать его

в вашем 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;
        }

в вашем www.conf

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

в вашем случае пользователь и группа "www", поэтому просто замените его.

• перезапустите nginx и php fpm

Если у вас есть объявления

pid =/run/php-fpm.pid

и

listen =/run/php-fpm.pid

в разных конфигурационных файлах, тогда root будет владельцем этого файла.

Тем, кто пробовал все в этой теме и все еще застрял: Это решило мою проблему. Я обновил /usr/local/nginx/conf/nginx.conf

• Раскомментируйте строку, говорящую user

• сделайте его www-data, чтобы он стал: user www-data;

• Сохраните его (требуется root-доступ)

• Перезагрузите nginx

Если у вас есть отдельный пул на пользователя, убедитесь, что пользователь и группа правильно настроены в файле конфигурации. Пользователь nginx можно найти в файле /etc/nginx/nginx.conf. Группа nginx такая же, как и пользователь nginx.

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

Я несколько раз менял ОС на своем сервере, пытаясь получить самую удобную систему.

Он работал очень хорошо большую часть времени, но, наконец, я получил эту ошибку Gateway 502.

Я использую php fpm socket для каждой учетной записи, а не для одного. Поэтому, если один сбой, по крайней мере другие приложения продолжают работать.

У меня были пользовательские и групповые www-данные. Но это изменилось на моем Debian 8 с последними версиями Nginx 1.8 и php5-fpm.

Пользователь по умолчанию - nginx, а также группа. Чтобы убедиться в этом, лучше всего проверить файлы /etc/group и/etc/passwd. Они не могут лгать.

Именно там я обнаружил, что теперь у меня есть nginx в обоих и уже не www-data.

Возможно, это может помочь некоторым людям по-прежнему пытаться выяснить, почему сообщение об ошибке продолжается.

Это сработало для меня.

Чтобы добавить, на CentOS (и, возможно, Red Hat и Fedora) файл для изменения разрешений находится по адресу:

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