Nginx Linux

Nginx: 413 Request Entity Too Large

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

Увеличьте client_max_body_size и перезагрузите конфигурацию.

В этой статье
  1. Что означает ошибка
  2. Причины и решения
  3. Пошаговое решение
  4. nginx
  5. PHP и приложение
  6. Прокси и CDN
  7. Как проверить результат

#Что означает ошибка

Сообщение
413

Ошибка 413 Request Entity Too Large в nginx возникает при загрузке файла, превышающего client_max_body_size (по умолчанию 1 МБ). Для PHP также действуют лимиты upload_max_filesize и post_max_size.

Нужно поднять лимиты на всех уровнях: nginx, PHP, приложение.

Если перед nginx стоит прокси/CDN, у него тоже есть ограничения.

Увеличьте client_max_body_size и перезагрузите конфигурацию.

#Причины и решения

Возможная причинаКак узнатьЧто делать
Малый лимит1 МБ.Проявляется как «413» или близкий по смыслу сбой.Увеличьте.
PHP лимитыupload.Проявляется как «413» или близкий по смыслу сбой.Увеличьте.
ПроксиДругой слой.Проявляется как «413» или близкий по смыслу сбой.Настройте.
КонфигНе применён.Проявляется как «413» или близкий по смыслу сбой.Reload.

#Пошаговое решение

  1. Поднимите client_max_body_sizeАдминистратор сервера откройте по SSH конфигурацию виртуального хоста Nginx и найдите лимит client_max_body_size через sudo nginx -T 2>&1 | grep -n client_max_body_size. Если для нужного сайта требуется, например, загрузка файлов до 20 МБ, установите client_max_body_size 20m; в соответствующий server или location, а не во всех сайтах. Уточните допустимый размер в правилах приложения и создайте резервную копию изменяемого файла.
  2. Поднимите лимиты PHPЕсли загрузка идёт через PHP, отдельно проверьте его фактические параметры upload_max_filesize и post_max_size именно у веб-PHP (phpinfo() только в закрытой временной странице либо панель хостинга). post_max_size должен быть больше предела файла с учётом других полей формы. Ошибка Nginx 413 возникает до передачи запроса PHP, поэтому менять только php.ini недостаточно.
  3. Проверьте конфигурациюСохраните конфигурацию Nginx и выполните sudo nginx -t: успешный вывод syntax is ok/test is successful допускает применение. Если есть ошибка с номером строки, верните предыдущий файл и исправьте синтаксис; не выполняйте перезапуск до успешной проверки.
  4. Перезагрузите службыПримените исправление sudo systemctl reload nginx после nginx -t, затем при необходимости отдельно согласуйте перезагрузку соответствующего пула PHP-FPM после изменения php.ini. Не перезапускайте произвольный php8.2-fpm, если сайт использует другую версию. Проверьте загрузку файла чуть меньше установленного порога и файла больше порога; второй должен корректно отклоняться.
  5. Проверьте лимиты проксиЕсли 413 остаётся, выясните, где завершается HTTPS: внешний CDN, балансировщик, Ingress Kubernetes или ещё один прокси может иметь меньший лимит. Сопоставьте заголовки ответа и журналы каждого уровня; меняйте только тот уровень, который реально отвергает запрос, сохраняя ограничения безопасности на загрузку слишком больших файлов.

#nginx

В /etc/nginx/nginx.conf (блок http) или в блоке server/location добавьте client_max_body_size 64m;. Проверьте синтаксис sudo nginx -t и примените sudo systemctl reload nginx. Для API с большими загрузками задайте значение только для нужного location.

#PHP и приложение

В php.ini: upload_max_filesize = 64M и post_max_size = 64M, max_execution_time = 120. Перезапустите php8.2-fpm. В WordPress проверьте «Медиафайлы» (максимальный размер). Для Laravel — post_max_size; для Node/Express — лимит body-parser (limit: '50mb').

#Прокси и CDN

Cloudflare на бесплатном тарифе ограничивает размер запроса 100 МБ. Балансировщики (AWS ALB, Traefik) имеют свои лимиты. В Kubernetes Ingress для nginx используйте аннотацию nginx.ingress.kubernetes.io/proxy-body-size: "64m". Для очень больших файлов используйте загрузку по частям (chunked upload).

Linux · Терминал (Bash)КомандаНужен sudo
Применение настроек nginx и PHP-FPM.
sudo nginx -t && sudo systemctl reload nginx
# PHP-FPM перезагружать лишь при отдельном изменении его настроек и после определения версии сайта.

#Как проверить результат

Проверьте лимит curl-запросом с тестовым файлом: dd if=/dev/zero of=test.bin bs=1M count=20 и curl -F "file=@test.bin" https://example.com/upload -o /dev/null -w "%{http_code}\n". Код 413 означает, что лимит ещё где-то мал, код 200 или 4xx приложения — что nginx пропустил файл. Помните, что ограничение может стоять в нескольких местах одновременно, поэтому проверяйте цепочку от внешнего прокси до приложения. После изменения не забудьте удалить тестовый файл.

Так эту ошибку тоже называют

502 502 Bad Gateway в Nginx: причины и быстрый способ найти виновника Ответ `502 Bad Gateway` означает, что Nginx, выступая шлюзом, не смог получить корректный ответ от backend-сервера — чаще всего PHP-FPM или приложения за `proxy_pass`. С… Сайты, серверы и хостинг Nginx NginxLinux Nginx: 502 Bad Gateway с PHP-FPM — причины и решение Проверьте, запущен ли php-fpm, путь к сокету и права. Сайты, серверы и хостинг Nginx Linux 504 Nginx 504 Gateway Time-out — причины и как исправить Ошибка `504 Gateway Time-out` значит, что Nginx отправил запрос приложению (PHP-FPM, Node.js, другому серверу), но не дождался ответа за отведённое время. Чаще всего при… Сайты, серверы и хостинг Nginx NginxLinuxPHP-FPM Nginx: ERR_TOO_MANY_REDIRECTS — цикл редиректов http/https и www — причины и решение Найдите петлю редиректов в конфиге и CMS, проверьте Cloudflare и proxy. Сайты, серверы и хостинг Nginx Linux 504 Nginx: 504 Gateway Time-out — upstream не отвечает вовремя — причины и решение Nginx выдаёт 504 Gateway Time-out, когда backend (PHP-FPM, Node.js, прокси) не успевает ответить за отведённое время. Увеличьте proxy_read_timeout или fastcgi_read_timeo… Сайты, серверы и хостинг Nginx Linux

Источники и обновления

Последнее обновление статьи: 1 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.