Изменения php.ini не применяются: как найти конфигурацию сайта и PHP-FPM

Вы изменили php.ini, сохранили файл, но сайт продолжает показывать прежнее значение. Запрос «php ini изменения не применяются» описывает симптом, у которого несколько разных причин: от редактирования конфигурации другого PHP до настройки, закреплённой администратором пула FPM. Повторное сохранение файла и случайные перезапуски не позволяют отличить эти ситуации.

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

1. Начните с одного параметра и ожидаемого результата

Запишите точное имя директивы, прежнее и требуемое значения, место изменения и время сохранения. Укажите, где обнаружено несоответствие: в HTTP-запросе, задании cron, консольной команде или долгоживущем воркере. Формулировка «PHP не видит настройки» слишком широка; запись «для этого домена значение date.timezone осталось прежним» уже задаёт проверяемую задачу.

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

Не меняйте несколько параметров одновременно ради проверки. Сохраните исходное состояние и определите, как вернуть его, если новый вариант нарушит работу. На общем хостинге дополнительно уточните область действия: весь аккаунт, выбранный домен или отдельный обработчик. Одинаково названные поля в разных разделах панели могут управлять разными проектами, поэтому подтверждение «настройки сохранены» ещё не завершает диагностику.

2. Установите, какой PHP обслуживает сайт

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

Сравните PHP_VERSION и PHP_SAPI в затронутом HTTP-маршруте с окружением консольной команды. Команда php --ini показывает конфигурацию выбранного консольного интерпретатора. В официальном описании параметров CLI также предусмотрены -c для выбора конфигурации, -n для её отключения и -d для задания значения. Учитывайте эти аргументы в реальном запуске задания.

Если cron вызывает PHP напрямую, исследуйте указанный в задании интерпретатор и его параметры. Если cron обращается к URL, проверяйте обработчик этого URL. Для очереди уточните команду запуска и момент создания воркеров. Результат новой команды в терминале не говорит, что давно работающий процесс уже изменился.

Так объясняется ситуация «PHP CLI и FPM — разные настройки». Не исправляйте её автоматически копированием одного файла поверх другого. Различия могут быть намеренными; задача состоит в согласовании нужного параметра для нужного сценария.

3. Соберите защищённый отчёт вместо публичного phpinfo

Для HTTP-проверки используйте временный служебный маршрут с действующей административной авторизацией или сетевым ограничением. Исключите публичное кеширование ответа, назначьте ответственного за удаление и не сохраняйте отчёт в открытом каталоге. Название вроде «секретная-диагностика» не является защитой.

Следующий учебный фрагмент формирует ограниченный набор данных после проверки доступа. Он не реализует авторизацию и не должен публиковаться отдельной страницей. Вместо date.timezone разработчик может выбрать исследуемую директиву, сохранив такой же узкий объём вывода.

<?php
$all = ini_get_all(null, true);
$entry = is_array($all) ? ($all['date.timezone'] ?? []) : [];
$report = [
    'php_version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
    'loaded_ini' => php_ini_loaded_file(),
    'scanned_ini' => php_ini_scanned_files(),
    'current' => ini_get('date.timezone'),
    'global' => $entry['global_value'] ?? null,
    'local' => $entry['local_value'] ?? null,
];

В отчёт передают только выбранные поля, а не весь массив $all. Полный phpinfo() раскрывает значительно больше сведений об окружении и для этой задачи не требуется. Пути к конфигурации тоже предназначены ответственному исполнителю, а не посетителям.

Снимайте значение там, где оно влияет на работу. Отдельный диагностический файл может обходить загрузку CMS и поэтому не показать позднее переопределение в приложении. Для такого случая нужны измерения до и после инициализации проекта в одном защищённом сценарии.

4. Найдите действительно загруженный основной файл

Ответ на вопрос «где находится php.ini сайта» получают от обслуживающего сайт процесса. php_ini_loaded_file возвращает путь загруженного php.ini, а при отсутствии такого файла — false. Это полезнее предположения, что нужный файл обязательно лежит рядом с исполняемым PHP или в знакомом каталоге сервера.

В правилах поиска конфигурации PHP предусмотрены особенности SAPI, переменная PHPRC, параметры запуска и вариант php-SAPI.ini. Основная конфигурация читается при запуске PHP. Поэтому сначала сопоставьте сообщённый путь с редактируемым файлом, а уже потом выбирайте способ применения изменений.

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

