Ошибка 502 в FASTPANEL после изменения версии или обработчика PHP

Почему после смены версии или обработчика PHP в FASTPANEL появляется 502 Bad Gateway?

Если 502 появилась непосредственно после изменения PHP в FASTPANEL, первым кандидатом становится новый backend. Nginx уже принял HTTP-запрос, но дальше цепочка не завершилась нормально. Поэтому вместо проверки всего сервера можно сразу сосредоточиться на PHP handler, соответствующей службе, listener и журналах.

При PHP-FPM схема сравнительно короткая: Nginx принимает запрос и передаёт PHP-файл PHP-FPM pool. В режимах, где участвует Apache, между Nginx и интерпретатором PHP появляется ещё один компонент. Фраза «PHP на сервере запущен» здесь мало что доказывает: нужно выяснить, какой обработчик назначен конкретному сайту и какой backend должен принимать запрос именно для него.

После переключения возможны разные сценарии. Новый PHP-FPM не запустился. Служба работает, но нужный listener не создан. PHP-FPM слушает другой путь, а Nginx обращается к прежнему socket. Backend принимает соединение и сразу закрывает его. Или инфраструктурная часть уже исправна, но приложение несовместимо с новой версией PHP.

Поэтому 502 не означает просто «PHP сломан». Технически полезнее считать её признаком того, что Nginx не смог нормально получить ответ от следующего backend в цепочке. Конкретную причину нужно подтвердить журналом.

Чем 502 отличается от 500 и 504 после изменения PHP?

502 обычно возникает при проблеме обмена с upstream: соединение не удалось установить, backend закрыл его раньше времени или вернул ответ, который frontend не смог корректно обработать. Ошибка 500 чаще появляется уже внутри backend или приложения. Код 504 означает, что frontend слишком долго ждал ответ.

Сам HTTP-код не определяет причину. Если Nginx пишет Connection refused, проверяется служба и listener. При Permission denied — права доступа. При timeout — время выполнения, workers и ресурсы. После фиксации 502 следующий полезный шаг — получить свежую строку frontend error log.

Как за пять минут проверить, действительно ли 502 связана с PHP?

Быстрее всего отделить проблему Nginx от проблемы PHP двумя запросами: к статическому файлу и к минимальному PHP-файлу. Если HTML отдаётся нормально, а PHP получает 502, Nginx уже обслуживает домен и document root, а сбой возникает при переходе к PHP backend.

Создайте временный test.html в корне проблемного сайта:

HTML OK

Рядом создайте test.php:

<?php echo 'PHP OK'; ?>

Проверьте оба URL через браузер либо curl:

curl -I https://example.com/test.html
curl -i https://example.com/test.php

Если test.html возвращает нормальный HTTP-ответ, Nginx способен принять запрос для домена и прочитать файл из document root. Если в это же время test.php даёт 502, искать DNS или SSL уже не нужно — проверяйте PHP handler, backend и upstream.

Если CSS, изображения и JavaScript открываются, а PHP-страницы отвечают 502, картина похожая: статика проходит, динамика ломается. И наоборот, если минимальный test.php отвечает PHP OK, а WordPress по-прежнему падает, socket можно временно оставить в покое. Backend жив. Дальше проверяются web PHP version, расширения, права и само приложение.

Какие логи FASTPANEL нужно открыть при 502 и что искать в них?

При 502 после смены PHP первым диагностическим источником должен быть frontend error log Nginx. Страница браузера сообщает только результат, а журнал обычно показывает, куда Nginx пытался подключиться и что произошло на этом шаге.

В FASTPANEL для сайта доступны frontend- и backend-журналы. Frontend относится к Nginx, backend — к компоненту, который обслуживает запрос дальше, например Apache или PHP-FPM. Начинать лучше с frontend error log, потому что именно Nginx возвращает пользователю 502.

