Изображение, которое пользователь пытается загрузить через форму на сайте, "не загружается" без внятного объяснения — одна из самых частых жалоб, за которой почти всегда стоит одна и та же небольшая группа причин на стороне сервера. Разберём настройки PHP, отвечающие за загрузку файлов, и как их правильно синхронизировать.
Два разных лимита PHP
; php.ini
upload_max_filesize = 20M
post_max_size = 25M
upload_max_filesize ограничивает размер одного
загружаемого файла, post_max_size — размер всего
POST-запроса целиком, включая все файлы формы вместе и остальные
поля. Значение post_max_size обязательно должно быть
больше upload_max_filesize — если формы допускают
несколько файлов сразу (например, загрузка нескольких изображений
товара), суммарный размер легко превышает лимит одного файла,
даже когда каждый файл в отдельности укладывается в него.
Симптом при превышении post_max_size
Особенность превышения именно post_max_size в том,
что PHP обрезает весь запрос целиком ещё до того, как скрипт
успевает его обработать, — в результате форма показывает
не конкретную ошибку о превышении размера, а просто теряет все
данные формы, включая обычные текстовые поля, что сбивает с толку
при диагностике: кажется, что форма вообще не отправляется.
Нужна помощь с Битрикс?
Где реально менять эти значения
На хостинге с доступом к php.ini напрямую — правка
файла и перезапуск PHP-FPM. На виртуальном хостинге без прямого
доступа — обычно есть панель управления с разделом настроек PHP
для конкретного сайта или возможность переопределить значения
через .htaccess (только если используется Apache
с mod_php, для PHP-FPM этот способ не сработает):
# .htaccess (только для Apache + mod_php)
php_value upload_max_filesize 20M
php_value post_max_size 25MЛимит на стороне nginx
# nginx.conf, в блоке server или location
client_max_body_size 25M;
Даже если лимиты PHP настроены правильно, отдельный лимит nginx
client_max_body_size может обрезать запрос ещё раньше,
до того как он вообще дойдёт до PHP, — в этом случае симптом
выглядит как ошибка 413 Request Entity Too Large, а не как молчаливая
потеря данных формы. Оба лимита — PHP и nginx — нужно синхронизировать
между собой, увеличение одного без другого не решает проблему
полностью.
Ограничение на стороне самого Битрикса
Помимо серверных лимитов, некоторые компоненты и модули (например, файловые свойства инфоблока) имеют собственное ограничение максимального размера загружаемого файла, настраиваемое в параметрах компонента или свойства, — оно может оказаться строже серверного лимита и обрезать загрузку раньше, даже если PHP и nginx формально пропустили бы файл большего размера.
Диагностика: где именно теряется файл
Последовательная проверка от сервера к приложению: сначала лимиты
nginx, затем PHP (upload_max_filesize,
post_max_size), затем настройки конкретного компонента
или свойства инфоблока в самом Битриксе. Проверка через
phpinfo() или административную панель
Настройки → Инструменты разработчика
→ Информация о системе показывает реально
применённые PHP-лимиты, что полезно, когда неясно, применилось ли
изменение php.ini после правки.
Частые ошибки
- Изменён только upload_max_filesize без post_max_size. Форма с несколькими файлами всё равно теряет данные при загрузке.
- Синхронизирован только PHP-лимит, но не nginx. client_max_body_size обрезает запрос раньше, чем он доходит до PHP.
- Изменение php.ini не подхватилось без перезапуска PHP-FPM. Диагностика продолжается с устаревшими значениями лимитов.
- Собственный лимит компонента строже серверного. Загрузка обрезается раньше, чем позволяют настройки сервера.
Итог
Проблема с загрузкой изображений почти всегда сводится
к рассинхронизации лимитов на разных уровнях — PHP
(upload_max_filesize и post_max_size),
веб-сервера (client_max_body_size в nginx) и, иногда,
собственных ограничений конкретного компонента Битрикса. Проверять
их стоит последовательно от сервера к приложению, а не менять
значения наугад в одном месте, не проверив остальные.