Железо и софт • 06.06.2026
Nginx выдает ошибку 502 Permission denied к сокету php fpm sock как исправить
Развернул веб-сервер Nginx в связке с PHP-FPM на сервере под управлением Linux. При попытке зайти на сайт в браузере вылетает ошибка «502 Bad Gateway», а в логах конфигурации веб-сервера (/var/log/nginx/error.log) бесконечно сыплется лог сбоя: «[crit] connect() to unix:/var/run/php-fpm.sock failed (13: Permission denied)». При этом сама фоновая служба PHP работает исправно и сокет физически существует в директории. Подскажите, из-за каких скрытых ограничений прав доступа ломается связь между веб-сервером и интерпретатором скриптов, и как правильно настроить параметры безопасности, чтобы исправить этот сетевой ступор?
Ответы (5)
Алексей Админ
Привет! Ошибка "13: Permission denied" означает классический конфликт прав доступа Unix-системы. Процесс Nginx обычно запускается под пользователем `www-data` или `nginx`, а фоновый пул PHP-FPM может работать от имени пользователя `php-fpm` или `root`. Когда веб-сервер пытается передать входящий веб-запрос на обработку интерпретатору через локальный файл-сокет, операционная система блокирует это действие, так как у группы пользователя веб-сервера банально нет прав на чтение и запись в этот конкретный файл. Сокет есть, но мост связи заблокирован на уровне ядра.
Денис Опс
Чтобы принудительно выставить правильные права на файл сокета и разблокировать передачу пакетов между серверами, настройте конфигурационный файл пула по шагам:
1. Подключитесь к серверу по SSH и откройте файл настроек пула (обычно это `www.conf`) через редактор nano от имени суперпользователя: `sudo nano /etc/php/8.x/fpm/pool.d/www.conf` (замените 8.x на вашу актуальную версию).
2. Нажмите сочетание клавиш Ctrl + W и найдите блок строк, начинающихся с префикса `listen.owner`.
3. Раскомментируйте эти строки (уберите точку с запятой в начале) и принудительно пропишите туда пользователя веб-сервера: `listen.owner = www-data` и `listen.group = www-data`.
4. Чуть ниже найдите параметр `listen.mode` и установите для него маску прав доступа: `listen.mode = 0660`.
5. Сохраните документ (Ctrl + O, Enter, Ctrl + X) и принудительно отправьте службу на перезапуск командой: `sudo systemctl restart php8.x-fpm`.
Михаил Системщик
Ребята, если вы выставили права www-data на сокет, а ошибка 502 Bad Gateway продолжает намертво висеть в логах, проверяйте статус встроенных модулей принудительного контроля безопасности (например, SELinux на CentOS/RHEL или AppArmor на Ubuntu). Эти подсистемы блокируют сетевое взаимодействие процессов, даже если стандартные права доступа к файлу сокета настроены идеально. Они видят, что сторонний демон лезет в папку `/var/run/` и сбрасывают сессию. Переведите модуль SELinux в режим аудита командой `setenforce 0`, чтобы проверить эту гипотезу.
Никита Линукс
Если виновником блокировки сокетов со стороны Nginx является активный режим SELinux, отключать его полностью в продакшене нельзя. Нужно выдать правильный тип контекста по инструкции:
1. Запустите консоль сервера с правами root-доступа.
2. Проверьте текущий контекст безопасности мешающего файла сокета командой: `ls -Z /var/run/php-fpm.sock`.
3. Задайте файлу правильный тип контекста, разрешающий веб-серверам чтение и запись потока: `sudo chcon -t httpd_sys_content_t /var/run/php-fpm.sock`.
4. Чтобы это правило не слетело после первой же перезагрузки ОС, зафиксируйте его в системной базе данных командой: `sudo semanage fcontext -a -t httpd_sys_content_t "/var/run/php-fpm.sock"`.
5. Перезапустите веб-сервер `sudo systemctl restart nginx` для очистки внутренних дескрипторов портов.
Роман Кодер
Чтобы вообще раз и навсегда забыть про любые проблемы со сложными Unix-правами доступа к файлам сокетов, ограничениями AppArmor и заклинившими масками владельцев папок, переведите стек на работу через стандартные локальные TCP-порты. Измените строку `listen = /var/run/...` в настройках PHP на `listen = 127.0.0.1:9000`. Соответственно, в конфигурационном блоке `fastcgi_pass` внутри Nginx укажите этот же сетевой адрес. Сетевой трафик пойдет через внутреннюю петлю localhost без каких-либо сбоев файловой системы.