Ошибка 413 Request Entity Too Large: что делать при загрузке большого файла

Ошибка 413 Request Entity Too Large означает, что принимающая сторона отклонила запрос из-за слишком большого объёма передаваемых данных. Обычно это заметно при загрузке документа, фотографии, архива или нескольких вложений. Но причина может находиться в разных местах: на CDN, обратном прокси, веб-сервере или внутри приложения.

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

Что означает ошибка 413 Request Entity Too Large

Код 413 относится к HTTP-ответам, которыми получатель сообщает о невозможности принять содержимое запроса установленного размера. Современное название в стандарте — 413 Content Too Large. В сообщениях серверов также встречаются Payload Too Large и Request Entity Too Large. Разница в формулировке не меняет основное направление проверки: нужно исследовать объём отправляемых данных и действующие ограничения. Названия и значение статуса поясняет справочник MDN.

Ошибка не означает, что весь сайт недоступен. Главная страница может нормально открываться, пока запрос загрузки файла возвращает 413. Также проблема не обязательно связана с файлом: большой JSON, XML или пакет данных интеграции способен превысить ограничение тела запроса.

По RFC 9110 сервер может прекратить приём запроса или закрыть соединение. Если ограничение временное, предусмотрено сообщение о времени повторной попытки через Retry-After. Однако ожидание не уменьшает файл: при постоянном лимите тот же запрос обычно снова будет отклонён.

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

Почему файл меньше лимита, а запрос всё равно слишком большой

Размер выбранного файла и размер тела HTTP-запроса — разные величины. При отправке формы в формате multipart/form-data вместе с содержимым файла передаются разделители частей, описания полей и другие значения формы. Структура такого тела определена в RFC 7578. Поэтому лимит полного тела запроса должен учитывать дополнительный объём.

Если пользователь прикрепил несколько файлов, в одном запросе может оказаться их суммарный размер. Ограничение «до 10 МБ на файл» не обязательно означает, что форма разрешает отправить десять таких файлов одновременно. У приложения могут быть отдельные правила для одного вложения, общей суммы и количества файлов.

Сравнивайте значения в одинаковых единицах. Интерфейс может округлять мегабайты, а сервер — проверять точное число байтов. Для пограничного случая запишите фактический размер и используемую систему единиц. МиБ — это 1 048 576 байт; обозначение МБ в интерфейсах не всегда используется последовательно.

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

Что делать посетителю при ошибке 413

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

Проверьте правила вложений

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

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

Уменьшите файл подходящим способом

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

Переименование расширения не уменьшает размер и не меняет настоящий формат. Архив тоже не всегда подходит: сайт может его не принимать, а уже сжатые изображения и видео не обязательно заметно уменьшатся. Выбирайте способ, который разрешён правилами загрузки и сохраняет нужное содержимое.

Используйте предусмотренный альтернативный канал

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

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

Как владельцу определить, какой компонент вернул 413

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

1. Найдите отклонённый запрос. Откройте Network в инструментах разработчика браузера и повторите допустимый тестовый сценарий. Зафиксируйте URL, метод, статус и сообщение ответа.
2. Опишите состав данных. Сколько файлов отправлено, каков их размер, какие поля формы присутствуют? Проверяется один файл или вся форма?
3. Сохраните время и идентификатор. Используйте часовой пояс и request ID, если он показан. По ним проще сопоставлять события между уровнями.
4. Проверьте журналы по цепочке. Найдите отказ на CDN, прокси, веб-сервере и в приложении. Определите первый компонент, который отклонил допустимую загрузку.
5. Сравните эффективный лимит с запросом. Проверяйте реально применённую настройку для нужного маршрута, а не только значение в найденном файле конфигурации.

Просмотр заголовков, отправленных данных и ответа разобран в документации Chrome DevTools. Обычное открытие адреса через GET не воспроизводит загрузку POST с телом. Для расследования нужен тот запрос, на котором произошёл отказ.

Логотип сервиса или заголовок Server дают подсказку, но не заменяют журналы. Если приложение не увидело запрос, сначала проверьте предыдущие уровни и полноту логирования. Отсутствие записи в одном журнале не является окончательным доказательством точки отказа.

В журнале полезны маршрут, метод, статус, время, идентификатор запроса и зафиксированный компонентом размер, если такой показатель доступен. Полное содержимое документа для поиска лимита обычно не требуется. Сравните успешную и неуспешную попытки на одном маршруте: одинаковы ли состав формы, способ передачи и число вложений? Иначе вы рискуете объяснять разницу размером файла, хотя запросы проходят через разные обработчики. Само сообщение «файл слишком большой» в интерфейсе тоже проверьте по реальному сетевому ответу.

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

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

