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

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

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

убедитесь, что www-data на самом деле является пользователем, от имени которого работает nginx worker. Для 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

Edit: Per @Chris Burgess, я изменил это на более безопасный метод.

Я удалил комментарий для прослушивания.режим. ,группа и. владелец:

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. Должны сделать трюк.

на самом деле, " слушай.режим "должен быть: "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-data.

usermod-A-G www-data nginx

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

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

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

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

Если вы использовали пулы для разных учетных записей пользователей, как я, где каждая учетная запись пользователя владеет своими процессами FPM и сокетами, устанавливая только прослушивание по умолчанию.владелец и слушать.параметры конфигурации группы для "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 версия. Решение было доработано.

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 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.конф) Наконец, найдите строки, которые устанавливают прослушивание.хозяин и слушать.группируйте и меняйте свои значения с " nobody "на"nginx":

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

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

user = nginx
group = nginx

перезапустить php-fpm (sudo сервис php-fpm restart)

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

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

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

to: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 и рнр5-тефлон.

пользователь по умолчанию-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/local/nginx/conf / nginx.conf

1. раскомментируйте строку:user

2. сделать www-data так это будет: user www-data;

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

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

Если у вас есть заявления

pid = / run / php-fpm.пид

и

listen = / run / php-fpm.пид

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