Задача о габаритном файле и ошибке
Будет полезна бэкенд-разработчикам, которые работают с микросервисной архитектурой и регулярно сталкиваются с неожиданным поведением инфраструктуры.
Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.
Условие
В компании «Доки.Онлайн» выкатили обновление: теперь пользователи могут загружать PDF-файлы с отсканированными договорами. Все работало отлично в локальной среде — разработчик протестировал загрузку больших файлов, убедился, что API обрабатывает их корректно, и спокойно отправил изменения в продакшн.
Но радость была недолгой. На боевом сервере при попытке загрузить файл система выдавала ошибку 413 Request Entity Too Large. Причем происходило это до того, как пользователь получал какой-либо отклик от самого приложения.
Разработчик Геннадий Завров начал искать причину. Он проверил логи всех четырех компонентов системы:
- фронтенда;
- API Gateway (определяет, в какой микросервис послать запрос);
- микросервиса загрузки файлов;
- микросервиса обработки документов.
Во всех логах пусто, будто никакого запроса и не было. Ни один сервис даже не попытался начать обработку файла.
Геннадий начал подозревать сетевые сбои, перегрузку API Gateway и баг в коде фронтенда. Однако простые тесты с маленькими файлами работали стабильно. Проблема проявлялась только при загрузке чего-то «потяжелее».
В какой-то момент он задал себе вопрос: а точно ли запрос доходит до приложений?
Задача
Почему при загрузке большого файла система возвращает ошибку 413, если сами сервисы даже не видят входящий запрос? Кто может остановить запрос еще до бэкенда?
Решение
Ошибка 413 Request Entity Too Large — это сигнал не от приложения, не от API Gateway и не от микросервиса. Это сообщение приходит от веб-сервера, который первым встречает HTTP-запрос от клиента.
В современной инфраструктуре почти всегда перед микросервисами стоит обратный прокси: это может быть nginx, Caddy, Traefik, HAProxy или другой подобный сервер. Его задачи — принимать входящие соединения, шифровать/дешифровать трафик, маршрутизировать запросы, балансировать нагрузку, а иногда — просто быть удобной точкой входа.
Но, кроме всего прочего, такой сервер выполняет и роль фильтра. Он может ограничивать допустимый объем тела запроса, отсеивать подозрительные заголовки, закрывать доступ по IP и выполнять массу других защитных проверок до того, как запрос попадет внутрь системы.
Вот и здесь веб-сервер посчитал, что тело запроса слишком большое, и не стал даже проксировать его дальше — ни в API Gateway, ни в микросервисы. Именно поэтому в логах приложений ничего не появилось. С точки зрения бэкенда пользователь вообще ничего не отправлял.
Это поведение может сбивать с толку, особенно если разработчик привык искать ошибки только в коде и логике приложения. Но в реальности, в боевых окружениях, веб-сервер играет критическую роль в обработке трафика. Он может не просто направить запрос, но и отклонить его задолго до того, как он коснётся вашего кода.
Вывод: если вы получаете ошибку 413, но бэкенд ничего не видит, присмотритесь к веб-серверу. Он стоит первым на пути запроса и может быть куда строже, чем ваши микросервисы.
