Ошибка 413 Request Entity Too Large: причины блокировки загрузки файлов и способы увеличения лимитов в Nginx, PHP, Cloudflare и Docker

1. Анатомия ошибки 413: Request Entity Too Large против Payload Too Large

Сбой с кодом HTTP 413 возникает в момент, когда клиент (веб-браузер, мобильное приложение, скрипт интеграции или фоновый воркер) отправляет на сервер HTTP-запрос (обычно методом POST или PUT), размер тела которого (Content-Length) превышает установленный лимит на стороне принимающего узла.

В зависимости от используемой версии протокола HTTP и типа промежуточного прокси сервер возвращает один из двух стандартных статусов:

• 413 Request Entity Too Large (RFC 2616): классическая историческая формулировка из ранней спецификации HTTP/1.1, которая по-прежнему сохраняется по умолчанию в веб-серверах Nginx и Apache. Указывает, что тело (entity) запроса физически больше, чем готов принять сервер.
• 413 Payload Too Large (RFC 7231, RFC 7540 и RFC 9110): стандартизированная современная терминология для HTTP/1.1, HTTP/2 и HTTP/3, закрепленная в актуальных стандартах IETF и используемая в современных API-шлюзах, Node.js-сервисах и логах Envoy/Traefik.

В современной архитектуре веб-проектов запрос редко идет напрямую к бэкенду. Обычно он проходит цепочку из нескольких независимых уровней:

1. Периферийный CDN / WAF (Cloudflare, DDoS-Guard): проверяет размер запроса на входе в глобальную сеть.
2. Фронтальный веб-сервер / Reverse Proxy (Nginx, Caddy, Traefik, NPM): принимает внешний трафик и отсекает тяжелые запросы до их передачи в локальную сеть сервера.
3. Бэкенд-интерпретатор (PHP-FPM, uWSGI, Node.js, Go): считывает данные во временный каталог и накладывает лимиты языка программирования.
4. Прикладной уровень (CMS / Фреймворк): проверяет права пользователя и допустимый размер вложений в медиабиблиотеку.

Если лимит исчерпан хотя бы на одном из этих уровней, передача файла прерывается с ошибкой 413. Чтобы быстро локализовать, какой именно узел блокирует соединение, проверьте заголовки ответа и статус веб-сервера через онлайн-инструмент Анализ HTTP-заголовков онлайн и чекер инфраструктуры Проверка хостинга и CMS.

2. Уровень веб-сервера: тонкая настройка client_max_body_size в Nginx

Главный барьер в подавляющем большинстве стеков на базе Linux — директива client_max_body_size модуля ngx_http_core_module в Nginx.

По умолчанию значение этой директивы составляет всего 1 МБ (1m). Любая попытка загрузить качественную фотографию (3–5 МБ), PDF-каталог, плагин для CMS или архив бэкапа мгновенно натыкается на блокировку с записью в журнале ошибок /var/log/nginx/error.log:

# Типичная запись в error.log Nginx при превышении лимита
[error] 14822#14822: *4192 client intended to send too large body: 15728640 bytes, client: 198.51.100.45, server: example.com, request: "POST /wp-admin/async-upload.php HTTP/2.0"

Директива client_max_body_size может задаваться на трех уровнях иерархии конфигурации Nginx:

Пример грамотной конфигурации виртуального хоста Nginx для сайта с повышенными требованиями к объему загружаемых файлов (до 64 МБ):

server {
    listen 443 ssl http2;
    server_name example.com;

    # Увеличиваем лимит тела клиентского запроса до 64 МБ
    client_max_body_size 64M;

    # Буферизация тела запроса в оперативной памяти (16K для 64-bit систем)
    client_body_buffer_size 128k;

    # Временный каталог для сброса тела запроса на NVMe-диск, если файл больше буфера
    client_body_temp_path /var/cache/nginx/client_temp 1 2;

    # Таймаут на чтение тела запроса между двумя последовательными операциями чтения
    client_body_timeout 60s;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;
    }
}

После редактирования конфигурационного файла обязательно протестируйте синтаксис и примените настройки без прерывания соединений:

# Проверка корректности синтаксиса Nginx
sudo nginx -t

# Мягкая перезагрузка конфигурации
sudo systemctl reload nginx

Готовый оптимизированный шаблон виртуального хоста Nginx с кэшированием FastCGI и защитой админки доступен в нашем конфигураторе Конфигурация Nginx для WordPress с FastCGI-кэшем.

3. Уровень PHP и PHP-FPM: синхронизация цепочки взаимозависимых директив

После того как Nginx пропустил запрос в бэкенд, управление переходит к PHP-FPM. Если размер файла укладывается в client_max_body_size, но превосходит лимиты в php.ini, веб-сервер уже не вернет ошибку 413 — бэкенд молча отбросит тело запроса, и в массиве $_FILES окажется пустой список, либо PHP сгенерирует ошибку UPLOAD_ERR_INI_SIZE.

В конфигурации PHP существует строгое правило иерархии четырех параметров:

Найдите активный файл конфигурации PHP-FPM для вашей версии PHP (например, Ubuntu 24.04 с PHP 8.3):

# Проверяем, какой php.ini загружен в системе
php --ini | grep "Loaded Configuration"