Сделайте один контрольный запрос к странице, которая стабильно выдаёт ошибку, и сразу откройте последние записи. В журнале могут оставаться сообщения от предыдущих переключений PHP, поэтому время ошибки должно совпадать с вашим тестом. Старый No such file от прежней конфигурации легко принять за текущую причину.

Обезличенная строка может выглядеть так:

connect() to unix:... failed (...) while connecting to upstream

Здесь уже есть две полезные части: Nginx пытался подключиться к upstream, а текст внутри ошибки объясняет, почему подключение не состоялось. No such file, Connection refused и Permission denied — три разные ветки диагностики. Лечить их одним restart бессмысленно.

Backend error log нужен следом. Если Nginx даже не смог подключиться к PHP-FPM, в backend-журнале может не быть записи для этого HTTP-запроса. Если соединение произошло, но PHP-FPM или Apache оборвал обработку, причина часто появляется уже там.

Удобная последовательность при работе из поддержки выглядит просто: воспроизвести ошибку, зафиксировать время, прочитать frontend error log, затем при необходимости backend log. Не наоборот. Так меньше шансов начать исправлять старую запись, которая уже не относится к текущей конфигурации.

Как проверить, запущен ли нужный PHP-FPM или Apache после переключения обработчика?

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

Что зафиксировать в FASTPANEL до перезапуска служб

Откройте настройки проблемного сайта и запишите два значения: выбранный PHP handler и PHP version. После этого откройте управление службами FASTPANEL и сопоставьте настройки сайта с тем, что реально запущено. Если выбран PHP-FPM, должна работать соответствующая PHP-FPM версия. Если в цепочке участвует Apache, проверяется и Apache.

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

Что означают состояния службы через SSH

При root-доступе сначала выведите подходящие службы:

systemctl --type=service | grep -Ei 'php.*fpm|apache|httpd|nginx'

Название PHP-FPM service зависит от дистрибутива, репозитория и установленной версии PHP. Найдя нужную службу, проверьте её:

systemctl status <имя-службы>

Интерпретировать результат лучше не по одному слову:

• active (running) — процесс службы работает, но это ещё не доказывает, что сайт подключается к правильному listener;
• failed — PHP-FPM или Apache не смог запуститься либо завершился с ошибкой;
• activating / auto-restart — процесс может постоянно падать и запускаться заново;
• inactive — служба сейчас не обслуживает запросы.

Если PHP-FPM помечен как active (running), а test.php продолжает отдавать 502, restart уже не первый шаг. Проверьте, существует ли нужный listener и совпадает ли он с upstream Nginx. Служба может быть жива, но сайт смотреть не туда.

Если служба failed или постоянно перезапускается

Посмотрите свежий системный журнал именно этой службы:

journalctl -u <имя-службы> --since "10 minutes ago"

Ищите первую техническую причину перед сообщением о завершении процесса. Это может быть ошибка конфигурации, невозможность открыть файл, проблема с каталогом, конфликт listener или другой сбой. Последующая строка systemd вроде Failed to start... лишь фиксирует результат.

Если процесс стартует и почти сразу снова оказывается в failed, повторный restart обычно только воспроизводит ту же ошибку. Здесь полезнее сохранить журнал и устранить причину старта.

FASTPANEL показывает PHP-FPM запущенным, но 502 остаётся

Такой сценарий встречается достаточно часто для отдельной проверки. В панели служба выглядит рабочей, но Nginx по-прежнему пишет No such file или Connection refused. Тогда статус процесса сам по себе уже не помогает.

После любого изменения повторите запрос к test.php и сразу проверьте frontend error log. Если тест стал возвращать 200 и новая upstream-ошибка не появляется, исправление подтверждено двумя независимыми признаками.

Как проверить, что FASTPANEL действительно применил нужную версию PHP и обработчик?

Команда php -v показывает CLI PHP текущего shell-окружения и не доказывает, что веб-сайт работает на той же версии. HTTP-запрос может обрабатываться другой версией PHP через PHP-FPM, FastCGI или Apache.

