Ошибка 413 указывает на то, что сервер отклонил запрос. Причина – размер запроса (файл, API, форма с вложениями) оказался выше установленного лимита. Что делать, если вы столкнулись ошибкой 413? Всё зависит от того, есть ли у пользователя доступ к конфигурации сервера или нет. Дальше поговорим о самой ошибке, причинах появления и, конечно же, о способах устранения, зарекомендовавших себя на практике.
Что означает ошибка 413
Ошибка 413 Request Entity Too Large – HTTP-ответ, означающий о превышении лимита передаваемого серверу запроса. Тут важно понимать, что это не ошибка как таковая, а ответ, посылаемый сервером. На практике часто бывает так: пользователь пытается загрузить на свой Wordpress-сайт какой-то архив на 20-30 МБ, а на сервере установлен лимит в 10 МБ. Запрос будет заблокирован, а сервер вернет ошибку 413. Всё просто.
Обычно Request Entity Too Large возникает в следующих ситуациях:
попытка загрузки на сайт изображения, видео, архива большого размера;
отправка формы на сайте с большим по размеру вложением;
в панель управления загружается крупный файл;
отправка большого POST-запроса.
Крайне важно отличать ошибку 413 от других HTTP-ошибок. Для сравнения приведем ошибку 404 и 500. Первая указывает на то, что запрашиваемый ресурс не найден, а вторая – на внутреннюю ошибку сервера. Ошибка 413 не говорит пользователю о технической проблеме на стороне сайта. Фактически она отсутствует. Это ответ сервера на попытку загрузки файла или вложения размера, превышающего допустимый максимум. То есть на сайте установленный конкретный лимит, который нельзя преодолеть без изменений в настройках. И когда загружаемый объект упирается в лимит, сервер выдает ответ – Request Entity Too Large.
Из-за чего возникает ошибка 413
Иногда веб-мастер, столкнувшийся с такой проблемой, первым делом идет в PHP, чтобы там увеличить лимит (upload_max_filesize, post_max_size). Но после внесения изменений останется в недоумении – лимит повысил, но проблема не ушла. Почему так случается?
Причина простая – ограничение может быть установлено одновременно в нескольких местах:
Nginx. Работающий через Nginx сайт получает ограничение на максимальный размер тела запроса директивой client_max_body_size.
Apache. Тут также ограничение задается настройкой веб-сервера, в частности директивой LimitRequestBody.
PHP. На сайтах под управлением PHP, как уже было сказано выше, ограничения задаются upload_max_filesize (размер отдельно загружаемого файла) и post_max_size (ограничение на общий POST-запрос).
CMS, плагин. Если вы пользуетесь каким-то плагинами, то теоретически они могут задать ограничение на размер запроса. Что касается CMS, то в Wordpress позволяет задавать собственные дополнительные лимиты.
CDN. Подключили CDN? Тогда запрос может быть ограничен еще на PoP, не дойдя до основного сервера.
Так почему, если поменять лимит в Nginx, можно увидеть, что проблема не ушла? Вы увеличили лимит на стороне Nginx, а на стороне PHP или CDN он стоит прежний. Это и есть причина, почему сервер продолжает возвращать ошибку 413, даже если вы поменяли настройки в определенном месте.
Как исправить ошибку 413 на shared-хостинге или в панели управления?
В случае размещения сайта на shared-хостинге root-доступ обычно отсутствует. Если это ваш случай, то для начала проверьте настройки PHP в панели управления сервером.
Вам нужно найти следующие параметры:
upload_max_filesize = 150M
post_max_size = 170MЭту запись нужно искать в вашей панели управления сервером. Она в зависимости от самой панели имеет один и тот же вид, но путь к ней – разный. Ищите следующее:
Настройки PHP или MultiPHP INI Editor – в cPanel.
Настройки PHP для домена – в Plesk.
PHP Settings – в DirectAdmin.
Параметры PHP – в FastPanel.
Настройки веб-домена и PHP – в HestiaCP.
Установите значение, исходя из реального размера загружаемых файлов. Рекомендуется устанавливать post_max_size выше upload_max_filesize хотя бы потому, что POST-запрос, как правило, включает в себя не только один файл.
Если сервер на Apache, то часто в .htaccess можно обнаружить запись:
php_value upload_max_filesize 100M
php_value post_max_size 110MНо не во всех конфигурациях подобная запись исправно работает. Например, при использовании сервером PHP-FPM внести изменения не удастся. Или другой вариант – провайдер установил запрет на внесение изменений в PHP-параметры через редактирование .htaccess.
Что касается ограничений со стороны провайдеров, то на shared-хостинге не редкость случаи, когда поставщик услуг устанавливает собственный лимит на максимальный размер загружаемого файла. Вы можете видеть в панели управления лимит в 128 МБ, но на сервер хостинга ограничивает до 64 МБ. И тут чтобы вы не делали и не меняли – ничего не поможет.
Если вам нужен полный контроль над своим проектом – смотрите тарифы на VPS в линейке предложений Leneex. У нас нет таких ограничений.
Как исправить ошибку 413 на VPS (Nginx и Apache)
Права администрирования VPS позволяют самому менять установленные лимиты. Но что и где менять, зависит уже от ОС, конфигурации и настроек веб-сайта. Рассмотрим самые популярные случаи.
Nginx
В Nginx используется директива clien_max_body_size. Чтобы сервер начал пропускать запросы до 150 МБ, нужно прописать следующее:
server {
server_name ВАШ_САЙТ.com
client_max_body_size
150M;
# остальные настройки
}После внесения изменений проверьте конфигурацию:
nginx -tДальше перезапустите конфигурацию командой:
systemctl reload nginxНо если еще установлены ограничения на уровне PHP, нужно менять и там. Одного изменения конфигурации Nginx окажется недостаточно.
PHP
Здесь проверке подлежат upload_max_filesize и post_max_size. Нужно прописать параметры:
upload_max_filesize = 150M
post_max_size = 170MКак только внесли изменения, перезапустите PHP-FPM:
systemctl restart php8.3-fpmВ конце прописывайте вашу версию, так как это может быть php8.2-fpm.
Apache
На Apache лимит устанавливается директивой LimitRequestBody.
Выглядит это так:
<VirtualHost *:80>
ServerName ВАШ_САЙТ.com
LimitRequestBody
104857600
# остальные настройки
</VirtualHost>Лимит устанавливается в байтах, выше указаны 100 МБ в байтах. Если используется .htaccess, то возможность внесения изменений директивы определяются уже настройками самого сервера.
Как только изменения были внесены, перезапустите конфигурацию:
apachectl configtestПосле чего выполните:
systemctl reload apache2Важно помнить, что при наличии связки Nginx+Apache+PHP-FPM лимит нужно поднимать на каждом уровне. Если вы поднимите его только на Nginx, ничего не произойдет – изменения работать не будут. И вот тут особенно ощущаются преимущества виртуального хостинга без ограничений панели управления shared-хостинга. На VPS от Leneex вам доступны root-права, поэтому вы сможете вносить правки без ограничений со стороны хостера.
Как проверить, что лимит поднялся правильно
После внесения всех изменения последовательно проверяем работоспособность конфигурации:
Проверяем конфигурацию на наличие ошибок. Если их нет – здорово, двигаемся дальше по списку.
Перезапускаем нужный нам сервис.
Проверяем параметры PHP.
Дальше загружаем файл, который ранее не загружался из-за лимита тела.
При наличии проблемы проверяем логи Nginx, Apache, PHP. Без записей логов все предположения – гадание на кофейной гуще.
Также проверяем CDN, если он был ранее подключен.
Всегда проверяйте все уровни: чаще всего пользователь где-то забывает изменить лимит. Вот это и есть основная причина, почему сервер продолжает возвращать ошибку 413.
Заключение
Ошибка 413 Request Entity Too Large сама по себе не говорит о технических проблемах со стороны сервера. Это ответ сервера на попытку загрузить файл, размер которого превышает допустимый. shared-хостинг уступает виртуальному серверу тем, что там могут стоять ограничения со стороны провайдера или панели управления. И вы не сможете их изменить, даже если этого захотите.
Решение тут будет одно – миграция на VPS. При наличии root-прав вам не составит труда самому корректировать лимит, вносить изменения в Nginx, Apache, PHP. Если ваш сайт регулярно сталкивается с ошибкой 413, и вы при этом пользуетесь shared-хостингом, время переходить на VPS. Ознакомьтесь с тарифами виртуального сервера на нашем сайте. Вы получите root-права и сможете настраивать сервер под размеры файлов, API-запросов. Вам не придется согласовывать каждое изменение с поставщиком услуг.
