#Симптом и границы применимости
Apache сам по себе чаще слушает TCP-порт, а Unix-сокет используется для подключения к PHP-FPM либо другому внутреннему процессу. Если после перезапуска Apache ошибки возникают на PHP-страницах, важно не путать отсутствие сокета с отсутствием прав на него.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Пул FPM ещё не создал сокетИмя PHP-сокета могло измениться после обновления или запуска службы. | В error_log видны No such file or directory и ошибки proxy_fcgi | Сравнить SetHandler/ProxyPassMatch с listen пула |
| Доступ запрещён системными правамиApache и PHP-FPM работают от разных пользователей. | В error_log Permission denied на connect() к сокету | Проверить права сокета и родительских каталогов |
| Путь находится в исчезнувшем каталоге /runКаталог /run часто создаётся заново при каждой загрузке. | До перезагрузки файл существует, после — исчезает | Проверить настройку runtime-каталога и запуск FPM |
#Пошаговая диагностика и исправление
- Определите, какие запросы пострадалиОткройте статическую страницу и PHP-страницу того же домена. Если статика работает, а PHP возвращает 503 или 502 при проксировании, вероятен канал Apache→FPM. Выполните один тестовый запрос, запомните время и не перезапускайте обе службы одновременно: так теряется диагностическая информация.
- Найдите адрес сокета по настройке ApacheПо SSH проверьте активный виртуальный хост и строки с proxy:unix, SetHandler, ProxyPassMatch. В панели конфигурация может генерироваться автоматически; тогда её нужно менять через панель, а не редактированием временного файла.
- Пример Debian; корректируйте путь поиска для своей сборкиLinux · Терминал (Bash)КомандаНужен sudoПример Debian; корректируйте путь поиска для своей сборки.
sudo apache2ctl -S; sudo grep -R -nE "proxy:unix:|SetHandler|ProxyPassMatch" /etc/apache2/sites-enabled /etc/apache2/conf-enabled
- Уточните, существует ли сокет после перезапускаВыполните ss -xlpn, затем ls -l и namei -l по фактическому пути из конфигурации. Ожидается Unix-сокет с правами, позволяющими пользователю Apache соединяться с ним; имя вроде /run/php/php8.2-fpm.sock — только пример. Не создавайте пустой файл вручную вместо сокета.
- Замените путь на фактический; ss читает системные сокетыLinux · Терминал (Bash)КомандаНужен sudoЗамените путь на фактический; ss читает системные сокеты.
sudo ss -xlpn | grep -E "php|fpm"; namei -l /run/php/php8.2-fpm.sock
- Сверьте пул и разрешенияНайдите в нужном пуле PHP-FPM listen, listen.owner, listen.group, listen.mode или listen.acl_users. Проверьте, какой пользователь выполняет Apache. Если SELinux/AppArmor сообщает об отказе, исправляйте политику по журналам, не отключая защиту. Не назначайте каталогам права 777.
- Проверьте порядок запуска службПосле запуска FPM сокет должен появиться даже до первого PHP-запроса (для Unix listen). Откройте состояние именно версии FPM, обслуживающей сайт, и журнал её запуска. Если служба не может создать сокет, исправление находится на стороне FPM. Не подменяйте рабочий пул другой версией без проверки расширений.
- Имя службы примерное: проверьте systemctl list-units и панельLinux · Терминал (Bash)КомандаНужен sudoИмя службы примерное: проверьте systemctl list-units и панель.
sudo systemctl status php8.2-fpm --no-pager; sudo journalctl -u php8.2-fpm -n 80 --no-pager
- Примените минимальную правку и проверьтеСделайте копию изменяемого файла. Исправьте только несовпадающий путь или нужную группу доступа; проверьте синтаксис FPM с бинарным файлом соответствующей версии и Apache. Перечитайте изменённую службу только после успешной проверки, затем повторите PHP-запрос и убедитесь, что другие сайты работают.
- Проверяет Apache, но не PHP-FPM; PHP-FPM проверяйте отдельным бинарным файлом версииLinux · Терминал (Bash)С осторожностьюНужен sudoПроверяет Apache, но не PHP-FPM; PHP-FPM проверяйте отдельным бинарным файлом версии.
sudo apache2ctl configtestКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат
После перезапуска выбранного FPM и Apache сокет существует с ожидаемым владельцем, PHP-страница возвращает правильный код, в error_log нет connect() failed; статика продолжает работать.
#Если проблема не устранена
Если повторный запуск снова ломает доступ, изучите создание /run, конфигурацию службы и ограничения безопасности. Восстановите копию настроек при ухудшении; не заменяйте Unix-сокет общедоступным TCP-портом.