Поэтому после изменения версии в FASTPANEL проверять нужно именно web runtime. Ситуация «в консоли PHP 8.x, а сайт фактически выполняется на другой ветке» вполне возможна и сама по себе не говорит о неисправности CLI.

Как проверить PHP version и SAPI через веб

Временно создайте файл:

<?php
echo PHP_VERSION . ' / ' . PHP_SAPI;
?>

Откройте его через домен сайта. Если вместо результата снова 502, проверять версию ещё рано: HTTP-запрос не доходит до рабочего PHP runtime. Возвращайтесь к frontend log, service и listener.

Если файл открывается, сравните значение PHP_VERSION с версией, назначенной сайту в FASTPANEL. PHP_SAPI показывает интерфейс, через который запущен PHP. Например, для PHP-FPM обычно можно увидеть значение, связанное с FPM/FastCGI. Но один PHP_SAPI не описывает всю цепочку Nginx → Apache/PHP или Nginx → PHP-FPM, поэтому его нужно читать вместе с настройкой handler в панели.

Как интерпретировать расхождения

Если FASTPANEL показывает новую версию, а web-тест по-прежнему возвращает старую, не нужно сразу редактировать системный php.ini. Сначала убедитесь, что проверяется тот же домен и тот же виртуальный хост, затем снова сопоставьте handler, version и backend.

Почему phpinfo() полезен только временно

Для более глубокого сравнения можно на короткое время создать страницу с phpinfo(). Она показывает загруженные extensions, пути конфигурационных файлов и другие параметры конкретного web PHP. После проверки файл нужно удалить: он раскрывает слишком много информации о серверной среде.

Что означает результат минимального PHP-теста

• Тестовый PHP-файл даёт 502. Связка Nginx и PHP backend ещё не восстановлена.
• Файл работает, но показывает неожиданную версию. Проверяйте назначение handler/version и фактический backend.
• Версия правильная, PHP работает, CMS падает. Переходите к расширениям, правам, rewrite и журналу приложения.
• PHP работает только периодически. Проверяйте стабильность PHP-FPM, workers и ресурсы VPS.

test.php отвечает — значит, Nginx уже способен передать запрос PHP backend и получить результат. С этого момента дальнейшая диагностика зависит от симптома реального сайта, а не от самого факта существования socket.

Что делать, если Nginx не может подключиться к PHP-FPM socket или backend?

Если frontend error log прямо показывает ошибку соединения с upstream, нужно сопоставить две вещи: адрес, куда обращается Nginx, и listener, который реально существует на сервере. Пока они не совпадают, перезапуск Nginx проблему не исправит.

В журнале указано No such file or directory

Для PHP-FPM через Unix socket такая запись обычно означает, что Nginx ожидает socket по определённому пути, но файла socket там нет. Возможные причины: нужный PHP-FPM pool не стартовал, служба запущена с другой конфигурацией или listener создаётся по другому пути.

Посмотреть слушающие Unix sockets можно командой:

ss -lxp

Если вывод большой, ищите процессы PHP-FPM и сопоставляйте их с адресом из ошибки Nginx. Здесь возможны три принципиально разных результата:

• нужный socket присутствует — переходите к правам и соответствию upstream;
• PHP-FPM sockets есть, но ожидаемого Nginx пути среди них нет — вероятно, backend слушает другой адрес;
• ожидаемого socket нет вообще — проверяйте соответствующую PHP-FPM службу, pool и её журнал.

Socket вручную не создаём. Обычный touch создаст пустой файл, но принимать PHP-запросы он не сможет. Unix socket должен создать работающий процесс.

Socket существует, но Nginx обращается к другому пути

Это отдельная ветка, которую легко пропустить. PHP-FPM может быть active, listener присутствует, а frontend log продолжает ссылаться на другой socket. В таком случае проблема не в запуске PHP-FPM, а в несоответствии фактического listener и upstream, назначенного сайту.

