HTTP 413 Запрос слишком большой: основные причины, способы устранения и руководство по настройке сервера

Ошибка HTTP 413 Request Entity Too Large — это код статуса ответа на стороне сервера, который возникает, когда тело входящего запроса — чаще всего загружаемый файл — превышает максимальный размер полезной нагрузки, настроенный на уровне веб-сервера, обратного прокси или приложения. Сервер активно отклоняет запрос до его обработки, возвращая клиенту статус 413.

Эта ошибка не является проблемой на стороне клиента. Это намеренный механизм ограничения, встроенный в веб-серверы, такие как Nginx и Apache, конфигурации среды выполнения PHP и промежуточное программное обеспечение на уровне приложений. Точное понимание того, какой уровень применяет ограничение — и как задействовать правильную директиву конфигурации — это разница между быстрым решением и часами устранения неполадок.

Почему возникают ошибки HTTP 413: разбор по уровням

Запрос на загрузку файла проходит через несколько уровней обработки, прежде чем достигает вашего приложения. Любой из этих уровней может самостоятельно отклонить запрос с ответом 413. Для правильной диагностики ошибки необходимо определить, какой уровень несёт ответственность.

Уровень 1: Директивы веб-сервера

Nginx применяет ограничения размера загрузки через директиву client_max_body_size. Её значение по умолчанию составляет 1 МБ, что является крайне низким показателем для большинства современных приложений. Эта директива может быть задана в контексте блока http, server или location, при этом приоритет имеет наиболее специфичный блок.

Apache использует директиву LimitRequestBody, которая по умолчанию равна 0 (без ограничений) в большинстве дистрибутивов — однако хостинг-провайдеры регулярно переопределяют это значение в своих глобальных конфигурациях или конфигурациях виртуальных хостов, устанавливая ограничительное значение. Apache также обрабатывает файлы .htaccess, что означает возможность применения ограничения на уровне каталога без изменения основной конфигурации.

Уровень 2: Конфигурация среды выполнения PHP

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

• upload_max_filesize — максимальный размер одного загружаемого файла
• post_max_size — максимальный размер всего тела POST-запроса, который должен быть равен или больше upload_max_filesize

Распространённая ошибка конфигурации — установка upload_max_filesize = 50M при сохранении post_max_size на значении по умолчанию 8M. Ограничение тела POST-запроса проверяется первым, поэтому загрузка завершается неудачей до того, как проверяется ограничение размера файла.

Существует также третья директива, которую часто упускают из виду: max_input_time — она определяет, как долго PHP будет ожидать получения входных данных. При медленном соединении и загрузке больших файлов этот тайм-аут может вызвать сбой, который проявляется как ошибка 413 или пустой ответ.

Уровень 3: Обратные прокси и балансировщики нагрузки

Если ваша инфраструктура использует обратный прокси — HAProxy, Varnish, Cloudflare или экземпляр Nginx, действующий как прокси перед другим сервером — этот прокси-уровень имеет собственные ограничения размера тела запроса. Например, 413, возвращаемый Cloudflare, имеет жёсткое ограничение в 100 МБ для планов Free и Pro, и никакая конфигурация на стороне сервера не сможет его переопределить. Всегда проверяйте заголовки ответа вашего прокси-уровня, чтобы определить источник ошибки 413.

Уровень 4: Ограничения приложений и CMS

Системы управления контентом и фреймворки применяют собственные ограничения загрузки поверх уровней сервера и PHP. WordPress считывает эффективный лимит загрузки из значений среды выполнения PHP, но также применяет собственные ограничения медиабиблиотеки. Некоторые плагины WordPress добавляют дополнительные уровни проверки. Пользовательские PHP-приложения могут использовать логику проверки $_FILES, которая устанавливает более строгие ограничения, чем разрешает сервер.

Конфигурация Nginx: устранение ошибки 413 на уровне веб-сервера

Для Nginx исправление требует изменения client_max_body_size в правильном контексте конфигурации. Редактирование блока http применяет ограничение глобально; редактирование блока server или location применяет его только к этому виртуальному хосту или конечной точке.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

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

nginx -t && systemctl reload nginx

Критический граничный случай: Если Nginx действует как обратный прокси перед PHP-FPM или другим сервером приложений, необходимо также проверить директивы proxy_read_timeout и proxy_send_timeout. Большая загрузка, превышающая тайм-аут, будет прервана в середине передачи, что приведёт к ошибке 413 или 504 в зависимости от поведения прокси.

Конфигурация Apache: устранение ошибки 413 на уровне веб-сервера

Директива LimitRequestBody Apache принимает значение в байтах. Директива может быть размещена в httpd.conf, блоке VirtualHost, блоке Directory или файле .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

Значение 104857600 равно 100 МБ (100 × 1024 × 1024). После изменения httpd.conf или файла виртуального хоста перезапустите Apache:

