PHP-настройки на виртуальном хостинге: .user.ini, php_value и безопасные лимиты

Для разработчика на виртуальном хостинге умение быстро и безопасно править настройки PHP — ежедневная рутина: где-то не хватает memory_limit, у формы загрузки упирается upload_max_filesize, а у админки валится импорт из-за max_execution_time. В этой статье собрал практический минимум: как работают .user.ini и php_value в .htaccess, чем они отличаются, какие лимиты выбирать для типичных сайтов и CMS, и как убедиться, что изменения действительно вступили в силу.

Зачем менять PHP-настройки на виртуальном хостинге

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Как PHP применяет конфигурацию: уровни и приоритеты

Настройки PHP могут задаваться на разных уровнях: глобальный конфиг (на стороне провайдера), настройки пула PHP-FPM, директивы в Apache для mod_php, а также пользовательские файлы — .user.ini и .htaccess. Понимание цепочки приоритетов помогает избежать сюрпризов, когда изменения не срабатывают.

Что у вас запущено: SAPI

От способа запуска PHP (SAPI) зависит, какой метод конфигурирования доступен:

• PHP-FPM / FCGI — самый распространённый на виртуальном хостинге сегодня. Пользовательские изменения применяются через .user.ini. Многие системные директивы (например, часть opcache.*) нельзя переопределить в .user.ini.
• Apache mod_php — устаревающий вариант, но всё ещё встречается. Локальные настройки задаются через .htaccess с php_value/php_flag.
• CLI — отдельный контур. Значения в консоли часто отличаются от веб-пула. Помните об этом при проверках через SSH.

Быстрый способ понять, что у вас используется: выведите phpinfo() в вебе и посмотрите Server API. Если там FPM/FastCGI — используйте .user.ini; если Apache 2.0 Handler — подойдёт .htaccess с php_value.

.user.ini: включение и кэш

Поддержка .user.ini определяется директивами user_ini.filename и user_ini.cache_ttl на стороне сервера. Как правило, имя — .user.ini, а кэш — 300 секунд. Это значит, что изменения не всегда моментальны: подождите несколько минут или «дотроньтесь» до файла (измените время модификации), чтобы инвалидация прошла быстрее.

.htaccess и php_value

php_value и php_flag в .htaccess работают только при mod_php. Если у проекта FPM, такие строки будут проигнорированы, а иногда даже вызовут ошибку 500. Никогда не мешайте подходы: используйте тот, который соответствует вашей SAPI.

.user.ini: быстрый старт

Создайте файл .user.ini в корне сайта (публичной директории) и задайте нужные значения. Пример минимального набора:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 60
max_input_time = 60
max_input_vars = 3000
date.timezone = Europe/Moscow
log_errors = On
display_errors = Off

Несколько замечаний:

• Единицы — краткие: M, G. Не используйте MB — это невалидно.
• post_max_size должно быть не меньше upload_max_filesize, иначе загрузки будут обрываться.
• date.timezone задайте явно, чтобы избежать неожиданных смещений времени в логах и планировщиках.
• В продакшене никогда не включайте display_errors; используйте log_errors и проверьте, куда пишется лог (error_log, если разрешено).

.htaccess: когда уместен php_value и php_flag

Если проект работает под mod_php, задайте директивы через .htaccess:

<IfModule mod_php8.c>
  php_value memory_limit 256M
  php_value upload_max_filesize 64M
  php_value post_max_size 64M
  php_value max_execution_time 60
  php_value max_input_time 60
  php_value max_input_vars 3000
  php_flag log_errors On
  php_flag display_errors Off
</IfModule>

php_flag применяют для булевых значений (On/Off), php_value — для остальных. Если модуль mod_php другой версии, имя в блоке <IfModule ...> будет иным (например, mod_php7.c).

Безопасные лимиты: как выбирать

Ключевой принцип: задавайте столько, сколько требуется задаче, и оставляйте запас, но не порядок величины. На виртуальном хостинге чрезмерные значения увеличивают риск «выстрелить себе в ногу»: долгая сборка ответа и рост потребления памяти ухудшают соседние процессы и повышают шанс убийства процесса по лимитам провайдера.

Практические ориентиры для большинства типичных сайтов:

