Найти в Дзене
UFO.Hosting

Ошибка 413: что это значит и почему появляется

HTTP 413 — распространенная ошибка, означающая слишком большой запрос, который не может принять сервер. Чаще всего она появляется при загрузке файлов. Важно понимать один нюанс: 413 обычно выдаёт не само приложение, а промежуточный слой — веб-сервер, обратный прокси, балансировщик, WAF или CDN. Поэтому исправление почти всегда сводится к тому, чтобы найти, где именно стоит лимит, и увеличить его. Сперва нужно разобраться, кто именно выдает 413. Для этого действуйте по шагам. 1. При каких действиях появляется ошибка — при загрузке файлов, отправки формы, импорте CSV или загрузке резервной копии? 2. Сколько весят файлы? 3. Ошибка появляется всегда или только после определённого порога? Есть два простых способа: В браузере: откройте DevTools → Network → нужный запрос → вкладка Headers. Иногда по заголовкам и оформлению страницы ошибки видно, кто отвечает. Через curl (удобно на сервере или локально): curl -I https://example.com/upload В ответе часто есть Server: или специфические заголовки
Оглавление

HTTP 413 — распространенная ошибка, означающая слишком большой запрос, который не может принять сервер. Чаще всего она появляется при загрузке файлов.

Важно понимать один нюанс: 413 обычно выдаёт не само приложение, а промежуточный слой — веб-сервер, обратный прокси, балансировщик, WAF или CDN. Поэтому исправление почти всегда сводится к тому, чтобы найти, где именно стоит лимит, и увеличить его.

Первые шаги для устранения проблемы

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

1) Воспроизведите проблему и зафиксируйте контекст

1. При каких действиях появляется ошибка — при загрузке файлов, отправки формы, импорте CSV или загрузке резервной копии?

2. Сколько весят файлы?

3. Ошибка появляется всегда или только после определённого порога?

2) Посмотрите, какой слой вернул ошибку

Есть два простых способа:

В браузере: откройте DevTools → Network → нужный запрос → вкладка Headers. Иногда по заголовкам и оформлению страницы ошибки видно, кто отвечает.

Через curl (удобно на сервере или локально):

curl -I https://example.com/upload

В ответе часто есть Server: или специфические заголовки прокси/CDN. Это не всегда 100% доказательство, но часто помогает.

3) Проверьте логи

413 почти всегда оставляет след в логах того слоя, который отклонил запрос.

  • Nginx: обычно /var/log/nginx/error.log
  • Apache: часто /var/log/apache2/error.log или /var/log/httpd/error_log
  • PHP-FPM: свой лог пула, плюс общий syslog/journal
  • Панели управления/прокси/CDN: могут иметь отдельные журналы

Если вы видите в логе Nginx что-то вроде “client intended to send too large body”, значит лимит именно там.

Самые частые причины 413

  1. Лимит на размер тела запроса в веб-сервере (Nginx/Apache).
  2. Лимит в прокси/балансировщике/CDN, который стоит перед сервером.
  3. Ограничения на уровне приложения или языка (например, PHP post_max_size и upload_max_filesize).
  4. Загрузка идёт не напрямую на сервер, а через API/эндпоинт, у которого свой лимит (импорт, медиа-эндпоинт, GraphQL и т. п.).

На практике очень часто встречается комбинация: вы подняли лимит в Nginx, но забыли про PHP — и после этого ошибка меняется.

Как исправить 413 в Nginx

В Nginx за размер запроса отвечает директива client_max_body_size. Если запрос больше — Nginx вернёт 413, даже не передавая его дальше.

Вариант 1: увеличить лимит для всего сайта

Обычно добавляют в блок http, server или location:

server {

# ...

client_max_body_size 50m;

}

Вариант 2: увеличить лимит только для конкретного пути (например, /upload)

location /upload {

client_max_body_size 50m;

}

После правок:

nginx -t

systemctl reload nginx

Лучше не ставить лимит с большим запасом или вообще без ограничений, если у вас публичные формы загрузки. Большие лимиты повышают риск злоупотреблений и лишней нагрузки.

Как исправить 413 в Apache

В Apache аналогичная история, только директива другая — LimitRequestBody.

Пример для виртуального хоста или каталога:

<VirtualHost *:80>

# ...

LimitRequestBody 52428800

</VirtualHost>

Значение указывается в байтах. 50 МБ — это 50 * 1024 * 1024 = 52 428 800.

Затем перезапуск/перезагрузка Apache:

apachectl configtest

systemctl reload apache2

Если у вас PHP: проверьте лимиты загрузки

Даже если веб-сервер теперь готов принять запрос, PHP может “отрубить” загрузку по своим настройкам. Это особенно актуально для WordPress, админок, импортов и любых форм.

В php.ini (или в конфигурации пула PHP-FPM / панели управления) проверьте:

  • upload_max_filesize — максимальный размер одного загружаемого файла
  • post_max_size — максимальный размер всего POST-запроса (должен быть не меньше, чем upload_max_filesize)
  • memory_limit — иногда нужен запас, если обработка файла идёт в памяти
  • max_execution_time и max_input_time — если файл большой и канал медленный, важны таймауты

Пример разумных значений:

upload_max_filesize = 50M

post_max_size = 60M

memory_limit = 256M

max_execution_time = 120

max_input_time = 120

После изменений перезапустите PHP-FPM:

systemctl restart php-fpm

# или php8.2-fpm / php8.3-fpm — зависит от версии

Если перед сервером стоит CDN, WAF или обратный прокси

Если вы используете внешние прокси-сервисы, CDN или защиту от атак, 413 может приходить от них, даже если на вашем сервере лимиты уже подняты. В этом случае:

  • проверьте, не ограничивает ли сервис размер загрузки по плану/настройкам;
  • убедитесь, что нужный путь (например, /upload) не попал под строгие правила WAF;
  • рассмотрите обходной вариант: загрузка напрямую на origin (если это безопасно) или загрузка в объектное хранилище.

Быстрый ориентир: какие значения ставить

Универсального числа нет. Оно сильно зависит от вашей задачи:

  • Для обычных сайтов с загрузкой изображений часто хватает 10–50 МБ.
  • Для импорта/бэкапов — лучше не через веб, но если нужно, то 100–200 МБ и внимательно с таймаутами.
  • Для публичных форм без авторизации лучше держать лимиты умеренными и дополнить защитой (rate limit, WAF-правила, капча).