Ошибка 413 Request Entity Too Large: что означает и как исправить

HTTP-статус 413 Request Entity Too Large (в новой редакции RFC 7231 — 413 Content Too Large) означает, что сервер отклонил запрос, потому что тело запроса превышает установленный лимит. Простыми словами: загружаемый файл или отправляемые данные оказались больше, чем разрешено конфигурацией сервера.

Браузер видит эту ошибку в нескольких сценариях: загрузка изображений или видео в CMS, отправка формы с вложением, импорт базы данных через phpMyAdmin, установка плагинов через веб-интерфейс WordPress.

Ошибка всегда возникает на стороне сервера — клиент здесь ни при чём. Источником ограничения может быть веб-сервер (Nginx или Apache) или PHP. Важно понять, что именно блокирует запрос, — иначе изменение одного параметра ничего не даст, если ограничение стоит в другом месте.

Как определить источник ограничения

Перед тем как менять конфиги — проверить логи. Они скажут, кто именно отклонил запрос.

Nginx:

tail -n 50 /var/log/nginx/error.log

Строка вида client intended to send too large body — ошибка на уровне Nginx.

Apache:

tail -n 50 /var/log/apache2/error.log

PHP:

grep -i "upload\|post" /var/log/php*.log

Если в логах ничего нет — ошибку может возвращать балансировщик или прокси перед сервером (HAProxy, Cloudflare, AWS ALB).

Исправление в Nginx

По умолчанию Nginx ограничивает тело запроса значением 1 МБ — директива client_max_body_size. При превышении сервер сразу возвращает 413 без передачи данных PHP.

Открыть конфигурацию:

nano /etc/nginx/nginx.conf

Или конфиг конкретного виртуального хоста:

nano /etc/nginx/sites-available/example.com

Найти или добавить директиву в нужный блок:

Глобально — блок http {}:

http {
    client_max_body_size 64m;
}

Для конкретного домена — блок server {}:

server {
    server_name example.com;
    client_max_body_size 64m;
}

Для конкретного location (например, только для загрузок):

location /upload {
    client_max_body_size 256m;
}

Значение 0 полностью снимает ограничение — не рекомендуется на публичных серверах.

После изменения — проверить синтаксис и перезагрузить:

nginx -t && systemctl reload nginx

Исправление в Apache

В Apache лимит задаётся директивой LimitRequestBody. По умолчанию она не ограничивает размер запроса (значение 0), но может быть явно прописана в конфиге или в .htaccess.

В конфигурационном файле (/etc/apache2/apache2.conf или в VirtualHost):

<VirtualHost *:80>
    ServerName example.com
    LimitRequestBody 67108864
</VirtualHost>

Значение задаётся в байтах. 67108864 = 64 МБ.

В .htaccess (если AllowOverride это разрешает):

LimitRequestBody 67108864

Перезагрузить Apache:

systemctl reload apache2

Если Apache работает за Nginx-прокси — лимит нужно поднять в обоих конфигах. Nginx проверяет размер первым.

Исправление в PHP

Даже если веб-сервер пропустил запрос, PHP имеет собственные ограничения на размер загружаемых файлов и POST-данных. Они задаются в php.ini.

Найти актуальный файл:

php --ini | grep "Loaded Configuration"

Открыть и найти три директивы:

nano /etc/php/8.2/fpm/php.ini

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

; Максимальный размер всех POST-данных (должен быть >= upload_max_filesize)
post_max_size = 128M

; Максимальное время выполнения скрипта в секундах
max_execution_time = 300

post_max_size должен быть больше или равен upload_max_filesize — иначе PHP отклонит загрузку раньше, чем проверит размер файла.

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

systemctl restart php8.2-fpm

Или Apache с mod_php:

systemctl restart apache2

Проверить, применились ли настройки — создать файл info.php:

<?php phpinfo();

Открыть в браузере и найти значения upload_max_filesize и post_max_size в выводе.

Исправление через .htaccess (PHP с mod_php)

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

php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value max_execution_time 300

Работает только при использовании Apache с mod_php. На PHP-FPM эти директивы через .htaccess не действуют.

WordPress: дополнительный нюанс

WordPress проверяет лимит загрузки самостоятельно и выводит его в Медиафайлы → Добавить новый. Если там написано «Максимальный размер файла: 2 МБ» — WordPress берёт наименьшее из трёх значений: upload_max_filesize, post_max_size и memory_limit.

Добавить в wp-config.php:

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '128M');
@ini_set('memory_limit', '256M');

Или в .htaccess перед # BEGIN WordPress:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Типичные ошибки при устранении

Изменили php.ini, но ошибка осталась — скорее всего, лимит стоит и в Nginx/Apache. Нужно поднять в обоих местах.

Изменили Nginx, но лимит не применился — забыли сделать nginx -t && systemctl reload nginx. Или директива прописана в неправильном блоке (например, в location, а запрос идёт по другому пути).

На сервере несколько php.ini — для CLI, для FPM, для Apache разные файлы. Изменение в CLI-версии не влияет на веб-запросы.

Ошибка 413 возвращает Cloudflare — у Cloudflare Free и Pro есть лимит 100 МБ на загрузку файлов через проксируемые домены. Это ограничение Cloudflare, не сервера — поднять его можно только на Enterprise-плане или отключив проксирование для конкретного домена.

Шпаргалка

Итог

Ошибка 413 решается поднятием лимита в том компоненте, который его установил: Nginx, Apache или PHP. Если сервер стоит за Cloudflare — дополнительно проверить ограничения на их стороне. После изменений всегда перезагружать соответствующий сервис и проверять через phpinfo() или повторную загрузку файла.