413 Request Entity Too Large: причины и решения

2026-09-19

413 Payload Too Large, также называемая 413 Request Entity Too Large, означает, что тело запроса больше лимита, установленного где-то между клиентом и приложением. Сервер либо что-то перед ним отказался вообще обрабатывать тело, как только увидел или оценил, насколько оно велико.

Что означает 413 Payload Too Large

RFC 9110 определяет текущее название как 413 Content Too Large, хотя 413 Payload Too Large и более старая 413 Request Entity Too Large обе относятся к одному и тому же коду состояния и до сих пор встречаются в серверах, фреймворках и страницах ошибок. Какая бы ни была формулировка, смысл одинаков: сам запрос был синтаксически корректен, но его тело превысило лимит размера прежде, чем сервер согласился принять его для обработки. Чаще всего это происходит при загрузке файлов, но может случиться при любом запросе с крупным телом, включая массовую полезную нагрузку API.

Как проявляется ошибка

Браузеры обычно показывают ту простую страницу ошибки, которую вернул origin-сервер или edge; специального интерфейса браузера для этого, как для сбоя соединения, не существует. Часто это молча проваливается в форме, а ответ виден только на вкладке сети, особенно для загрузки файла, построенной на JavaScript. Из командной строки ответ подтверждает это прямо:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Логи доступа и ошибок сервера - самое надежное место для подтверждения точного вовлеченного размера и того, какой слой отклонил запрос, поскольку он может быть заблокирован на CDN, веб-сервере или в приложении, и каждый логирует это по-своему.

Что вызывает 413

client_max_body_size у nginx. Значение по умолчанию - 1 МБ, что достаточно мало, чтобы почти любая реальная загрузка файла спотыкалась об это, пока лимит явно не повысят:
```
client_max_body_size 20M;
```
LimitRequestBody у Apache. Задается на директорию либо глобально, и, как у nginx, по умолчанию имеет размер, который многие приложения превышают, хотя никто не менял его намеренно.
upload_max_filesize и post_max_size у PHP. Две отдельные настройки в php.ini, обе должны быть достаточно большими для загрузки; post_max_size должен быть не меньше upload_max_filesize, иначе второй параметр молча ограничивает первый.
maxAllowedContentLength у IIS. Задается в web.config в разделе requestLimits, по умолчанию около 30 МБ, и отдельна от собственного параметра ASP.NET maxRequestLength, который использует другие единицы измерения и должен повышаться вместе с ним.
Лимит загрузки Cloudflare по тарифному плану. Тарифы Free и Pro ограничивают размер тела запроса 100 МБ независимо от того, что иначе принял бы origin-сервер, и этот лимит нельзя поднять из собственной настройки origin; его нужно решать на стороне Cloudflare либо обходить прямым путем загрузки, минующим прокси.
Лимиты полезной нагрузки у API-шлюза. Управляемые API-шлюзы обычно ограничивают тела запросов значительно ниже того, что позволил бы традиционный веб-сервер, часто до низких единиц мегабайт, что ловит команды, переносящие существующую функцию загрузки за новый шлюз.

Как понять, кто виноват

Это почти никогда не вина посетителя в смысле того, что он сделал что-то неправильно; загружаемый им файл просто больше лимита, существующего где-то в цепочке, и исправление принадлежит тому, кто владеет этим слоем. Если один и тот же файл загружается нормально в одном окружении и проваливается в другом, сравните каждый слой на пути запроса, поскольку у nginx, PHP и CDN может быть свой лимит, и побеждает наименьший. Запуск HTTP-проверки с телом запроса, близким к вашему целевому лимиту, отправленным извне вашей сети, подтверждает, каков реальный предел сквозным образом, а не полагается на какой-то один файл конфигурации.

Как исправить ошибку 413

Если вы посетитель

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

Если вы администрируете сайт

Повышайте лимит на каждом слое вместе, а не только на одном. Один запрос обычно проходит через CDN, веб-сервер и среду выполнения приложения, и наименьший настроенный лимит где-либо в этой цепочке определяет реальный предел.
Задавайте nginx и Apache явно, а не полагайтесь на значения по умолчанию:
```
# nginx
client_max_body_size 20M;

# Apache
LimitRequestBody 20971520
```
Согласуйте две настройки PHP. Повысьте и upload_max_filesize, и post_max_size, и убедитесь, что второй параметр равен первому или больше него.
Обновляйте requestLimits в IIS и maxRequestLength в ASP.NET вместе в web.config, поскольку они измеряют одно и то же в разных единицах, и оба нуждаются в повышении.
Обходите лимит тарифа Cloudflare для действительно крупных файлов, загружая их напрямую в хранилище по подписанному URL, полностью минуя проксируемый путь запроса, вместо попытки поднять лимит, который данный тариф не открывает.
Проверьте собственный лимит полезной нагрузки API-шлюза отдельно от бэкенд-сервиса, если он стоит перед вашим приложением; он может отклонить запрос еще до того, как у ваших собственных, более щедрых настроек приложения появится шанс применяться.

Как предотвратить блокировку реальных пользователей ошибкой 413

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

Часто задаваемые вопросы

413 Payload Too Large - это то же самое, что 413 Request Entity Too Large?

Да. RFC 9110 переименовал текст статуса в 413 Content Too Large, но оба более старых названия относятся к идентичному коду состояния и значению, и все три формулировки до сих пор встречаются в реальной жизни в зависимости от версии серверного ПО.

Почему моя загрузка проваливается, даже если я повысил client_max_body_size в nginx?

Другой слой в цепочке, чаще всего post_max_size в PHP, фиксированный лимит тарифа CDN либо API-шлюз, вероятно, независимо применяет меньший лимит. Каждый слой между клиентом и приложением должен допускать этот размер, а не только тот, который вы изменили.

Могу ли я поднять лимит Cloudflare в 100 МБ на бесплатном или pro-тарифе?

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

Считается ли 413 блокировкой безопасности?

Обычно нет. Это, как правило, прямолинейный лимит ресурса, а не защитное правило, хотя некоторые WAF действительно используют необычно крупные тела как один из нескольких сигналов при решении, блокировать ли запрос.

Какой разумный лимит загрузки по умолчанию, если я его не устанавливал?

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