После изменения upload_max_filesize сервер не принимает файл

#Симптомы, область применения и причины

Лимит upload_max_filesize увеличен, однако форма загрузки выдаёт ошибку или не передаёт файл. Диагностика post_max_size, реального php.ini, лимита Nginx/Apache, временного каталога и кода ошибки PHP. После изменения одного ограничения не следует автоматически увеличивать всё подряд: нужно определить слой, который отклонил конкретный HTTP-запрос, и сравнить активные параметры PHP именно для сайта.

#Безопасная диагностика и пошаговое исправление

1. Определите точный отказ в браузереОткройте страницу с формой загрузки; нажмите F12 → «Сеть» (Network), выберите отправку файла и найдите запрос POST к серверу. Запишите статус HTTP и размер файла, но не копируйте в отчёт имя файла с личными данными. Если видите 413, запрос отверг веб-сервер или прокси; если 200/4xx с сообщением приложения — смотрите его проверку. Отдельно испытайте маленький заранее безопасный файл того же типа.

1. Проверьте реальную конфигурацию обработчика сайтаОткройте панель управления → нужный сайт → настройки PHP. Посмотрите upload_max_filesize, post_max_size, file_uploads, upload_tmp_dir, версию и режим PHP. CLI-команда php --ini показывает настройки терминала, которые могут не совпадать с FPM; это не доказательство рабочего лимита сайта. Разработчик может временно записать значения ini_get для веб-запроса в закрытый служебный журнал и удалить код после проверки.
2. Пример кода по теме

   PHPКопировать всёВыделить

   Исполняйте только во внутреннем тестовом маршруте сайта; результаты попадут в журнал PHP и не должны выводиться посетителям.

   <?php
   foreach (['upload_max_filesize','post_max_size','file_uploads','upload_tmp_dir'] as $name) {
       error_log($name.'='.ini_get($name));
   }

1. Сравните размер файла с суммарным POSTНапример, если загружаете файл размером 50 МБ, upload_max_filesize может быть 64M, а post_max_size — 32M. Тогда весь запрос будет отклонён до обработки файла. Установите для конкретного сайта post_max_size выше upload_max_filesize, учитывая дополнительные поля формы, например 80M при 64M. Предварительно запишите старые значения, не снимайте ограничение полностью: это защита памяти и ресурсов сервера.

1. Уточните, не перехватывает ли запрос NginxЕсли браузер показывает HTTP 413, проверьте конфигурацию Nginx для фактического server_name и location: параметр client_max_body_size. В SSH выполните sudo nginx -T только для просмотра объединённой конфигурации (вывод может содержать секреты, его нельзя публиковать целиком). Если запрос проходит через несколько прокси, сравните лимиты каждого. Править следует один затронутый серверный блок, а не общий лимит для всех сайтов.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Тест синтаксиса Nginx после правки файла и до применения конфигурации. Права администратора обязательны.

   sudo nginx -t

1. Проверьте временный каталог и код загрузкиПопросите разработчика для контрольного теста зарегистрировать $_FILES["file"]["error"] (вместо file укажите настоящее имя поля), но не содержимое и не полный путь файла. Значение 1 относится к upload_max_filesize, 2 — ограничению формы MAX_FILE_SIZE, 3 — частичной загрузке, 6 — отсутствию временного каталога, 7 — ошибке записи. Для 6–7 проверьте наличие дискового пространства и доступность upload_tmp_dir пользователю PHP-FPM. Нельзя делать каталог доступным всем через chmod 777.
2. Замените file на реальное имя поля формы

   PHPКопировать всёВыделить

   Замените file на реальное имя поля формы. Не записывайте содержимое загружаемых данных и удалите отладку после проверки.

   <?php
   // Только в контролируемом обработчике после POST:
   if (isset($_FILES['file'])) {
       error_log('upload error code: '.(int)$_FILES['file']['error']);
   }

1. Примените точечное изменение и проверьте конфигурациюВ панели нажмите «Сохранить» или «Применить» для выбранного сайта. Если изменяли Nginx вручную, сначала сохраните копию конфигурационного файла, выполните тест sudo nginx -t и лишь при успешном тесте используйте sudo systemctl reload nginx (только для сервера с systemd и службой nginx). При изменениях php.ini/pool PHP-FPM сначала проверьте соответствующий конфиг FPM и выполните плавную перезагрузку нужной службы или штатное применение панели; не перезапускайте все службы без необходимости.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Исполняйте только после успешного nginx -t, если Nginx действительно принимал запрос и менялся его конфиг.

   sudo systemctl reload nginx

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

1. Проверьте не только удачный, но и отклонённый файлЗагрузите безопасный файл нужного размера и убедитесь, что приложение сохранило его в ожидаемом месте. Затем попробуйте тестовый файл, превышающий установленный предел: сервер должен корректно отклонить его и сообщить пользователю об ограничении. Если первый не проходит, верните значения и проверьте настройки приложения/балансировщика; если второй проходит без ограничений, настройка стала слишком широкой и требует пересмотра.

#Как проверить результат и что делать дальше

Успешная проверка включает корректный HTTP-ответ, наличие файла у приложения и отсутствие новой ошибки PHP; если виноват Nginx, из журнала исчезает 413 именно на контрольном запросе. При неуспехе восстановите сохранённые пределы, не раскрывайте общий каталог загрузок и передайте разработчику код $_FILES и HTTP-код.