Не меняйте автоматически первый найденный конфигурационный файл. Сначала установите, какой upstream используется конкретным виртуальным хостом FASTPANEL и какой путь реально слушает нужная PHP version. Если правка делается вручную в сгенерированной панелью конфигурации, нужно учитывать, что FASTPANEL может позже перегенерировать этот участок.

В журнале указано Connection refused

Connection refused означает, что Nginx обращается к известной точке, но в этот момент соединение никто не принимает. Проверьте состояние PHP-FPM или Apache и наличие соответствующего listener.

Если служба остановлена — смотрите причину в системном журнале. Если служба active, а listener отсутствует, status уже недостаточно: нужно проверить, какой pool загружен и что именно слушает backend.

В журнале указано Permission denied

При Permission denied backend или socket уже может существовать, но один процесс не имеет необходимого доступа. Здесь сопоставляют владельца socket, группу, режим доступа и пользователей Nginx/PHP-FPM.

Рекурсивная команда вида:

chmod -R 777 ...

не исправляет архитектуру доступа и создаёт новую проблему безопасности. Если журнал указывает на конкретный socket или каталог, права исправляются точечно и только после понимания, какой пользователь должен иметь доступ.

Проверка конфигурации перед reload

Если менялась конфигурация Nginx, сначала выполните:

nginx -t

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

Если текущий PHP mode использует Apache, проверьте и его конфигурацию штатной командой установленной системы, например:

apachectl configtest

Названия служб и команд между дистрибутивами различаются, поэтому не стоит подставлять имя сервиса из чужой инструкции вслепую.

После исправления должны одновременно выполняться три условия: нужный listener существует, nginx -t проходит успешно, test.php возвращает нормальный HTTP-ответ. Если одно из них не выполнено, диагностика upstream ещё не закончена.

Почему сайт может сломаться при переходе между PHP-FPM, FastCGI и Apache module, даже если PHP запущен?

Если test.php уже возвращает 200, а WordPress или другая CMS после смены PHP handler продолжает выдавать ошибку, проблема перешла на следующий уровень. Nginx способен передать запрос PHP backend, поэтому искать отсутствующий socket без нового подтверждения уже не нужно.

Смена handler меняет не только способ запуска PHP. Она может изменить участие Apache в цепочке, применение .htaccess, пользователя backend, набор PHP extensions и конфигурацию конкретной PHP version.

Что происходит с .htaccess при PHP-FPM

В схеме FASTPANEL, где Nginx работает непосредственно с PHP-FPM, Apache-файл .htaccess не обрабатывается. Если сайт до переключения зависел от правил Apache, часть поведения может измениться даже при полностью рабочем PHP.

Проверить стоит rewrite rules, redirects, ограничения доступа, а в старых проектах — php_value, php_flag и другие Apache directives. Если после переключения PHP главная открывается, а внутренние URL массово получают 404, rewrite гораздо вероятнее, чем неисправный PHP-FPM socket.

Само наличие .htaccess не объясняет 502. Если минимальный PHP тоже падает, сначала чинится backend.

Права пользователя сайта

После смены схемы обработки PHP новый backend должен иметь доступ к файлам приложения и к каталогам, куда CMS действительно пишет данные. Для WordPress это могут быть uploads, cache и временные директории; для других приложений набор путей отличается.

Если backend log содержит Permission denied при обращении к конкретному файлу или каталогу, исправляйте владельца или права этого объекта. Массово открывать весь document root на запись не нужно.

Расширения и настройки новой версии PHP

При переходе на другую PHP version приложение может получить другой набор extensions и другую конфигурацию. Проверить могут понадобиться memory_limit, session path, список disable_functions и модули, от которых зависит CMS.

Отсутствующий extension чаще проявляется уже как ошибка приложения, а не как No such file при соединении Nginx с upstream. Если минимальный PHP выполняется, а CMS пишет об отсутствующей функции или классе, инфраструктурная часть уже прошла базовый тест.

