Apache перестал обрабатывать файлы PHP после смены обработчика

#Что означает проблема

Если сервер вместо исполнения PHP предлагает скачать файл или показывает его исходный код, это чрезвычайно опасно: в исходниках могут быть пароли базы и ключи приложения. До диагностики немедленно исключите публичную выдачу такого содержимого через штатную страницу обслуживания либо ограничение доступа на входном узле. Если вместо этого возникает 503/502/500, применяйте безопасную диагностику подключения PHP-FPM и журнала Apache.

#Как различить причины

#Подробная диагностика и устранение

1. Немедленно проверьте, не раскрывается ли исходный кодЕсли браузер показывает <?php или скачивает .php, считайте это происшествием безопасности. Не размещайте общедоступный phpinfo.php или тест с паролями; временно закройте соответствующий сайт штатным режимом обслуживания или блокировкой на внешнем Nginx и согласуйте дальнейшие действия. Проверьте журнал загрузок: если исходники могли быть получены, учётные данные приложения следует считать потенциально раскрытыми и заменить по установленному порядку.
2. Различите неисправности по коду ответаЕсли код не раскрывается, откройте обычную публичную страницу через браузер F12 → «Сеть», запишите HTTP-статус и время. 503 от Apache при proxy_fcgi может означать отсутствие подключения к PHP-FPM; 500 — ошибку обработчика или самого скрипта. Не угадывайте по внешнему виду: проверьте error.log нужного виртуального хоста за ту же минуту.
3. Найдите конкретный VirtualHost и модульНа сервере через SSH выполните sudo apache2ctl -S и sudo apache2ctl -M. В списке модулей ищите proxy_module, proxy_fcgi_module, php_module (название версии может отличаться). Определите, какой путь PHP обслуживал домен: PHP-FPM через SetHandler/ProxyPassMatch или встроенный mod_php. Не включайте одновременно два обработчика для одного файла без схемы проекта.
4. Проверьте действующий FilesMatch и путь к сокетуВ конфигурации найденного хоста найдите <FilesMatch "\.php$"> и SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/" либо другую конфигурацию. Приведённая строка — только пример. Проверьте, что сокет действительно существует в sudo ls -la /run/php/ и принадлежит нужному пулу. На Fastpanel и иных панелях имя пути может отличаться полностью, нельзя подставлять php8.2-fpm.sock без проверки.
5. Проверьте состояние конкретного PHP-FPMВыполните systemctl --type=service --state=running | grep -E "php.*fpm" для поиска действующих служб; далее посмотрите sudo systemctl status ИМЯ-СЛУЖБЫ с реальным именем из списка. Если пул не запущен, прочитайте журнал sudo journalctl -u ИМЯ-СЛУЖБЫ -n 80 --no-pager и исправьте обнаруженную ошибку конфигурации, сокета или прав. Не запускайте произвольную новую версию PHP вместо той, которую выбрали для сайта.
6. Убедитесь в безопасной области применения обработчикаСопоставьте блок FilesMatch, DocumentRoot и правила безопасности каталога загрузок. Нельзя разрешать выполнение произвольных PHP-файлов внутри пользовательских uploads. В стандартной архитектуре PHP-FPM проверяйте соответствие SCRIPT_FILENAME фактическому пути скрипта; при ошибке типа Primary script unknown исправьте сопоставление, а не открывайте все каталоги.
7. Сделайте копию и восстановите нужный обработчикСохраните конфигурацию Apache и настройки пула PHP-FPM. Если применяете изменения в Apache, выполните sudo apache2ctl configtest; если меняете настройки PHP-FPM, используйте тест конфигурации конкретной установленной версии, указанный поставщиком пакета. После успешных проверок примените reload соответствующих служб через systemctl или панель. При ошибке возвратите резервные копии и верните сайт в режим обслуживания.
8. Включайте публичный сайт только после проверкиПроверьте выполнение безопасного уже существующего PHP-маршрута, который не раскрывает секреты, корректность 200/авторизации, работу статических файлов и логи Apache/PHP-FPM. Убедитесь, что исходный код PHP не отображается и не скачивается, а неизвестные PHP-файлы и загрузки не исполняются. Только после этого снимайте страницу обслуживания. Если исходники были доступны, отдельно проведите разбор доступа и замену потенциально затронутых секретов.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1SSH Debian/Ubuntu: проверка виртуальных хостов, модулей и существующих сокетов.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   SSH Debian/Ubuntu: проверка виртуальных хостов, модулей и существующих сокетов. На панели или другом дистрибутиве каталог может отличаться.

   sudo apache2ctl -S

   sudo apache2ctl -M

   sudo ls -la /run/php/

   Вариант 2SSH без sudo; показывает найденные службы FPM.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   SSH без sudo; показывает найденные службы FPM. Не вставляйте текст ИМЯ-СЛУЖБЫ буквально: используйте фактическое имя из вывода.

   systemctl --type=service --state=running | grep -E "php.*fpm"

   Вариант 3Только иллюстрация синтаксиса mod_proxy_fcgi!

   ТекстКопировать всёВыделить

   Только иллюстрация синтаксиса mod_proxy_fcgi! Версия PHP, путь сокета и контекст должны соответствовать вашему установленному пулу; неподтверждённое значение вставлять нельзя.

   <FilesMatch "\.php$">
       SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
   </FilesMatch>

#Как проверить результат

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

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

Если после восстановления обработчика 503 сохраняется, изучите ошибку proxy_fcgi и путь сокета; если 500 — логи приложения, права и совместимость версии PHP. Если выводится исходный код, не возвращайте сайт в публичный доступ до устранения риска.