• Небольшой сайт/лендинг/блог без тяжёлого админского импорта: memory_limit 128–192M, upload_max_filesize 16–32M, post_max_size 16–32M, max_execution_time 30–60.
• CMS со статьями и медиабиблиотекой, плагинами: memory_limit 256M, upload_max_filesize 64M, post_max_size 64–96M, max_execution_time 60–90.
• Импорты/экспорт, построение миниатюр, бэкапы из админки: memory_limit 384–512M (временно под конкретную задачу), upload_max_filesize 128M, post_max_size 128–160M, max_execution_time 120–300.

Не ставьте memory_limit = -1 (безлимит) на виртуальном хостинге. Это почти гарантированный способ словить обрыв процесса от изоляции или уткнуться в физический предел контейнера.

Загрузка файлов: связка upload_max_filesize, post_max_size, max_file_uploads

Для корректной загрузки учитывайте сразу несколько слоёв:

• upload_max_filesize — максимум одного файла.
• post_max_size — максимум всего тела запроса (должно быть не меньше upload_max_filesize плюс накладные данные формы).
• max_file_uploads — лимит количества файлов в одном запросе.
• Ограничение веб-сервера (например, client_max_body_size в Nginx или LimitRequestBody в Apache) — на виртуальном хостинге обычно фиксировано провайдером и может «перекрывать» значения PHP.

Пример разумной связки для медиабиблиотеки: upload_max_filesize = 64M, post_max_size = 64M или немного больше, max_file_uploads = 20. Если используете множественную загрузку, следите, чтобы суммарный размер файлов плюс накладные не превышал post_max_size.

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

memory_limit ограничивает общий объём памяти, доступный одному PHP-процессу, включая сам интерпретатор, расширения и структуры данных приложения. При операциях вроде генерации миниатюр, экспорта в ZIP, парсинга больших XML/CSV буфера растут быстро. Если вы видите «Allowed memory size exhausted», повышайте лимит постепенно и оптимизируйте код: разбивайте обработку на батчи, используйте потоковую обработку, уменьшайте размер изображений на клиенте.

Частая ловушка — путать memory_limit с памятью пула FPM. На виртуальном хостинге вы не управляете pm и размером пула; высокий memory_limit увеличивает пик на каждый процесс. Если одновременно выполняется несколько тяжёлых запросов, суммарное потребление может взлететь и спровоцировать общий лимит аккаунта. Если вам нужна тонкая настройка пула, подумайте о переезде на VDS и смотрите материал по теме: тюнинг PHP-FPM на VDS.

Про opcache: большинство директив opcache.* — уровня SYSTEM и в .user.ini не меняются. Не удивляйтесь, если попытка правки проигнорирована. Конфигурация кэша обычно задаётся провайдером.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Время выполнения: max_execution_time и max_input_time

max_execution_time ограничивает время работы скрипта в секундах (без учёта времени парсинга входных данных). max_input_time — время на парсинг входа. Для длительных импортов и генераций полезно временно повышать max_execution_time до 120–300, но лучше переразбить задачу на несколько шагов или фоновые процессы. На уровне веб-сервера также могут быть таймауты (например, у прокси). На виртуальном хостинге эти таймауты менять нельзя, поэтому не завышайте без крайней нужды. Для долгих задач рассмотрите очереди и фоновые воркеры — см. как запускать очереди через systemd.

max_input_vars: длинные формы, фильтры в админке

Если при сохранении больших форм исчезают поля — вероятно, упёрлись в max_input_vars (по умолчанию 1000). Для сложных админок ставят 3000–5000. Но помните, что слишком большое значение замедляет парсинг входа и повышает потребление памяти из-за массива $_POST. Ищите баланс и оптимизируйте форму: вкладки, пагинация, группировка.

Профили под популярные сценарии

Ниже — практические профили, которые обычно «заводятся с пол-оборота». Это не догма: проверяйте требования плагинов и бандлов.

• Типовой блог/корпоративный сайт: memory_limit = 192M, upload_max_filesize = 32M, post_max_size = 32M, max_execution_time = 60, max_input_vars = 2000.
• CMS с медиа и формами: memory_limit = 256M, upload_max_filesize = 64M, post_max_size = 64M, max_execution_time = 90, max_input_vars = 3000.
• Импорт каталога/контента в админке: memory_limit = 512M (на время операции), upload_max_filesize = 128M, post_max_size = 160M, max_execution_time = 300, max_input_vars = 5000. После импорта верните значения на прежний уровень.

