Как исправить ошибку 413 в Nginx при загрузке файла

Ошибка 413 Request Entity Too Large означает, что сервер отклонил слишком большое тело запроса. Она часто появляется при загрузке изображения, архива или резервной копии. Исправление начинается с поиска слоя, который вернул отказ: Nginx, внешний прокси или само приложение.

Здесь разберём проверенный случай Nginx. На Ubuntu 24.04.5 с Nginx 1.24.0 мы отправили запрос размером 2 МиБ, получили 413, подняли ограничение только для /upload до 3 МиБ и повторили запрос. Он прошёл, а запрос на 5 МиБ остался заблокирован.

Сначала подтвердить код и адрес запроса

Откройте инструменты разработчика браузера, вкладку «Сеть» / Network, и повторите загрузку. Посмотрите URL, HTTP-код, размер отправляемых данных и тело ответа. Не ориентируйтесь только на текст уведомления интерфейса: приложение может показать общее сообщение для разных причин.

Это настоящий ответ нашего отдельного стенда. Тестовая страница показывает HTTP-код и текст ответа; она передаёт в память приложения синтетическое тело без пользовательских файлов. Ограничение на первом этапе составляло 1m.

413 отличается от 502 Bad Gateway: при 502 Nginx не получил корректный ответ от upstream. Увеличение лимита тела не исправит недоступный процесс приложения.

Найти отказ в журнале Nginx

sudo tail -n 50 /var/log/nginx/error.log
sudo nginx -T 2>&1 | less

Если для сайта указан собственный error_log, смотрите его. Ищите сообщение client intended to send too large body, время опыта и нужный URI. На нашем стенде оно содержало размер тела 2097152 bytes — 2 × 1024 × 1024 байта.

Вывод nginx -T помогает найти активный server, location, подключаемые include и текущий client_max_body_size. Конфигурация может содержать внутренние адреса и секретные заголовки; не публикуйте её целиком в поддержку или комментарии. Подробности работы с журналами есть в отдельной инструкции.

Если сообщение отсутствует, убедитесь, что запрос дошёл до этого сервера. При CDN или другом reverse proxy внешний узел может вернуть 413 раньше. По одному заголовку Server нельзя надёжно определить всю цепочку обработки.

Изменить лимит в нужном location

Директива client_max_body_size задаёт максимальный размер тела запроса. Она допустима в http, server и location. В нашем примере общий предел — 1m, а для единственного маршрута загрузки — 3m.

Ниже полная конфигурация именно тестового виртуального хоста. Он слушает только loopback на 18130, приложение уже запущено на 8003. Это пример расположения директивы, а не замена конфигурации вашего домена:

server {
    listen 127.0.0.1:18130;
    server_name _;
    client_max_body_size 1m;
    error_log /var/log/nginx/hostfera-413.error.log;
    location / {
        proxy_pass http://127.0.0.1:8003;
        proxy_set_header Host $host;
    }
    location = /upload {
        client_max_body_size 3m;
        proxy_pass http://127.0.0.1:8003;
        proxy_set_header Host $host;
    }
}

На рабочем сайте найдите существующий обработчик загрузки и добавьте ограничение в него, сохранив его proxy_pass, FastCGI-настройки, авторизацию и заголовки. Не создавайте конкурирующий location вслепую. Точное сопоставление location = /upload действует для этого URI; /upload/ и /api/upload — другие адреса. В WordPress загрузка может идти через PHP-обработчик, поэтому копирование нашего proxy-блока туда не подходит.

Выбирайте лимит по требованиям проекта. Для загрузки файла размером 2 МиБ оставьте место для оболочки multipart/form-data и других полей. Если лимит приложения равен 2 МиБ на файл, лимит всего HTTP-тела обычно должен быть немного больше. 3m — число для нашего опыта, не универсальная настройка сайта.

Значение 0 отключает проверку размера на уровне Nginx. Для обычной загрузки это лишает вас полезного ограничения; задайте конечный предел и учтите параллельные запросы, временное место на диске и предел самого приложения.

Проверить конфигурацию и применить

Перед редактированием сохраните копию конкретного файла. Замените example.conf на фактический файл сайта; резервную копию держите вне каталога автоматически подключаемых конфигураций.

sudo install -d -m 0700 /root/nginx-config-backups
sudo cp -a /etc/nginx/sites-available/example.conf \
  "/root/nginx-config-backups/example.conf.$(date +%Y%m%d-%H%M%S)"
sudoedit /etc/nginx/sites-available/example.conf
sudo nginx -t

Только если проверка успешна, выполните:

sudo systemctl reload nginx
sudo systemctl is-active nginx

При ошибке синтаксиса сначала исправьте указанный файл и строку. Перезапуск VPS не требуется. Если нужно отменить изменение, восстановите сохранённый файл, снова выполните nginx -t и только затем reload.

Повторить маленькую и слишком большую загрузку

После изменения Nginx наше приложение подтвердило получение всех 2097152 байт. Мы проверили также ограничения:

Запрос	Результат после изменения
2 МиБ на /upload	200, приложение получило 2097152 байта
5 МиБ на /upload	413
2 МиБ на другой маршрут	413, общий предел 1m сохранился

Для отдельного тестового обработчика можно создать синтетические файлы и отправить их через curl:

truncate -s 2M /tmp/hostfera-upload-2m.bin
truncate -s 5M /tmp/hostfera-upload-5m.bin
curl --show-error --include \
  -H 'Content-Type: application/octet-stream' \
  --data-binary @/tmp/hostfera-upload-2m.bin \
  http://127.0.0.1:18130/upload
curl --show-error --include \
  -H 'Content-Type: application/octet-stream' \
  --data-binary @/tmp/hostfera-upload-5m.bin \
  http://127.0.0.1:18130/upload

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

Если 413 осталась

Проверьте последовательно внешний прокси/CDN, правильность выбора виртуального хоста, более конкретный location и ограничение приложения. Для PHP это в том числе upload_max_filesize и post_max_size, для фреймворка — его лимит запроса или файла. Увеличение только client_body_buffer_size не меняет допустимый размер запроса: это другая настройка.

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