# Открываем конфигурацию для пула PHP-FPM
sudo nano /etc/php/8.3/fpm/php.ini

Отредактируйте ключевые параметры загрузки и таймаутов:

; Максимальный размер одного загружаемого файла
upload_max_filesize = 64M

; Максимальный размер всего тела POST-запроса (включая все файлы и поля формы)
post_max_size = 64M

; Лимит оперативной памяти на выполнение одного скрипта
memory_limit = 256M

; Максимальное время (в секундах), отведенное на чтение входящих данных POST/GET
max_input_time = 300

; Максимальное время выполнения скрипта (обработка файла, создание превью, сжатие)
max_execution_time = 300

После внесения правок перезапустите службу PHP-FPM:

# Перезапуск службы PHP 8.3 FPM
sudo systemctl restart php8.3-fpm

Если вы используете изолированные пулы на один сайт, параметры можно жестко задать прямо в файле пула /etc/php/8.3/fpm/pool.d/www.conf:

; Переопределение настроек для конкретного пула
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[memory_limit] = 256M

Для детального расчета количества процессов воркеров и экономии RAM ознакомьтесь с нашей статьей PHP-FPM на VDS: расчет pm.max_children и тюнинг пулов без OOM Killer.

4. Уровень Reverse Proxy: Nginx Proxy Manager, Docker Compose и Caddy

Когда веб-приложение развернуто в контейнерах Docker за обратным прокси-сервером (Nginx Proxy Manager, Traefik или Caddy), стандартный лимит 413 часто срабатывает именно на внешнем прокси-шлюзе.

Рассмотрим типовые сценарии для популярных прокси-серверов:

1. Настройка в Nginx Proxy Manager (NPM)

По умолчанию контейнер NPM имеет дефолтный лимит Nginx в 1 МБ. Чтобы разрешить загрузку файлов большего объема:

1. Откройте панель управления Nginx Proxy Manager.
2. Перейдите в редактирование нужного Proxy Host.
3. Откройте вкладку Advanced.
4. В поле Custom Nginx Configuration добавьте следующие директивы:

# Увеличиваем лимит тела запроса до 100 МБ
client_max_body_size 100M;

# Отключаем буферизацию запроса на диск прокси для потоковой передачи в контейнер
proxy_request_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;

2. Настройка лимитов в современном веб-сервере Caddy 2

В веб-сервере Caddy ограничение входящего тела запроса настраивается через блок директивы request_body в файле Caddyfile:

example.com {
    # Задаем максимальный объем тела запроса
    request_body {
        max_size 100MB
    }

    reverse_proxy 127.0.0.1:8080 {
        # Сквозная передача заголовков
        header_up Host {upstream_hostport}
    }

    encode gzip zstd
    tls admin@example.com
}

Подробное руководство по современным возможностям Caddy читайте в статье Caddy 2 вместо Nginx: настройка веб-сервера с автоматическим SSL и Reverse Proxy для Docker.

5. Уровень Cloudflare: преодоление жесткого потолка в 100 МБ

Многие администраторы сталкиваются с ситуацией: в Nginx установлен client_max_body_size 500M, в PHP-FPM параметры upload_max_filesize и post_max_size увеличены до 500M, но при загрузке файла весом 105 МБ браузер мгновенно возвращает фирменную страницу ошибки:

Error 413: Request Entity Too Large
Cloudflare Ray ID: 894f2b10a8c43210 • Your IP: 198.51.100.24 • Performance & security by Cloudflare

Причина кроется в архитектурных лимитах самого сервиса Cloudflare:

Если ваш проект работает на бесплатном тарифе Cloudflare, существует три проверенных инженерных решения для передачи файлов более 100 МБ:

1. Выделенный прямой субдомен без проксирования («серое облако» в DNS):
   Создайте субдомен вида upload.example.com или direct.example.com, направьте A-запись на IP-адрес вашего VDS и отключите оранжевое облако проксирования (режим DNS only). Загрузку файлов перенаправляйте на этот субдомен напрямую в Nginx, минуя промежуточные узлы Cloudflare.
2. Потоковая загрузка частями (Chunked Upload / протокол TUS):
   Фронтенд-библиотека (например, Uppy, Dropzone или Resumable.js) нарезает большой файл (например, архив 2 ГБ) на небольшие чанки размером по 20–50 МБ. Каждый чанк отправляется отдельным запросом в рамках лимита Cloudflare, а бэкенд склеивает их в единый файл на NVMe-диске сервера.
3. Прямая загрузка в S3 через Pre-signed URLs:
   Веб-сервер генерирует временную подписанную ссылку на объектное хранилище (MinIO или S3), после чего браузер клиента заливает файл напрямую в бакет по протоколу HTTPS. Сам VDS и Cloudflare не расходуют трафик и процессорное время на обработку тяжелых байтов.

6. Сводная таблица диагностики: от симптома к решению

Используйте эту матрицу для быстрой локализации и устранения сбоя при загрузке файлов:

Для комплексной проверки сетевых портов и доступности вашего сервера воспользуйтесь онлайн-утилитой Сканер портов онлайн и мониторингом SSL-сертификатов в Проверка SSL-сертификата.