Почему версия PHP в терминале отличается от версии сайта

В терминале установлена нужная версия PHP, но сайт продолжает сообщать о другой. Это не обязательно ошибка обновления. Командная строка и веб-сервер могут запускать разные исполняемые файлы, читать разные настройки и использовать разные наборы расширений.

В Linux с установленным PHP CLI выполните:

Команды показывают версию, загруженные конфигурационные файлы и модули именно этого CLI. Они полезны для фоновых скриптов и задач, которые вызывают этот бинарный файл. Но переносить вывод на обработчик веб-запросов нельзя.

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

Не выбирайте службу по самому большому номеру версии в списке. Важна связь: виртуальный хост, адрес upstream, конкретный пул и его процесс. Несколько сайтов на одном сервере могут намеренно использовать разные окружения.

Для проблемного сценария составьте небольшой набор: версия, расширения, ограничения памяти и времени выполнения, настройки загрузки файлов. Не нужно менять все параметры только ради полного совпадения CLI и FPM: у них могут быть разные рабочие задачи.

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

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

Предпочтительно использовать уже существующие защищённые средства диагностики CMS или панели. Публикация открытой страницы со всеми параметрами ради одной версии создаёт лишнюю задачу по контролю доступа и уборке.

Даже после исправления веб-пула планировщик может продолжать запускать прежний CLI. Проверьте явный путь к бинарному файлу, пользователя и конфигурацию задания. Иначе сайт будет работать в одном окружении, а обмен каталогом — в другом.

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

Набор расширений тоже проверяйте в каждой среде отдельно. Наличие модуля в CLI не доказывает его загрузку в том пуле, который обслуживает сайт.

The terminal has the required PHP version installed, but the site continues to report a different one. This is not necessarily an update error. The command line and web server may run different executable files, read different configuration settings, and use different sets of extensions.

On Linux with PHP CLI installed, run:

These commands show the version, loaded configuration files, and modules specific to this CLI. They are useful for background scripts and tasks that invoke this binary file. However, you cannot transfer this output to the web request handler.

When working via PHP-FPM, the web server forwards requests to a specific socket or pool address. You must determine which service handles that pool and identify the settings associated with it. Service names and file locations depend on the distribution and installation method.

Do not select a service based on the highest version number in the list. What matters is the connection: virtual host, upstream address, specific pool, and its process. Multiple sites on a single server may intentionally use different environments.

For a problematic scenario, compile a small set: version, extensions, memory and execution time limits, and file upload settings. There is no need to change all parameters just to achieve a complete match between CLI and FPM, as they may have different operational tasks.

Example: an import via the terminal completes, but launching through the web interface is interrupted. The cause could be a difference in limits, process user, or proxy restrictions. A successful CLI run does not prove that the error lies exclusively in PHP-FPM.

Detailed PHP information output can reveal paths, environment variables, and server settings. If a diagnostic mechanism is used to check the web environment, it must be accessible only to the responsible specialist and removed or disabled after verification.

It is preferable to use existing secure diagnostic tools for the CMS or control panel. Publishing an open page with all parameters for a single version creates an unnecessary task for access control and cleanup.

Even after fixing the web pool, the scheduler may continue to run the old CLI. Check the explicit path to the binary file, the user, and the job configuration. Otherwise, the site will run in one environment while the directory exchange runs in another.

After making changes, repeat the scenario where the problem occurred: a web request, import, or background processing. Save the actual versions and settings for each environment. The result should be a clear execution map, not just the same number appearing in several randomly selected commands.

Check the set of extensions separately in each environment. The presence of a module in the CLI does not prove it is loaded in the pool serving the site.