Ошибка 413 Payload Too Large

HTTP 413 Payload Too Large означает, что сервер или промежуточный компонент отказывается обрабатывать запрос, потому что его содержимое превышает допустимый размер. В RFC 9110 этот статус называется 413 Content Too Large; формулировка Payload Too Large широко встречается в интерфейсах и документации более ранних реализаций.

Практически 413 чаще всего появляется при загрузке файлов, отправке крупного JSON, multipart/form-data или другом запросе с большим body. Диагностику нужно начинать не с безусловного увеличения лимита, а с ответа на два вопроса: какой фактический размер запроса и какой компонент первым его отклоняет.

Что означает HTTP 413

клиент
  ↓ request body
CDN / WAF
  ↓
reverse proxy
  ↓
приложение

на одном из уровней:
размер > допустимого лимита
  ↓
413

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

Где чаще всего возникает 413

CDN или WAF

Публичный запрос может быть отклонён на edge ещё до origin. В этом случае приложение вообще не увидит запрос.

Reverse proxy

Прокси нередко имеет собственный лимит request body. Для Nginx типичный пример — директива client_max_body_size.

Веб-сервер или ingress

Отдельный HTTP-сервер, ingress controller или API gateway может иметь лимит, отличный от лимита приложения.

Приложение

Framework или обработчик upload может ограничивать размер body, multipart form, JSON или конкретного поля.

Бизнес-правило

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

413, 400 и 415 — не одно и то же

Если JSON синтаксически корректен, но файл внутри слишком велик, 413 точнее, чем универсальный 400.

Шаг 1. Зафиксируйте точный запрос

Нужны method, URL, Content-Type, размер body, наличие Content-Length, способ передачи, время ошибки, response headers и request ID.

Размер файла можно проверить так:

wc -c upload.bin

Шаг 2. Воспроизведите запрос через curl

Multipart upload:

curl -i   -F 'file=@upload.bin'   https://example.com/upload

JSON из файла:

curl -i   -H 'Content-Type: application/json'   --data-binary @request.json   https://api.example.com/v1/import

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

Шаг 3. Найдите границу размера

На безопасном тестовом endpoint сравните запросы разных размеров:

1 МБ  → 200
5 МБ  → 200
10 МБ → 413

Так можно подтвердить, что проблема действительно зависит от объёма, а не от содержимого или авторизации.

Не генерируйте гигантские тестовые payload на production без необходимости: это создаёт лишнюю нагрузку.

Шаг 4. Определите компонент, вернувший 413

Путь запроса:

клиент
→ CDN/WAF
→ load balancer
→ Nginx/ingress
→ приложение

Полезные признаки:

• branded error page или специфичные headers edge-провайдера;
• запись 413 в access log reverse proxy;
• отсутствие запроса в application log;
• различие между public URL и прямым upstream.

Если приложение не видит request ID, ошибка сформирована раньше.

Шаг 5. Проверьте Nginx

Для Nginx размер тела может ограничиваться:

client_max_body_size 10m;

Не увеличивайте значение автоматически до огромного. Сначала определите реальную максимальную нагрузку и убедитесь, что downstream-компоненты способны безопасно принять такой body.

После изменения конфигурации:

nginx -t

и только затем применяйте изменение по принятой процедуре deployment/reload.

Шаг 6. Сверьте все лимиты по цепочке

Плохая конфигурация:

CDN             100 МБ
reverse proxy    20 МБ
application      50 МБ

Фактический публичный предел — 20 МБ.

Нужно знать минимальный лимит всей цепочки:

клиент → edge → proxy → app → storage

Повышение только application limit не исправит 413, который уже возвращает proxy.

Шаг 7. Проверьте, действительно ли нужен большой request

Иногда правильное решение — не увеличивать лимиты, а изменить протокол:

• multipart upload;
• resumable upload;
• загрузка напрямую в object storage по временной ссылке;
• разбиение большого импорта;
• асинхронная обработка после upload.

Сам факт 413 не означает, что сервер должен принимать любой размер.

413 и Content-Length

Если Content-Length известен заранее, компонент может отклонить запрос ещё до получения всего body. При streaming transfer решение может приниматься уже во время чтения.

Поэтому отсутствие полной загрузки на сервере не означает, что клиент «не успел отправить файл»: сервер мог намеренно остановить transfer из-за лимита.

413 после релиза

Проверьте изменения:

1. ingress/proxy config;
2. framework limits;
3. multipart parser;
4. CDN/WAF policy;
5. новый формат request;
6. выросший размер JSON;
7. перемещение endpoint за другой gateway.

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

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

Нужно проверить граничные сценарии:

размер ниже разрешённого → ожидаемый 2xx
размер выше лимита       → 413

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

Для реального upload дополнительно проверьте, что файл действительно сохранился и обработался корректно, а не только что status стал 200.

Автоматический контроль

Обычный небольшой GET не проверяет upload limit. Если endpoint критичен, можно регулярно выполнять безопасный запрос с реалистичным, но контролируемым body и заранее заданным ожидаемым ответом.

UpWatch можно использовать для регулярной проверки HTTP/API endpoint, если запрос не создаёт опасных побочных эффектов и критерий заранее определён.

Типичные ошибки

• увеличивать все лимиты сразу;
• считать 413 ошибкой только приложения;
• не измерять фактический размер body;
• проверять только frontend validation;
• отключать ограничения полностью;
• тестировать огромные payload на production;
• путать 413 с 408 или 504.

Практический чек-лист

1. Подтвердить именно HTTP 413.
2. Зафиксировать method, URL и Content-Type.
3. Измерить body.
4. Воспроизвести запрос через curl.
5. Определить компонент, вернувший 413.
6. Сверить лимиты CDN/WAF, proxy и приложения.
7. Найти минимальный лимит цепочки.
8. Решить, нужно ли увеличивать размер вообще.
9. Изменить только нужный уровень.
10. Проверить запрос ниже и выше границы.
11. Проверить реальную обработку файла/данных.
12. Сохранить защиту от чрезмерных запросов.

Источники и спецификации

• RFC 9110: 413 Content Too Large
• Nginx: client_max_body_size
• curl: официальная документация