Отсутствие основного файла не означает отсутствие настроек вообще: остаются встроенные значения и применимые дополнительные источники. Не создавайте новый php.ini в произвольном каталоге сайта без подтверждения, что именно этот обработчик будет его читать. Сначала выясните механизм, предусмотренный вашей платформой.

5. Просмотрите дополнительные INI-файлы и дубли

php_ini_scanned_files показывает дополнительные INI-файлы, разобранные после основного. Список включает полные пути. Наличие файла в этом списке само по себе не доказывает корректность каждой записи: при проблеме разбора проверяйте также журнал запуска.

По правилам PHP дополнительные каталоги задаются сборкой и могут переопределяться через PHP_INI_SCAN_DIR; внутри каталога INI-файлы читаются в алфавитном порядке. Поэтому найдите все активные определения нужной директивы в реально прочитанном наборе. Не делайте вывод по первым найденным строкам в одном файле.

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

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

6. Сравните global_value, local_value и момент чтения

ini_get возвращает текущее значение директивы. Обычно это строка; выключенная логическая настройка может выглядеть как пустая строка или "0". Отсутствие директивы проверяют строго через === false, чтобы не спутать его с допустимым выключенным значением. Единицы также сохраняют значение: строка "128M" не равна числу 128 байт.

При включённых подробностях ini_get_all предоставляет global_value и local_value, а также сведения об уровне доступа. Сравнение базового и локального значений помогает заметить переопределение. Однако эти поля не являются полной историей: они не сообщают, какой конкретно файл или строка приложения последними задали значение.

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

Совпадение global и local тоже не доказывает отсутствие промежуточных изменений: разные источники могли задать одинаковое значение. Закрывайте гипотезу сопоставлением конфигурации с кодом, а не одним снимком. Для приёмки решающим будет значение именно в том месте, где оно используется.

7. Проверьте режимы PHP_INI_* и допустимое место изменения

Не каждую директиву разрешено менять из скрипта или каталога сайта. Обозначения режимов часто встречаются в инструкциях как PHP_INI_*; в текущем справочнике допустимых мест изменения используются названия INI_USER, INI_PERDIR, INI_SYSTEM и INI_ALL. Проверяйте режим конкретной директивы для используемой версии.

Режим	Что важно для диагностики	Типичная ошибочная попытка
INI_USER	Предусматривает изменение пользовательским кодом; поддерживается в .user.ini	Ожидать постоянного изменения файла после ini_set
INI_PERDIR	Предусматривает настройку до исполнения скрипта на разрешённом уровне	Менять такую директиву обычным ini_set
INI_SYSTEM	Требует системного уровня настройки	Пытаться изменить её пользовательским файлом каталога
INI_ALL	Допускает разные уровни, с учётом административных ограничений	Считать, что приложение всегда может отменить политику хостинга

Эта классификация указывает допустимый уровень, но не заменяет документацию обработчика и ограничения значения. Важен и момент применения: настройка, влияющая на подготовку запроса, не исправит уже выполненную подготовку. Поэтому не переносите любую найденную строку в ini_set() только ради удобства.

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

8. Проверьте настройки пула PHP-FPM

FPM может задавать параметры PHP для отдельного пула. В официальной конфигурации FPM описаны php_value, php_flag, php_admin_value и php_admin_flag. Значения административного уровня нельзя переопределить через ini_set(). Поэтому правильная правка основного файла может не изменить итоговую настройку конкретного сайта.

Учебный фрагмент ниже относится именно к существующей конфигурации выбранного пула FPM. Это не содержимое обычного php.ini и не инструкция для любого хостинга. Он показывает административно закреплённый часовой пояс и отключённый вывод ошибок посетителю:

php_admin_value[date.timezone] = UTC
php_admin_flag[display_errors] = off

Установите, в какой пул фактически направляется домен. Правка похожего файла соседнего сайта не даст результата. Если платформа передаёт настройки через конфигурацию веб-сервера и FastCGI, проверьте и этот источник. Не воспринимайте запись пула как единственно возможное место административного значения.

