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

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

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

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

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

Решение @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 и .владельца:

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

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

Примечание сбоку:

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

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

Убедитесь, что эти строки раскомментированы в файле /etc/php5/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", так как другие доступные для записи или другие доступные для чтения здесь никогда не являются хорошим выбором.

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

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

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

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

Мод пользователя -a-G www-данные nginx

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

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

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

user  www www;

Между тем, ваша конфигурация php, вероятно, указывает пользователя и группу 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

Необходимо также учитывать ваши индивидуальные пулы FPM, если таковые имеются.

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

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

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

listen.group = nginx

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

Я только что снова получил эту ошибку сегодня, когда обновил свою машину (с обновлениями для 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 на этой машине, один работал нормально, а другой (крошечная установка 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;
}

Обновление

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

Разница в файлы параметров 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 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;

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

В конфигурации nginx установите значение fastcgi_pass в:

fastcgi_pass   127.0.0.1:9000;

Вместо

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

Это должно соответствовать параметру listen = в /etc/php5/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/

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

listen.owner = nginx
listen.group = nginx

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

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

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

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

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

user = nginx
group = nginx

Перезапустить php-fpm (служба sudo php-fpm перезапуск)

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

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

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

К: user www-data;

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

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

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

Мой момент пробуждения наступил, когда я заметил, что в /var/run/php5-fpm.sock нет файла сокета, как и должно быть, и не было netstat -an покажите процессы, прослушивающие порт, который я пробовал в качестве альтернативы, пытаясь решить эту проблему. Поскольку файл /usr/sbin/php5-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

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

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

# getenforce

Выключите его:

# setenforce 0

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Раскомментируйте строку со словами user

2. Сделайте это www-data так, чтобы это стало: user www-data;

3. Сохраните его (требуется корневой доступ)

4. Перезапустить nginx

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

Pid= /выполнить/php-fpm.pid

И

Слушать =/выполнить/php-fpm.pid

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