PHP-FPM sock failed: как найти причину и восстановить работу сайта

Если Nginx не может подключиться к PHP-FPM через Unix-сокет, сайт часто перестаёт выполнять PHP и начинает возвращать 502 Bad Gateway.

В журнале Nginx при этом можно увидеть ошибку, связанную с подключением к файлу вида:

/run/php/php8.3-fpm.sock

или:

/run/php-fpm/www.sock

Главное — не начинать с перезапуска всего сервера или выдачи прав 777.

Сначала нужно понять, существует ли сокет, слушает ли его PHP-FPM и совпадает ли этот путь с настройкой Nginx.

PHP-FPM действительно поддерживает работу через Unix-сокеты, а Nginx позволяет передавать FastCGI-запросы на сокет через fastcgi_pass unix:....

Сначала найдите путь, который использует Nginx

Посмотрите итоговую конфигурацию Nginx:

nginx -T

Найдите директиву:

fastcgi_pass

Например:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Или PHP-FPM может быть подключён через TCP:

fastcgi_pass 127.0.0.1:9000;

Это два разных способа подключения.

Официальная документация Nginx прямо допускает в fastcgi_pass как адрес и порт, так и путь Unix-сокета.

Если используется Unix-сокет, сохраните точный путь из конфигурации. Именно его дальше нужно сравнивать с настройкой PHP-FPM.

Проверьте, какой сокет создаёт PHP-FPM

У каждого пула PHP-FPM есть параметр:

listen =

Например:

listen = /run/php/php8.3-fpm.sock

или:

listen = 127.0.0.1:9000

PHP-FPM позволяет разным пулам слушать разные сокеты или порты. Это одна из штатных возможностей FPM.

Точный путь к файлам конфигурации зависит от системы и способа установки PHP.

Часто конфигурации пулов находятся в каталогах вроде:

/etc/php/8.x/fpm/pool.d/

или:

/etc/php-fpm.d/

Но не подставляйте путь из примера вслепую.

Нужно найти фактический параметр listen на конкретном сервере.

Пути Nginx и PHP-FPM должны совпадать

Допустим, в Nginx указано:

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

а PHP-FPM настроен так:

listen = /run/php/php8.3-fpm.sock

В таком случае Nginx пытается подключиться совсем не туда, где слушает PHP-FPM.

Это часто возникает после:

• смены версии PHP;
• установки новой версии PHP-FPM;
• удаления старой версии;
• изменения конфигурации пула;
• переноса конфигурации с другого сервера.

Исправлять нужно не «сокет вообще», а привести обе стороны к одному реальному адресу:

Nginx → тот же socket/port ← PHP-FPM.

Если сокета вообще нет

Проверьте сам файл:

ls -l /run/php/

или конкретный путь:

ls -l /run/php/php8.3-fpm.sock

Если файла нет, возможны несколько причин:

• PHP-FPM не запущен;
• нужный пул не запустился;
• используется другой путь;
• используется другая версия PHP;
• FPM работает через TCP, а Nginx ждёт Unix-сокет;
• конфигурация PHP-FPM содержит ошибку.

Сначала определите, какой именно PHP-FPM установлен и запущен.

Не стоит сразу создавать пустой файл .sock вручную. Unix-сокет создаётся работающим процессом PHP-FPM, а обычный файл с таким именем проблему не решит.

Проверьте, работает ли PHP-FPM

На серверах с systemd сначала найдите фактический сервис PHP-FPM, потому что его имя зависит от системы и установленной версии PHP.

Например, можно посмотреть список сервисов:

systemctl list-units --type=service | grep -i fpm

После этого проверить найденный сервис:

systemctl status ИМЯ_СЕРВИСА

Если PHP-FPM не запущен, сначала нужно выяснить причину его остановки.

Не ограничивайтесь командой restart.

Если FPM не может стартовать из-за неправильной конфигурации, простой перезапуск снова закончится той же ошибкой.

Проверьте конфигурацию PHP-FPM перед перезапуском

PHP-FPM поддерживает тест конфигурации через параметр -t.

В зависимости от установки бинарный файл может называться, например:

php-fpm

или содержать номер версии.

Используйте фактический бинарный файл своего PHP-FPM, а не случайную команду из инструкции для другого дистрибутива.

Если проверка показывает ошибку, сначала исправьте конфигурацию и только затем перезапускайте сервис.

Если сокет существует, проверьте права

Другой распространённый случай: файл сокета существует, но Nginx не имеет права к нему подключиться.

Посмотрите:

ls -l /run/php/php8.3-fpm.sock

Для Unix-сокетов PHP-FPM существуют специальные настройки:

listen.owner
listen.group
listen.mode

Например:

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

Это только пример — нужный пользователь и группа зависят от сервера.

Официальная документация PHP указывает, что в Linux веб-серверу необходимы права чтения и записи на Unix-сокет; эти права как раз задаются параметрами listen.owner, listen.group и listen.mode.

