Панели хостинга Linux; Nginx / Apache / PHP-FPM (в зависимости от панели)

Панель управления хостингом: после перезапуска служба теряет доступ к сокету

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

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

Если сайт работает до перезапуска, а затем получает 502 или permission denied при подключении к *.sock, нужно проверить владельца, группу и способ создания сокета из конфигурации пула PHP-FPM.

В этой статье
  1. Симптом и границы применимости
  2. Возможные причины и признаки
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась
  6. Безопасный откат

#Симптом и границы применимости

Если сайт работает до перезапуска, а затем получает 502 или permission denied при подключении к *.sock, нужно проверить владельца, группу и способ создания сокета из конфигурации пула PHP-FPM.

Эта инструкция относится к конкретному сайту в панели управления хостингом, когда его обслуживают Nginx, Apache, PHP-FPM или их сочетание. Названия разделов и доступность SSH зависят от установленной панели и прав пользователя; шаги, которых нет в вашем интерфейсе, выполняет администратор сервера.

#Возможные причины и признаки

Возможная причинаКак узнатьЧто делать
Неправильный владелец сокетаСокет создаётся процессом PHP-FPM с группой, недоступной Nginx/ApacheВ error_log connect() ... failed (13: Permission denied)Настроить listen.owner и listen.group либо ACL
Несовпадающий путьПанель пересоздала пул под новым именемNginx ищет отсутствующий *.sockСопоставить fastcgi_pass и listen
Остаточные права на каталогРодительский каталог недоступен рабочему пользователюПрава на сокет нормальные, но соединения нетПроверить выполнение прохода к каталогу

#Пошаговая диагностика и исправление

  1. Запишите сообщение об ошибкеОткройте страницу один раз после перезапуска. В журнале сайта найдите точную строку про upstream socket и код ошибки: No such file (2) означает другой сценарий, чем Permission denied (13). Не меняйте chmod без этого различия.
  1. Найдите текущий путь сокетаВ панели узнайте обработчик PHP и пользовательский пул. По SSH изучите действующую конфигурацию fastcgi_pass/proxy_fcgi и listen соответствующего пула; в разных сборках они расположены в разных каталогах.
  1. Посмотрите фактические права сокетаЧерез SSH проверьте путь и группу файла сокета и каталог, в котором он появляется. Директория /run может пересоздаваться после перезапуска; поэтому ручной chown сокета исчезнет при следующем запуске.
  2. Пример для Debian, SSH с административными правами
    Linux · Терминал (Bash)КомандаНужен sudo
    Пример для Debian, SSH с административными правами. Если панель использует другой путь, сначала найдите его и подставьте вместо /run/php.
    sudo ls -ld /run/php
    sudo find /run/php -maxdepth 1 -type s -ls
  1. Уточните пользователя фронтендаПроверьте, под каким пользователем работают Nginx или Apache, и какой пользователь/группа назначены пулу PHP. Не делайте предположения, что имя всегда www-data: панели создают отдельных пользователей сайтов.
  1. Исправьте конфигурацию создания сокетаЕсли у пула Unix-сокет, проверьте listen.owner, listen.group, listen.mode или ACL согласно его версии PHP-FPM. Меняйте только параметры выбранного пула через предусмотренное в панели место и сохраните старые значения. Не назначайте сокету 0777.
  1. Проверьте конфигурацию пулаДо перезапуска выполните тест выбранной версии PHP-FPM; параметры -t и имя бинарника могут отличаться. Если тест не проходит, исправьте конфигурацию и не перезапускайте процесс.
  2. Дополнительная команда по теме
    Linux · Терминал (Bash)КомандаНужен sudo
    Пример лишь для установленного php-fpm8.2 на Debian-подобной системе; замените бинарник на фактический. Права администратора.
    sudo php-fpm8.2 -t
  1. Проверьте после контролируемого перезапускаЧерез панель или systemd перезапустите только нужную службу в окно обслуживания. Снова проверьте владельца *.sock и страницу. При повторной ошибке восстановите конфигурацию пула; повторное ручное изменение прав вместо исправления источника не помогает.

#Проверка результата

После перезапуска сокет создаётся с правильным путём и доступными фронтенду правами, сайт отвечает без 502.

#Если проблема осталась

Если сокет существует и права верны, проверьте ограничения SELinux/AppArmor и сообщения journald; если сокет отсутствует, смотрите ошибки старта пула PHP-FPM.

#Безопасный откат

Если после изменения ошибка усилилась, верните сохранённое значение только изменённого параметра и повторно проверьте конфигурацию используемого веб-сервера до применения. Не возвращайте всю базу или весь сервер из резервной копии, если достаточно откатить одну настройку. При отсутствии доступа к нужному уровню обратитесь к администратору с точными временем, адресом, кодом ответа и обезличенными фрагментами журналов.

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

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

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