Для WordPress после успешного test.php проверьте /wp-admin/, одну внутреннюю динамическую страницу и действие, которое точно выполняет PHP. Главная может оказаться закешированной и скрыть проблему.

Как отличить ошибку конфигурации от падения PHP-FPM, нехватки workers или ресурсов VPS?

После restart PHP-FPM сайт оживает на несколько минут, затем снова получает 502. Или обычные запросы проходят, а несколько параллельных начинают падать. Это уже другая картина, чем постоянный No such file сразу после переключения PHP: backend существует, но перестаёт стабильно обслуживать запросы.

Проверьте память, место на диске и inode

Для первого среза достаточно нескольких команд:

free -h
df -h
df -i
uptime

free -h показывает RAM и swap. df -h — заполнение файловых систем. Но свободное место в гигабайтах ещё не гарантирует, что сервер может создавать новые файлы. Если закончились inode, файловая система может иметь свободные гигабайты, но PHP, логи, sessions или cache перестанут нормально создавать новые файлы. Поэтому при странном поведении заполнения проверяют и df -i.

Посмотреть процессы с высоким потреблением памяти можно так:

ps aux --sort=-%mem | head

Сам по себе большой процент памяти не доказывает причину 502. Нужна связь по времени: ошибка Nginx появилась тогда же, когда PHP-FPM был убит, перезапущен или достиг собственного ограничения.

Как проверить OOM, если PHP-FPM неожиданно исчезает

Если PHP-FPM был рабочим, затем пропал или перезапустился под нагрузкой, проверьте системные сообщения на события OOM. В зависимости от дистрибутива информация может находиться в systemd journal или kernel log. Для поиска можно начать с:

journalctl -k --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'

Формулировки между системами отличаются, поэтому отсутствие ровно одной ожидаемой строки ничего не доказывает. Ищите связку: в 22:14 Nginx фиксирует 502, в 22:14 системный журнал сообщает об уничтожении PHP-FPM или другого процесса из-за нехватки памяти. Это уже серьёзное подтверждение ресурсной причины.

Если RAM свободна, OOM-событий нет, а PHP-FPM остаётся запущенным, покупать больше памяти или увеличивать swap только из-за одной 502 рано.

Как понять, что PHP-FPM упирается в workers

Количество PHP-FPM workers ограничивает число запросов, которые pool способен одновременно обрабатывать. При достижении лимита в PHP-FPM log могут появляться сообщения о достижении максимального количества дочерних процессов. Точная формулировка зависит от версии и конфигурации, но смысл один: свободных workers для новых запросов не хватает.

Здесь нужно сопоставить три признака:

• ошибка появляется в основном под параллельной нагрузкой;
• PHP-FPM не падает полностью и listener остаётся на месте;
• backend log указывает на достижение ограничения pool либо очередь запросов заметно растёт.

Если этих признаков нет, увеличивать workers наугад не стоит.

Почему нельзя просто увеличить workers в два раза

Каждый PHP-FPM worker потребляет память. Если один процесс тяжёлого WordPress занимает заметный объём RAM, увеличение числа дочерних процессов способно не устранить 502, а приблизить OOM. Получится замкнутый круг: workers стало больше, сервер использовал больше RAM, kernel начал убивать процессы, а Nginx снова получает ошибки от backend.

Перед изменением pool полезно посмотреть фактическое потребление PHP-процессов и доступный объём памяти. Универсального числа workers для VPS не существует: оно зависит от приложения, нагрузки и памяти одного процесса.

Как связать 502 с реальным событием на сервере

Не сравнивайте журналы «примерно за сегодняшний день». Сделайте контрольный запрос и запишите время до минуты. Затем сопоставьте:

22:14:03  Nginx: upstream error / 502
22:14:03  PHP-FPM: process exited / pool warning
22:14:04  systemd или kernel: restart / OOM event

