Загрузка файла получает 413: находим лимит тела запроса в Nginx и приложении

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

Сравните запрос на входе и у backend

curl --max-time 30 -i -F 'file=@./sample.bin' https://app.example/upload

Используйте подготовленный безопасный файл и тестовый эндпоинт, где загрузка разрешена. Сохраните HTTP-статус, ответ и время. Заголовки и оформление страницы дают подсказку, но надёжнее сопоставить запрос с access/error log Nginx и журналом приложения.

Если Nginx сообщает о слишком большом клиентском теле, а backend не видел запроса, ограничение сработало на прокси. Если backend зарегистрировал запрос и сам вернул 413, менять только Nginx недостаточно. При наличии внешнего балансировщика проверьте и его журнал: он может остановить загрузку раньше обоих.

Настройте нужный location

location /upload {
    client_max_body_size 20m;
    proxy_pass http://127.0.0.1:9000;
}

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

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

Согласуйте лимиты по всей цепочке

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

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

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

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

Научитесь локализовать отказ по журналам и HTTP-поведению. Откройте программу Linux и Bash для DevOps-инженеров. Диагностика сети, HTTP и учебного сервиса помогает выбрать конкретный уровень исправления, прежде чем менять ограничения всей цепочки.

Ещё по теме

• curl завершился успешно после HTTP 500: сохраняем тело ошибки и код отказа
• mTLS в curl: где сертификат клиента, где ключ, а где доверие к серверу