apachectl configtest && systemctl restart apache2

Важный нюанс: В средах общего хостинга изменения .htaccess могут игнорироваться, если хостинг-провайдер установил AllowOverride None в своей конфигурации на уровне сервера. В этом случае только хостинг-провайдер может изменить ограничение. Это одна из основных технических причин рассмотреть переход на среду VPS-хостинга, где у вас есть полный root-доступ к конфигурации сервера.

Конфигурация PHP: устранение ошибки 413 на уровне среды выполнения

Файл php.ini является авторитетным источником ограничений загрузки PHP. Файл для редактирования зависит от вашей модели выполнения PHP (mod_php, PHP-FPM, CLI). Используйте phpinfo() или php --ini для определения того, какой php.ini фактически загружен.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

После редактирования php.ini перезапустите соответствующую службу:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Альтернативные методы при отсутствии доступа к php.ini:

Если вы используете план общего хостинга без прямого доступа к php.ini, вы можете попробовать переопределить настройки PHP с помощью:

1. Файла .user.ini в корне сайта (работает с PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Директивы .htaccess (работает только с mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Кода PHP во время выполнения (ограниченная эффективность, не рекомендуется для продакшена):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Обратите внимание, что ini_set() не может переопределить upload_max_filesize или post_max_size во время выполнения в PHP 7.x и более поздних версиях — эти директивы оцениваются до начала выполнения скрипта. Методы .user.ini или .htaccess значительно надёжнее.

Исправление ошибок 413 для WordPress

WordPress отображает эффективный лимит загрузки на экране Медиафайлы > Добавить новый. Если отображаемый лимит ниже того, что вы настроили в php.ini, проблема обычно заключается в том, что WordPress считывает данные из другого PHP-процесса или что уровень кэширования обслуживает устаревшие данные конфигурации.

Добавьте следующее в wp-config.php для явного определения размера загрузки:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Для установок WordPress Multisite размер загрузки на уровне сети контролируется отдельно в разделе Администрирование сети > Настройки > Настройки сети > Максимальный размер загружаемого файла. Этот параметр не зависит от ограничений PHP и должен быть настроен в дополнение к изменениям на уровне сервера.

Сравнение: где исправить ошибку 413 в зависимости от среды хостинга

Диагностика того, какой уровень возвращает ошибку 413

Перед применением каких-либо исправлений подтвердите источник ответа 413. Используйте curl с подробным выводом для проверки заголовков ответа:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Изучите заголовок ответа Server и любые заголовки X-Powered-By или CF-RAY. Заголовок CF-RAY указывает на то, что ошибка 413 возникла на уровне Cloudflare, а не вашего сервера. Ответ от nginx/1.x.x указывает на уровень Nginx. Отсутствие заголовка Server может указывать на балансировщик нагрузки или WAF выше вашего приложения.

Также проверьте журналы ошибок сервера сразу после возникновения ошибки 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Когда конфигурации сервера недостаточно: инфраструктурные соображения

Для приложений, которые регулярно обрабатывают большие передачи файлов — видеоплатформы, системы резервного копирования, медицинская визуализация, крупные каталоги товаров электронной коммерции — жёсткое кодирование высоких лимитов загрузки в конфигурацию общего сервера не является устойчивой архитектурой. Рассмотрите следующие альтернативы:

• Загрузка по частям: Разделите большие файлы на меньшие части на стороне клиента с помощью таких библиотек, как Resumable.js или Uppy. Каждая часть не превышает лимит сервера, а сервер собирает их заново. Это полностью обходит ошибку 413.
• Прямая загрузка в объектное хранилище: Сгенерируйте предварительно подписанный URL для S3-совместимого хранилища и позвольте клиенту загружать напрямую, полностью минуя ваш веб-сервер. Веб-сервер обрабатывает только транзакцию метаданных.
• Выделенные конечные точки загрузки: Настройте отдельный блок location в Nginx с более высоким значением client_max_body_size специально для маршрутов загрузки, сохраняя ограничительное значение по умолчанию для всех остальных конечных точек.

Для вычислительно интенсивных рабочих нагрузок, связанных с обработкой больших файлов — транскодирование видео, машинное обучение на загруженных данных — среда GPU-хостинга обеспечивает вычислительную мощность для обработки как загрузки, так и последующих вычислений без узких мест.

Если вашему приложению требуется управляемая среда панели управления с полным доступом к конфигурации PHP, VPS с cPanel предоставляет редактор MultiPHP INI в WHM, позволяющий переопределять директивы PHP для каждого домена без использования командной строки.

Соображения безопасности при повышении лимитов загрузки

Увеличение лимитов загрузки без соответствующего усиления безопасности создаёт реальную поверхность для атак. Сервер, принимающий POST-запросы размером 500 МБ, является потенциальной целью для атак типа «отказ в обслуживании», которые исчерпывают дисковый ввод-вывод, память или пулы соединений.

Реализуйте следующие меры контроля наряду с любым увеличением лимита:

• Ограничение частоты запросов на конечных точках загрузки: В Nginx используйте limit_req_zone для ограничения частоты загрузки на IP-адрес.
• Проверка типа файла: Никогда не полагайтесь на MIME-тип, предоставленный клиентом. Проверяйте сигнатуры файлов (магические байты) на стороне сервера.
• Права доступа к каталогу загрузки: Каталог, принимающий загрузки, не должен быть доступен через веб или исполняемым. Храните загрузки за пределами корня документов.
• Антивирусная проверка: Интегрируйте ClamAV или аналогичный сканер в конвейер загрузки для любой публично доступной конечной точки загрузки.
• Только аутентифицированные загрузки: Требуйте аутентификацию перед принятием больших полезных нагрузок. Неаутентифицированные конечные точки загрузки больших файлов легко злоупотребляются.

Для производственных сред, обрабатывающих конфиденциальные загружаемые данные, сочетание вашей хостинговой инфраструктуры с правильно настроенными SSL-сертификатами обеспечивает шифрование передачи файлов в пути, предотвращая перехват загружаемого контента.

Матрица технических решений: выбор правильного исправления

Практический чеклист для устранения ошибки HTTP 413

• Определите уровень, возвращающий ошибку 413, с помощью curl -v и журналов ошибок сервера перед внесением каких-либо изменений
• В Nginx установите client_max_body_size в наиболее специфичном применимом блоке (предпочтительно location перед server перед http)
• Убедитесь, что post_max_size всегда больше или равно upload_max_filesize в php.ini
• Увеличьте max_input_time и max_execution_time для больших файлов при медленных соединениях
• Убедитесь, что переопределения .htaccess разрешены (AllowOverride All или AllowOverride Options) перед тем, как на них полагаться
• Проверяйте все прокси-уровни независимо — CDN, балансировщик нагрузки и сервер приложений каждый применяют ограничения отдельно
• После любого изменения конфигурации перезагрузите (а не просто перезапустите) соответствующую службу и очистите любой кэш опкодов или страниц
• Для WordPress Multisite настройте лимит загрузки на уровне сети в дополнение к директивам PHP
• Реализуйте ограничение частоты запросов и проверку типа файла перед повышением лимитов на публично доступных конечных точках загрузки
• Если общий хостинг не позволяет получить доступ к конфигурации, перейдите на среду VPS-хостинга или выделенных серверов для полного контроля

Часто задаваемые вопросы

Каков лимит загрузки по умолчанию в Nginx, вызывающий ошибку 413?

По умолчанию Nginx устанавливает client_max_body_size равным 1 МБ. Любое тело запроса, превышающее 1 МБ, вернёт ошибку 413, если эта директива явно не увеличена в конфигурации Nginx.

Можно ли исправить ошибку 413 без root-доступа к серверу?

На общем хостинге вы можете попробовать исправления через .htaccess (только Apache, если AllowOverride разрешает) или файл .user.ini (только PHP-FPM). Однако если хостинг-провайдер установил ограничительные глобальные лимиты, эти методы будут неэффективны, и вам нужно будет обратиться в поддержку или перейти на план VPS.

Почему загрузка завершается неудачей даже после увеличения upload_max_filesize в php.ini?

Наиболее распространённая причина — post_max_size остаётся на более низком значении по умолчанию. PHP оценивает ограничение размера тела POST-запроса перед ограничением размера отдельного файла, поэтому загрузка отклоняется до того, как проверяется upload_max_filesize. Всегда увеличивайте обе директивы одновременно.

Вызывает ли Cloudflare ошибки 413?

Да. Cloudflare применяет собственные ограничения размера тела запроса: 100 МБ для планов Free и Pro, 200 МБ для Business и 500 МБ для Enterprise. Если ваш запрос превышает эти ограничения, Cloudflare возвращает ошибку 413 до того, как запрос достигает вашего исходного сервера. Никакие изменения конфигурации на стороне сервера не решат эту проблему — вам нужно либо перейти на более высокий план Cloudflare, использовать прямой обход загрузки (предварительно подписанные URL), либо реализовать загрузку по частям.

Как навсегда исправить ошибку 413 в WordPress на сервере с cPanel?

Используйте редактор MultiPHP INI в WHM для увеличения upload_max_filesize и post_max_size для конкретной версии PHP и домена. Затем убедитесь, что изменение отражено в WordPress в разделе Медиафайлы > Добавить новый. Для WordPress Multisite дополнительно обновите максимальный размер загрузки в разделе Администрирование сети > Настройки. Изменения .htaccess или wp-config.php не требуются при непосредственном использовании редактора INI в WHM.