Как проверить, что настройки применились

Лучший способ — веб-скрипт, исполняемый тем же пулом, что и ваш сайт. Создайте файл, например phpinfo.php:

<?php phpinfo(); ?>

Откройте его в браузере, найдите изменённые директивы и убедитесь, что локальное значение (Local Value) равно ожидаемому. После проверки удалите файл — он подробно раскрывает конфигурацию окружения и не должен висеть в продакшене.

Альтернатива — точечный вывод значений:

<?php
header('Content-Type: text/plain');
$keys = ['memory_limit','upload_max_filesize','post_max_size','max_execution_time','max_input_time','max_input_vars','date.timezone'];
foreach ($keys as $k) {
  echo $k . ': ' . ini_get($k) . "\n";
}
?>

Помните: значения в CLI (через SSH) могут отличаться. Если проверяете командой php -i, это показывает конфиг для консоли, а не для веба.

Порядок и область действия .user.ini

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

Полезный приём: держите базовые умеренные лимиты в корне, а для «тяжёлых» разделов создавайте локальные .user.ini с повышенными значениями. Так вы ограничите зону повышенного потребления ресурсов.

Частые ошибки, из-за которых настройки не применяются

• Неверный метод для SAPI: используете php_value при FPM — не сработает. Для FPM — .user.ini.
• Опечатки и лишние пробелы: директивы чувствительны к имени. Проверьте, что написали именно memory_limit, а не memory-lim it.
• Неверные единицы: 128MB — неверно; должно быть 128M.
• Забыли про кэш .user.ini: подождите 3–5 минут или обновите время модификации.
• Ограничение веб-сервера: PHP-размеры увеличены, но client_max_body_size или аналогичный лимит на стороне веб-сервера меньше.
• Системные директивы: часть опций (например, многие opcache.*) нельзя менять в .user.ini.

Логи и безопасность: что включить, а что — нет

В продакшене держите display_errors = Off; ошибки должны уходить в логи (log_errors = On). Если окружение позволяет задавать файл лога, используйте error_log в каталоге с ограниченным доступом. Убедитесь, что логи не копятся бесконечно: настройте ротацию на уровне панели или менеджера логов, если доступно.

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

Чек-лист перед выкатыванием на прод

• Определили SAPI сайта через phpinfo().
• Выбрали правильный метод: .user.ini для FPM/FCGI или .htaccess с php_value для mod_php.
• Подобрали умеренные лимиты под задачу, не создающие каскадного роста потребления.
• Согласовали связку upload_max_filesize и post_max_size; учли серверные лимиты тела запроса.
• Выставили display_errors = Off, log_errors = On, настроили место хранения логов.
• Проверили применённые значения через веб-скрипт, а не CLI.
• Удалили диагностические скрипты после проверки.

Мини-FAQ

Можно ли одним файлом настроить сразу весь аккаунт? На виртуальном хостинге — только в рамках каталога сайта и его поддиректорий через .user.ini. На соседние сайты в аккаунте это не подействует.

Почему я не могу изменить параметры opcache? Большинство директив opcache.* — уровня SYSTEM, меняются только в глобальной конфигурации.

Изменения в .user.ini не видны сразу. Это нормально? Да, из-за user_ini.cache_ttl. Подождите несколько минут или обновите метку времени у файла.

Почему upload_max_filesize поднял до 200M, а загрузка всё равно обрывается на ~50M? Вероятно, на стороне веб-сервера стоит ограничение тела запроса меньше указанного. На виртуальном хостинге оно фиксировано провайдером.

Нужно ли после изменения .user.ini перезапускать что-то? Нет, для FPM это подхватывается автоматически после истечения кэша пользовательских INI.

Если подойти к настройкам PHP вдумчиво — через .user.ini или php_value — даже на типовом виртуальном хостинге можно добиться стабильной работы проекта без избыточных лимитов и неожиданных регрессий. Держите конфиг под контролем, проверяйте эффекты через phpinfo() и постепенно подстраивайте значения под реальные нагрузки.