#Симптомы и отличие от похожих неисправностей
После очистки /run/php или другого каталога временных сокетов Nginx возвращает 502 Bad Gateway, хотя до очистки сайт работал. Как отличить удалённый сокет от неисправной службы и восстановить связь без безусловного удаления файлов. Этот случай специфичен для удаления каталога или файла сокета при ещё работающем PHP-FPM: статус службы может быть активным, но Nginx больше не видит путь, указанный в fastcgi_pass.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Удалён путь сокета работающего процессаUnix-сокет удалили из файловой системы, но запущенный работник продолжает держать ранее открытый объект. | В Nginx connect() to unix:... failed (2: No such file or directory), а systemctl сообщает active. | Проверить путь и безопасно пересоздать сокет штатной службой. |
При очистке удалился и каталогРодительский каталог для listen отсутствует и FPM не способен заново создать файл. | При перезапуске FPM пишет No such file or directory или отказ bind. | Восстановить каталог штатной службой/панелью и проверить владельца. |
| Nginx и FPM смотрят в разные местаПосле обновления версии или перезапуска сервиса сменилось имя сокета, а fastcgi_pass остался старым. | Один путь указан в Nginx, другой в listen работающего пула. | Сверить конфигурации и изменить только неверную сторону. |
#Диагностика и пошаговое устранение
- Воспроизведите один запрос и запишите ошибку NginxОткройте нужный сайт в браузере без выполнения тяжёлых задач. В панели хостинга найдите «Журнал ошибок» Nginx за текущее время или попросите администратора показать его. Ищите
connect() to unix:/run/php/...sock failed (2: No such file or directory)и выпишите точный путь. Если указанPermission denied (13), это другая ситуация: файл есть, но доступ запрещён, и восстановление каталога не поможет.
- Найдите службу и убедитесь, что она обслуживает нужный сайтПодключитесь по SSH: из терминала Windows/Linux выполните
ssh пользователь@сервер, используя собственные учётные данные. Командойsystemctl list-units --type=service --all "php*-fpm.service"определите названия. У нескольких PHP может быть по разному сокету; сверяйте имя пула из панели домена и Nginx, а не выбирайте первую активную службу.Linux · Терминал (Bash)КомандаПроверка названия службы без изменений. Нестандартные сервисы панели могут называться иначе.systemctl list-units --type=service --all "php*-fpm.service"
- Сопоставьте fastcgi_pass и listenВ панели управления откройте конфигурацию сайта или попросите администратора выполнить
sudo nginx -Tв закрытом сеансе; вывод содержит всю конфигурацию и может включать внутренние адреса. Найдитеfastcgi_pass unix:/run/php/...sock;для домена, затемlisten = ...в соответствующем пуле. Пути должны совпадать до символа. Если указан127.0.0.1:9000, это TCP-соединение, и тема очистки Unix-сокетов к нему не относится.
- Проверьте существование файла и его родительского каталогаНа сервере выполните
ls -ld /run/phpиls -l /run/phpтолько если эта директория присутствует в найденном пути; иначе подставьте правильный каталог.lsпокажет владельца, права и список сокетов; при «No such file or directory» отсутствие подтверждено. Не создавайте файл .sock вручную: это не обычный файл, а адрес слушающего процесса. - Для примера Debian /run/phpLinux · Терминал (Bash)КомандаДля примера Debian /run/php. Без sudo, только просмотр. Не подставляйте путь, если ваша панель использует другой каталог.
ls -ld /run/phpls -l /run/php
- Убедитесь, что FPM не потерял родительский каталог при очисткеЕсли отсутствует весь
/run/php, проверьте, как он создаётся при запуске службы: на systemd-системах часть временных каталогов создаётRuntimeDirectoryили пакетная настройка. Не делайте слепоеmkdir -pс произвольными правами: при следующей перезагрузке каталог может снова исчезнуть. Сначала проверьте настройки службы и панель, при необходимости восстановите пакетное описание у администратора.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюНужен sudoПример для Debian PHP 8.2: после теста конфигурации повторное создание сокета штатным процессом. Нужны права администратора. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.
sudo php-fpm8.2 -t && sudo systemctl restart php8.2-fpmКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Восстановите сокет штатной перезагрузкой нужного пулаЕсли
listenиfastcgi_passсовпадают, каталог присутствует и служба активна, согласуйте кратковременный перерыв: исчезнувший сокет обычно требует перезапуска управляющего FPM, а не nginx. Выполнитеsudo php-fpm8.2 -t; только после успешного тестаsudo systemctl restart php8.2-fpm, заменив версию и имя службы. Перезапуск прерывает запросы этого пула, поэтому заранее завершите критические загрузки и импорты.
- Если файл появился, но 502 сохранилась, проверьте разрешенияПосмотрите фактический владелец и группу сокета, сопоставьте с пользователем Nginx и директивами
listen.owner,listen.group,listen.modeпула. При журналеPermission deniedисправляйте группу/ACL в настройке пула, не ставьте 777. Еслиconnect() failed (111: Connection refused), сервис мог сразу завершиться после запуска — вернитесь к его журналу. Ожидаемый результат: файл создан и обслуживает входящие соединения.
- Проверьте сайт и исключите повторную очистку живого сокетаПовторите запрос на обычную PHP-страницу и убедитесь в корректном ответе 200 (либо ожидаемом ответе приложения) и отсутствии новых строк с
No such file or directory. Найдите источник очистки: ручной скрипт, cron или служебная процедура панели. Исправьте её так, чтобы не удалять действующие сокеты. При отрицательном результате не повторяйте очистку, а соберите три факта: точный fastcgi_pass, текущий listen и сообщение журнала.
#Как проверить результат и что предпринять при неуспехе
Успех — сокет существует, FPM запущен, Nginx подключается к пути из fastcgi_pass, а браузер не получает 502. Если ошибка повторяется после очистки по расписанию, исправляйте её источник; восстановление одного файла не устранит причину. При необходимости верните исходную конфигурацию пула и веб-сервера из резервных копий.