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

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

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

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

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

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

я обнаружил, что должен измениться listen.mode to 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.д/ВСП.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. Должны сделать трюк.

поэтому попробуйте узнать, какой пользователь / группа работает на вашем веб-сервере. Я использую 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.д/ВСП.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.д/ВСП.conf) Наконец, найдите строки, которые задают listen.хозяин и слушает.сгруппируйте и измените их значения с " никто "на"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;

в: 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, так как там должно быть, и не было!--3--> показать процессы, прослушивающие порт, который я пробовал в качестве альтернативы, пытаясь решить эту проблему. Поскольку файл / 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.д/ВСП.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/местные/nginx в/конф/с nginx.conf

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

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

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

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

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

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

и

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

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