У меня была аналогичная ошибка после обновления php. PHP исправил ошибку безопасности, где o имело разрешение rw на файл сокета.

1. Откройте /etc/php5/fpm/pool.d/www.conf или /etc/php/7.0/fpm/pool.d/www.conf , в зависимости от вашей версии.

2. Раскомментируйте все строки разрешений, например:

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

3. Перезапустить fpm – sudo service php5-fpm restart или sudo service php7.0-fpm restart

Примечание . Если ваш веб-сервер работает как пользователь, отличный от www-данных, вам необходимо обновить файл www.conf соответственно

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

То, что я закончил, заключается в добавлении следующих строк в файл конфигурации 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 .

Образец из http://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.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 ).

Примечание:

Мои php5-fpm -v Reports: 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», поскольку 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-data:

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

Обновить

Следует отметить, что 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/

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

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

Мой момент пробуждения состоял в том, что я заметил, что в файле /var/run/php5-fpm.sock не было файла /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 

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

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

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

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

to: user www-data;

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

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

 listen.owner = nginx listen.group = nginx chown nginx:nginx /var/run/php-fpm/php-fpm.sock 

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

Откройте ваши файлы http://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 php-fpm)

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

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

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

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

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

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

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

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

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

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

Если у вас есть отдельный пул на пользователя, убедитесь, что пользователь и группа правильно настроены в файле конфигурации. Пользователь 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. Сохраните его (необходим root-доступ)

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

Если у вас есть декларации

pid = /run/php-fpm.pid

а также

listen = /run/php-fpm.pid

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