Поэтому решение:

chmod 777 ...

не является нормальной диагностикой.

Нужно определить, от какого пользователя работает Nginx, и настроить доступ PHP-FPM корректно.

Не забудьте про ACL

PHP-FPM также поддерживает:

listen.acl_users
listen.acl_groups

Если для сокета настроены POSIX ACL, параметры listen.owner и listen.group могут игнорироваться.

Поэтому ситуация:

> owner и group выглядят правильно, но доступ всё равно работает не так, как ожидается

требует проверки полной конфигурации пула, а не только одной строки listen.mode.

Если ошибка появилась после обновления PHP

Это особенно характерный сценарий.

Допустим, раньше сервер использовал:

/run/php/php8.2-fpm.sock

после обновления работает:

/run/php/php8.3-fpm.sock

а в конфигурации Nginx осталась старая версия.

Тогда PHP-FPM может быть полностью исправен, но Nginx продолжит обращаться к несуществующему сокету.

Порядок проверки:

1. посмотреть fastcgi_pass в Nginx;
2. посмотреть listen в активном FPM-пуле;
3. сравнить пути;
4. проверить существование сокета;
5. только потом менять конфигурацию.

Не угадывайте номер версии PHP по памяти.

Если используется TCP, сокет искать не нужно

Иногда PHP-FPM настроен так:

listen = 127.0.0.1:9000

а Nginx:

fastcgi_pass 127.0.0.1:9000;

Это штатная схема.

В таком случае отсутствие .sock вообще не является проблемой.

PHP-FPM поддерживает прослушивание TCP, а для TCP также существует параметр listen.allowed_clients, ограничивающий клиентов FastCGI.

Поэтому сначала всегда определяйте фактическую схему подключения:

Unix socket или TCP.

Если файл есть, но соединение всё равно не устанавливается

Сам факт наличия .sock ещё не доказывает, что через него сейчас нормально принимает соединения рабочий PHP-FPM.

Нужно проверить:

• запущен ли FPM;
• активен ли нужный pool;
• совпадает ли socket path;
• корректны ли права;
• нет ли ошибки в журнале PHP-FPM;
• не остался ли путь от старой версии PHP.

Полезнее искать причину в связке:

Nginx
↓
fastcgi_pass
↓
Unix socket / TCP
↓
PHP-FPM pool

а не диагностировать каждый компонент отдельно.

Проверьте журнал PHP-FPM

PHP-FPM имеет собственный журнал ошибок. Путь задаётся параметром error_log в конфигурации FPM.

Если сервис не стартует или пул создаётся неправильно, журнал может сразу показать:

• ошибку конфигурации;
• проблему с пользователем или группой;
• невозможность создать listener;
• конфликт адреса;
• другую причину остановки.

Это намного полезнее, чем многократно перезапускать сервис.

Проверьте Nginx после изменений

Перед применением изменений конфигурации Nginx проверьте её:

nginx -t

Если конфигурация корректна, примените её штатным способом для вашего сервера.

После этого снова откройте сайт и проверьте журнал ошибок.

Не меняйте одновременно Nginx, PHP-FPM, права и версию PHP. Иначе после восстановления сайта будет сложно понять, что именно было причиной.

А если проблема не в сокете, а PHP-FPM перегружен?

Бывает и другой случай: соединение настроено правильно, но PHP-FPM не успевает обрабатывать запросы.

PHP-FPM имеет status page, где можно увидеть:

• listen queue;
• активные процессы;
• idle-процессы;
• общее количество процессов;
• max children reached;
• slow requests.

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

Но это уже следующий этап.

Если Nginx вообще не может подключиться к указанному Unix-сокету, сначала исправляется именно соединение.

Короткий порядок диагностики

При PHP-FPM sock failed я бы проверял так:

1. посмотреть точную ошибку Nginx;
2. найти фактический fastcgi_pass;
3. определить — используется Unix-сокет или TCP;
4. найти listen активного PHP-FPM pool;
5. сравнить адреса;
6. проверить, существует ли socket;
7. проверить статус PHP-FPM;
8. проверить конфигурацию FPM;
9. проверить listen.owner, listen.group и listen.mode;
10. посмотреть журнал PHP-FPM;
11. проверить конфигурацию Nginx;
12. применить изменения;
13. повторно открыть сайт и проверить ошибки.

Так можно локализовать проблему, а не перезапускать всё подряд.

Чего не стоит делать

При ошибке подключения к PHP-FPM не стоит сразу:

• ставить 777 на сокет и каталоги;
• создавать .sock обычной командой touch;
• менять номер версии PHP наугад;
• перезапускать весь сервер;
• переустанавливать PHP;
• переводить Unix-сокет на TCP без причины;
• менять одновременно несколько конфигураций;
• считать любой 502 Bad Gateway проблемой PHP-FPM-сокета.

Сначала сравните фактический адрес в Nginx с фактическим listen PHP-FPM.