PHP-FPM Linux

PHP-FPM: connect() to unix socket failed (13: Permission denied)

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

Ошибка «connect() to unix:/run/php/php-fpm.sock failed (13: Permission denied)» исправляется настройкой listen.owner, listen.group и listen.mode в пуле PHP-FPM под пользователя nginx, проверкой пути сокета и SELinux.

В этой статье
  1. Что означает ошибка
  2. Причины и решения
  3. Пошаговое решение

#Что означает ошибка

Сообщение
connect() to unix:/run/php/php-fpm.sock failed (13: Permission denied) while connecting to upstream

Nginx обращается к PHP-FPM через unix-сокет. Ошибка (13: Permission denied) означает, что у пользователя, от которого работает nginx, нет прав на файл сокета. Сокет создаёт PHP-FPM с владельцем и режимом, заданными в пуле (listen.owner, listen.group, listen.mode). Если nginx запущен от другого пользователя или группы, доступ запрещён. Посетитель видит 502 Bad Gateway.

#Причины и решения

Возможная причинаКак узнатьЧто делать
Неверные listen.owner и listen.groupСокет принадлежит другому пользователю.ls -l показывает иного владельца.Задайте владельца.
Другой пользователь у nginxnginx работает от nginx, а сокет для www-data.ps показывает иного пользователя.Согласуйте.
Неверный путь сокетаПути в nginx и PHP-FPM различаются.Сокет не существует.Исправьте путь.
SELinux блокируетКонтекст неверен.В журнале AVC.Исправьте контекст.

#Пошаговое решение

  1. Прочитайте ошибкуПо SSH выполните sudo tail -n 40 /var/log/nginx/error.log и найдите строку connect() to unix:/... failed (13: Permission denied). Выпишите точный путь сокета и время; сообщение может относиться не к Nginx→PHP, а к другому backend. Отдельно проверьте журнал PHP-FPM, чтобы не принять отсутствующий сокет за неверные разрешения.
  2. Найдите сокетВыполните ls -l /run/php/ или stat /фактический/путь/к/сокету, подставив путь из журнала. В выводе посмотрите владельца, группу и режим сокета; файл может пересоздаваться после запуска пула. Если сокета нет, проверяйте работающую службу и параметр listen, а не меняйте права на несуществующий объект.
  3. Определите пользователя nginxНайдите директиву user в основном конфигурационном файле Nginx через sudo nginx -T 2>/dev/null | head -n 30. На Debian/Ubuntu часто это www-data, на других системах — nginx либо другой пользователь; на панели хостинга схема может отличаться. Выясните, в какую группу он входит (id имя_пользователя) и может ли открыть сокет.
  4. Проверьте пулОткройте файл конфигурации нужного пула PHP-FPM (/etc/php/8.2/fpm/pool.d/www.conf — пример, версия должна совпадать с вашей) и найдите listen, listen.owner, listen.group, listen.mode. Сравните путь с fastcgi_pass в Nginx и права с его системным пользователем. Сохраните копию перед любыми правками.
  5. Задайте праваЕсли подтверждён отказ чтения сокета, настройте группу и разрешения по модели сервера: например, listen.owner = www-data, listen.group = www-data, listen.mode = 0660 только когда Nginx действительно работает под www-data. Не задавайте режим 0666 и не исправляйте разрешения вручную на временном файле сокета; после перезапуска их установит FPM.
  6. Проверьте путьВ конфигурации сайта найдите fastcgi_pass unix:/run/php/...sock; и сравните символ в символ с listen нужного пула. При работе через TCP вместо сокета адрес и порт тоже должны совпадать. Если у одного домена собственный пул, не перенаправляйте его на общий пул без понимания изоляции сайтов. После исправления выполните nginx -t и проверку конфигурации PHP-FPM.
  7. Перезапустите службыСначала выполните sudo php-fpm8.2 -t (или установленную команду проверки вашей версии), затем штатно перезагрузите PHP-FPM, если меняли пул. Для Nginx выполните sudo nginx -t && sudo systemctl reload nginx; не делайте restart nginx без необходимости. Откройте проблемную страницу и новый error.log; при ошибке верните конфигурацию из копии.
  8. Проверьте SELinuxНа RHEL/AlmaLinux/Rocky при SELinux Enforcing изучите журнал AVC через sudo ausearch -m AVC -ts recent и контексты сокета ls -Z. При подтверждённом отказе исправляйте политику и контекст по документации дистрибутива; не выключайте SELinux и не применяйте restorecon -Rv к неизвестному каталогу без проверки политики. На Debian проверьте AppArmor, если установлен.
  9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Проверка сокета и перезапуск служб.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Проверка сокета и перезапуск служб.
    ls -l /run/php/
    sudo nginx -t
    sudo php-fpm8.2 -t
    # После правки используйте штатный reload конкретной службы, если проверка прошла.

    Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

    Вариант 2Пример файла или настройки
    INI
    ; /etc/php/8.2/fpm/pool.d/www.conf
listen = /run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Если вы изменили версию PHP, не забудьте обновить имя сокета в конфигурации nginx (php8.3-fpm.sock). Для нескольких сайтов создавайте отдельные пулы и сокеты, а группу nginx добавьте в группу пула (usermod -aG). Альтернатива сокету — TCP (listen = 127.0.0.1:9000), она проще в настройке, но чуть медленнее и открыта локально. После изменений проверьте работу сайта и журнал ошибок. Для CentOS и AlmaLinux при включённом SELinux может понадобиться setsebool -P httpd_can_network_connect 1. Справка — PHP-FPM: конфигурация.

Так эту ошибку тоже называют

PHP-FPM: server reached pm.max_children setting — причины и решение Предупреждение PHP-FPM «server reached pm.max_children setting» означает, что все процессы заняты. Рассчитайте max_children по памяти, найдите долгие запросы через slowl… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: как рассчитать pm.max_children по памяти — причины и решение Предупреждение pm.max_children reached в PHP-FPM означает исчерпание пула процессов. Рассчитайте max_children по доступной памяти и среднему размеру процесса, выберите р… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: запросы выполняются медленно, в логе slowlog — причины и решение Медленные запросы и таймауты в PHP-FPM (502/504) исправляются включением slowlog, настройкой request_terminate_timeout, fastcgi_read_timeout в nginx, оптимизацией запрос… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: server reached pm.max_children и ответы 503/504 — причины и решение Предупреждение значит, что все процессы заняты. Найдите медленные запросы, увеличьте max_children при наличии памяти и включите кэширование. Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM не запускается: ERROR: unable to bind listening socket — причины и решение Служба не стартует при занятом порте/сокете или ошибке конфигурации. Проверьте php-fpm -t и журнал. Сайты, серверы и хостинг PHP-FPM Linux

Источники и обновления

Последнее обновление статьи: 1 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.