Какие ограничения проверить в Nginx, Apache, PHP и CDN

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

Nginx: client_max_body_size

В Nginx директива client_max_body_size ограничивает размер тела клиентского запроса; превышение приводит к 413. Она допустима в контекстах http, server и location. Назначение и синтаксис приведены в официальной документации.

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

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

Apache: LimitRequestBody

Для Apache проверьте LimitRequestBody. Эта директива задаёт допустимый объём тела запроса в байтах и применяется в определённой области конфигурации. Точные контексты и поведение зависят от установленной версии; сверяйтесь с документацией Apache.

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

PHP: ограничение файла и всего POST

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

Превышение PHP-лимита не следует автоматически называть HTTP 413. Например, при превышении post_max_size массивы $_POST и $_FILES могут оказаться пустыми. Какой ответ увидит пользователь, зависит от обработки этого случая приложением. Поэтому проверяйте статус, серверные сообщения и состояние входных данных вместе.

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

CDN, шлюз и ограничения приложения

В панели CDN проверьте разрешённый размер запроса для нужного домена и действующие условия услуги. Например, Cloudflare описывает собственные лимиты входящей загрузки и возможность настройки в пределах доступных условий. Значение в php.ini не управляет таким внешним ограничением.

В CMS или API исследуйте отдельные лимиты обработчика, парсера тела и поля загрузки. Если инфраструктура принимает запрос, а приложение отвергает файл, нужно понять его собственные правила. При штатной поддержке можно использовать загрузку частями с возобновлением. Этот механизм требует согласованного протокола клиента и сервера; добавление одного заголовка не создаёт его автоматически.

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

Пример: как согласовать лимиты для одной формы

Рассмотрим условную политику: форма принимает один файл до 20 МиБ и небольшие текстовые поля. Команда выбрала предел тела запроса 24 МиБ с учётом проверенного дополнительного объёма. Это пример логики настройки, а не готовые значения для любого сайта.

Для соответствующего уже существующего обработчика Nginx может использоваться такая директива:

client_max_body_size 24m;

В применяемой веб-приложением конфигурации PHP выбранную политику отражают отдельные параметры:

upload_max_filesize = 20M
post_max_size = 24M

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

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

Как проверить исправление ошибки 413

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

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

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

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

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

Как уменьшить повторные ошибки загрузки

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

Клиентская проверка позволяет раньше показать сообщение, но серверная проверка всё равно нужна. Согласуйте текст интерфейса с реальной политикой. Ошибка, при которой форма обещает принять документ, а инфраструктура отклоняет его по меньшему порогу, особенно неудобна после длительного заполнения.

Регулярный контроль общедоступных страниц помогает сопоставлять изменения ответа с релизами и жалобами. При планировании этой работы можно перейти на SiteGuard и описать важные сценарии сайта. Проверка обычного адреса не воспроизводит загрузку файла, поэтому контроль POST-запроса и его результата выполняйте отдельно.

Что написать хостингу или разработчику

Передайте URL формы, действие, время с часовым поясом, HTTP-статус, количество файлов и точные размеры. Добавьте результат сравнения с небольшим файлом, идентификатор запроса и сведения о недавних изменениях. Спросите, какой компонент отклоняет запрос и какое эффективное ограничение действует на этом маршруте.

Условный пример: «Форма прикрепления документа возвращает 413 при одном PDF размером 18 МиБ. Файл 1 МиБ проходит. В интерфейсе указан предел 20 МиБ. Проверяли сегодня в 12:10 UTC. Просим проверить лимит всего тела запроса и источник отказа». Замените цифры собственными наблюдениями.

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

Частые вопросы об ошибке 413

Поможет ли очистка cookies или кэша браузера?

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

Почему 413 появляется только при нескольких вложениях?

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

Почему увеличение upload_max_filesize не помогло?

Запрос мог быть отклонён раньше PHP, либо продолжает действовать другой предел: всего POST, приложения или CDN. Также проверьте, изменена ли конфигурация именно веб-приложения и применились ли настройки.

Можно ли просто отключить ограничение размера?

Для обычной формы полезнее задать обоснованный предел под её задачу. Безлимитный приём не устраняет ограничения обработки и хранения. Согласуйте допустимый объём на всех уровнях и сохраните понятный отказ для неподходящих запросов.

Что делать, если бизнесу нужны очень большие файлы?

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

Когда исправление можно считать завершённым?

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