Это не образец конкретного FASTPANEL-инцидента, а схема корреляции. Если события происходят в один момент, версия о падении backend становится намного сильнее. Если PHP-FPM журнал в это время чистый, а Nginx сообщает No such file сразу после смены handler, возвращайтесь к конфигурации.

Если 502 постоянна и появилась сразу после смены handler, сначала проверяется конфигурация. Если ошибка зависит от нагрузки, PHP-FPM периодически оживает после restart или журнал показывает падение процессов, тогда уже имеет смысл разбирать workers, память, OOM и файловую систему.

Как безопасно откатить версию или обработчик PHP, если сайт нужно срочно восстановить?

Если рабочий сайт сразу после изменения PHP получил 502, безопасный аварийный шаг — вернуть последнее известное рабочее сочетание PHP version и handler. Но перед откатом стоит сохранить текущее состояние и свежую ошибку: после восстановления именно эти данные помогут понять, почему новая конфигурация не запустилась.

1. Запишите текущие PHP version и handler.
2. Сохраните свежую строку frontend error log и, если есть, backend log.
3. Верните последнее известное рабочее сочетание PHP version и handler.
4. Проверьте минимальный PHP-файл.
5. Проверьте реальные динамические страницы.
6. Снова откройте свежие журналы.
7. После восстановления исследуйте новую конфигурацию отдельно.

Почему нельзя одновременно менять PHP, Nginx, права и CMS

Если после 502 одновременно вернуть PHP, перезапустить Nginx, изменить права каталога и отключить плагины WordPress, сайт может открыться, но причина останется неизвестной. В следующий раз проблема повторится с тем же набором догадок.

Меняйте один параметр и сразу выполняйте контрольный запрос. Если возврат прежнего handler восстанавливает test.php, а свежие upstream errors исчезают, связь с новой PHP-конфигурацией подтверждается гораздо лучше.

Успешный rollback восстанавливает сайт, но не объясняет причину

Если старая PHP-конфигурация снова работает, задача доступности решена. Причина сбоя новой конфигурации при этом остаётся открытой: соответствующий PHP-FPM мог не запускаться, мог отличаться listener, права или runtime новой версии.

После восстановления не нужно сразу снова переключать PHP «для проверки». Сначала разберите сохранённые логи и подготовьте контрольные точки: service, socket, test.php и web PHP version.

Что делать, если откат PHP не устранил 502

Если вернули прежнюю PHP version и handler, а сайт всё равно получает 502, исходное изменение уже нельзя считать единственной причиной. Возможны как минимум три сценария: backend остался в состоянии failed, конфигурация frontend/backend не вернулась в рабочее состояние или изменение PHP просто совпало по времени с другой неисправностью.

Повторите диагностику от фактов:

1. Сделайте новый запрос к test.php.
2. Откройте именно свежую строку frontend error log.
3. Проверьте состояние соответствующей службы.
4. Проверьте фактический listener.
5. Если менялась конфигурация Nginx, выполните nginx -t.

Если после rollback Nginx всё ещё пишет No such file, смотрите текущий путь upstream и socket, а не предполагайте, что панель обязательно вернула абсолютно всё состояние. Если ошибка стала другой, это тоже полезный признак: система перешла в другую ветку диагностики.

Практический чек-лист диагностики 502 после смены PHP

• Зафиксировать последнюю рабочую PHP version и handler.
• Проверить статический test.html.
• Проверить минимальный test.php.
• Воспроизвести 502 и сразу открыть frontend error log.
• Проверить backend error log.
• Определить, какой backend должен обслуживать текущий PHP mode.
• Проверить состояние соответствующего PHP-FPM или Apache.
• При SSH посмотреть свежий системный журнал нужной службы.
• Сопоставить upstream Nginx с реально существующим listener.
• При изменении Nginx выполнить nginx -t.
• Если используется Apache, выполнить его штатный configtest.
• Не создавать Unix socket вручную.
• Не использовать chmod 777 как универсальное исправление.
• Проверить web PHP version через HTTP, а не только php -v.
• После смены PHP mode проверить зависимость сайта от .htaccess.
• При периодической 502 проверить RAM, диск, inode, OOM и PHP-FPM workers.
• При необходимости вернуть последнее рабочее сочетание handler/version.
• Если rollback не помог, заново проверить свежий log, service и listener.
• После исправления выполнить несколько динамических запросов.
• Удалить диагностические test.php и phpinfo().

