Ошибка 413 при загрузке: какой слой отклонил файл

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

Установите место отказа

Сохраните адрес функции загрузки, время, HTTP-статус и безопасные сведения об ответе. Затем сопоставьте получение запроса на доступных участках: внешняя доставка, прокси, PHP и приложение. Название сервера на странице ошибки — подсказка, но не полный маршрут.

В документации nginx client_max_body_size ограничивает тело клиентского запроса и при превышении приводит к 413. Если отказ произошёл здесь, изменение только PHP не заставит этот запрос пройти дальше.

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

Файл — только часть multipart-запроса

По RFC 7578 multipart/form-data состоит из частей, разделителей и заголовков частей. Внутри могут передаваться и файлы, и другие поля. Поэтому общий размер тела нельзя приравнять к сумме размеров выбранных файлов.

Учебный пример: два файла по 8 MiB дают 16 MiB только файловых данных. Если предел тела тоже 16 MiB, место для оформления multipart и дополнительных полей уже не предусмотрено. Это не рекомендуемый тарифный лимит и не замер браузерного запроса.

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

Таблица границ для одной загрузки

Следующая карта — предлагаемый протокол диагностики. Заполняйте только существующие в своей цепочке уровни. У внешнего посредника и у приложения могут быть собственные условия, которые надо подтвердить по действующей конфигурации.

Что происходит на стороне PHP

В описании директив PHP post_max_size относится к POST-данным в целом, а upload_max_filesize — к одному загружаемому файлу. Для загрузки значение общего предела должно быть больше ограничения одного файла. Также существует отдельное ограничение числа одновременно загружаемых файлов.

Там же описано, что при превышении post_max_size массивы $_POST и $_FILES оказываются пустыми. Это отличается от обычного получения каждого файла с отдельным результатом. Само отсутствие полей, однако, нужно сопоставить с реальным запросом, а не считать единственной возможной причиной.

Не объявляйте любой PHP-отказ автоматически HTTP 413. Выясните, какой ответ формирует используемая цепочка. Пользователю нужна корректная причина, а разработчику — понимание, на каком этапе ещё доступны сведения для диагностики.

Проверяйте настройки действующего веб-обработчика

В документации конфигурации PHP поиск php.ini зависит, в частности, от SAPI и условий запуска. Поэтому значение, увиденное в командной строке, не подтверждает автоматически настройку обработчика этого сайта.

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

Для поддержки сайта полезен паспорт загрузки: маршрут, поддерживаемый формат, число файлов и пределы. Так правка относится к реальной функции, а не к случайно найденному php.ini.

Большая загрузка требует бюджета после приёма

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

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

Проверьте успех, отказ и сохранность формы

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

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

1. Сохраните точную попытку, ответ и согласованный размер загрузки.
2. Нарисуйте фактическую цепочку до приложения.
3. Найдите первый подтверждённый отказ по объёму тела или файла.
4. Проверьте эффективную настройку нужного маршрута и обработчика.
5. Рассчитайте общий бюджет формы и последующей работы.
6. Измените только согласованную причину и подтвердите применение.
7. Проверьте успешную загрузку, штатный отказ и отсутствие частичного результата.

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