Исправление выбирают по назначению политики. Если значение закреплено осознанно, меняют его через ответственного администратора или адаптируют приложение. Если приложение пытается самовольно переопределить правило, устраняют ошибочную настройку приложения. Нельзя считать отказ ini_set доказательством повреждения PHP: он может быть ожидаемым результатом действующих ограничений.

9. Проверьте применимость .user.ini и срок кеширования

Файлы .user.ini обрабатываются только CGI/FastCGI SAPI. Это не универсальный способ изменить любой PHP, в частности консольный запуск их таким образом не подхватывает. Допускаются настройки соответствующих пользовательских и каталожных режимов, включая INI_ALL; системные директивы сюда переносить нельзя.

Учитывайте расположение реально исполняемого PHP-файла. Поиск идёт от его каталога к document root, а не по красивому адресу страницы в браузере. Если маршрут /catalog/ обслуживает общий index.php в корне, создание .user.ini в отдельной папке catalog может оказаться неверным выбором места.

Имя файла управляется user_ini.filename; пустое значение отключает этот поиск. Период перечитывания задаёт user_ini.cache_ttl, по умолчанию 300 секунд, то есть пять минут. Поэтому мгновенная проверка после сохранения может видеть старое состояние. Уточните действующее значение TTL и повторите запрос после соответствующего интервала.

Ожидание не решает ошибку режима, пути или отключённого поиска. Если результат не изменился, вернитесь к этим условиям. Не уменьшайте TTL для всего сервера без необходимости. Дополнительно проверьте, что служебный файл нельзя скачать через сайт, и не храните в нём секреты, которым там не требуется находиться.

10. Найдите переопределение внутри приложения

CMS, библиотека или загрузочный файл могут менять разрешённую директиву после старта запроса. Ищите точное имя параметра в конфигурации проекта и вызовах изменения настройки. Отдельно проверьте переменные окружения и настройки панели приложения, из которых затем формируется значение. Это особенно полезно, когда закрытый отдельный файл показывает ожидаемый результат, а рабочий маршрут — другой.

По описанию ini_set успешный вызов возвращает прежнее значение, а отказ — false. Проверять отказ нужно строго: прежняя пустая строка тоже может быть законным результатом успеха. После вызова читают фактическое значение, а не делают вывод только по отсутствию видимого предупреждения.

Изменение через ini_set действует на время выполнения скрипта и не переписывает исходный INI-файл. Для долгоживущего воркера скрипт может обрабатывать несколько заданий, поэтому настройка, изменённая в одной задаче, требует продуманного восстановления перед следующей. Не переносите представление «одна задача — один короткий запрос» на такой исполнитель автоматически.

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

11. Примените изменение к конкретному потребителю

После правки определите, кто читает этот источник. Для стартовых настроек PHP-FPM потребуется предусмотренное платформой перечитывание конфигурации или обновление процессов соответствующей службы. Для PHP как модуля веб-сервера жизненный цикл связан с этим сервером. Новый запуск CLI читает свои стартовые параметры заново; уже работающий воркер от этого не меняется.

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

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

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

12. Учебный пример: файл изменён, значение осталось прежним

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

Сначала команда подтверждает версию, SAPI и путь загруженного файла: они соответствуют ожидаемым. Затем проверяет дополнительные INI-файлы и не находит другого определения. В конфигурации фактического пула обнаруживается php_admin_value[date.timezone] с прежним значением. Попытка менять параметр в приложении также не решает задачу из-за административного ограничения.

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

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

13. Закройте задачу проверкой и короткой записью

Результат ремонта описывают через фактическое состояние: какая директива изменена, для какого обработчика, из какого управляемого источника и каким запросом это подтверждено. Такая запись полезнее перечня перезапущенных служб. Она позволит воспроизвести настройку при переносе сайта или создании нового экземпляра.

1. Подтвердите ожидаемое значение в нужном HTTP-маршруте и моменте исполнения.
2. Проверьте затронутый прикладной сценарий безопасными тестовыми данными.
3. Сверьте остальные узлы и исполнители, для которых изменение должно действовать.
4. Убедитесь, что журналы не содержат новых ошибок чтения конфигурации.
5. Удалите временную диагностику и сохраните краткий результат в закрытой документации.

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

Для внешнего контроля HTTP-доступности после изменений подключите SiteGuard. Фактические значения PHP и результат прикладного сценария проверяйте в своём окружении.