Как убедиться, что сайт стабильно работает после исправления 502?

Главная страница открылась после restart, но это ещё не доказывает, что PHP backend исправен. Она может быть отдана из page cache, тогда как первый реальный динамический запрос снова получит 502. Проверять нужно именно выполнение PHP и свежие журналы.

Проверьте несколько разных динамических запросов

Сначала снова откройте минимальный PHP-файл. Затем проверьте несколько страниц сайта, которые требуют выполнения PHP. Для WordPress полезно открыть /wp-admin/, одну внутреннюю страницу и выполнить действие, которое не сводится к отдаче закешированного HTML.

Если проблема раньше проявлялась периодически, одного успешного запроса недостаточно. Сделайте несколько последовательных обращений. Backend должен не просто ответить один раз, а оставаться рабочим.

Снова проверьте frontend и backend logs

После контрольных запросов откройте свежие журналы. Старые 502 останутся в истории, но на новые тестовые запросы не должны появляться повторяющиеся Connection refused, No such file, Permission denied или другие upstream errors.

Если страница уже открывается, а frontend log всё ещё периодически фиксирует ошибки соединения с backend, проблема не закрыта. Часть запросов может проходить, часть — падать.

Подтвердите фактическую версию PHP

Если работа началась с перехода на другую PHP version, после восстановления снова проверьте web runtime через PHP_VERSION. Сервер мог начать работать потому, что был выполнен rollback на старую версию. Для аварийного восстановления это нормально, но считать миграцию завершённой нельзя.

PHP_SAPI дополнительно покажет контекст выполнения PHP. После проверки временный диагностический файл удалите.

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

Если до исправления restart помогал только ненадолго, после восстановления посмотрите состояние PHP-FPM ещё раз через несколько реальных запросов. Listener не должен исчезать, служба не должна переходить в restart loop, а системный журнал не должен показывать новое завершение процессов.

Если причиной был лимит workers или память, простой test.php может работать идеально, пока сайт не получает реальные запросы. Поэтому проверка должна соответствовать исходному симптому: постоянную 502 проверяют обычными запросами, нагрузочную — несколькими параллельными или реальными динамическими действиями без создания искусственно опасной нагрузки на production.

Критерии, по которым 502 можно считать устранённой

• Статические файлы и PHP-запросы стабильно возвращают нормальные ответы.
• Минимальный PHP-код выполняется без 502.
• Основные динамические страницы сайта работают.
• Назначенная сайту PHP version соответствует ожидаемой.
• Нужный PHP-FPM или Apache остаётся в рабочем состоянии.
• Backend listener существует и не исчезает после серии запросов.
• В свежем frontend log нет повторяющейся upstream-ошибки.
• В backend/system journal нет нового падения процесса.
• При периодической проблеме проверены workers, память и OOM.
• Временные диагностические файлы удалены.

Закрывать такой инцидент стоит не по одной открывшейся главной, а по цепочке подтверждений: динамический запрос дошёл до правильного backend, PHP выполнился, нужная версия действительно используется, процесс остался жив, а новая upstream-ошибка в журнале не появилась.

Если после следующего переключения PHP 502 повторится, начинать с нуля уже не нужно. Контрольные точки известны: статика, минимальный PHP, свежий frontend log, состояние нужной службы, listener и web PHP version. По ним обычно быстро видно, на каком именно шаге новая конфигурация перестаёт работать.