Что значит ошибка 413 Request Entity Too Large?

Сервер отказался обрабатывать запрос, потому что тело запроса — файл или данные формы — больше, чем он готов принять. В стандарте HTTP (RFC 9110) код называется «413 Content Too Large», а nginx и Apache пишут старое название «Request Entity Too Large».

Это проблема моего компьютера или сайта?

Сайта: лимит на размер задаёт сервер. Посетитель может только уменьшить файл — сжать, разделить на части или отправить другим способом. Поднять лимит может только владелец сайта.

Это похоже на 414 URI Too Long?

Похоже по смыслу, но речь о разном. 414 — слишком длинный адрес страницы, 413 — слишком большое тело запроса. 414 обычно появляется из-за длинной ссылки, 413 — при загрузке файла или отправке большой формы.

Может ли 413 пропасть сама, если подождать?

Стандарт это допускает: если условие временное, сервер должен прислать заголовок Retry-After со временем, когда можно повторить. Но в nginx, Apache и PHP лимит размера — это настройка, она не меняется сама. Повтор того же файла даст ту же ошибку.

Есть ли ограничения у CMS?

Да. У сайтов на PHP, в том числе на WordPress, свой лимит на файл — upload_max_filesize, по умолчанию 2 МБ, и на весь запрос — post_max_size, по умолчанию 8 МБ. Сверх post_max_size PHP не отвечает 413, а отдаёт скрипту пустую форму.

Влияет ли 413 Content Too Large на SEO и индексацию?

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

Ошибка 413 Request Entity Too Large: как исправить

Ошибка 413 значит, что сервер отказался принимать запрос из-за его размера: файл или форма оказались больше лимита. Чаще всего она появляется при попытке загрузить фото, видео, архив или документ. Браузер обычно показывает белую страницу «413 Request Entity Too Large» с подписью веб-сервера. Мы подняли стенд с nginx, Apache и PHP, отправили файлы от 0,5 до 100 МБ и разберём, кто и где ставит лимит, как устранить ошибку — и почему иногда вместо 413 форма молча приходит пустой.

Отвечает ли сайт и с каким кодом, можно проверить нашим сервисом проверки доступности: он запрашивает страницу со своего сервера и показывает код ответа.

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

Код описан в стандарте HTTP, RFC 9110, раздел 15.5.14. Его название — «413 Content Too Large»: сервер «is refusing to process a request because the request content is larger than the server is willing or able to process» — отказывается обрабатывать запрос, потому что содержимое больше, чем он готов или может обработать. Раньше код назывался «Request Entity Too Large», и nginx с Apache до сих пор пишут это название.

Стандарт разрешает серверу закрыть соединение, не дочитав запрос. Если лимит временный, сервер должен прислать заголовок Retry-After. На практике лимит почти всегда постоянный: это строка в настройках.

Ошибка относится к классу 4xx — «запрос клиента не годится». Но исправить её посетитель может только одним способом: прислать меньше. Размер, который сервер готов принять, определяется его настройками, и заранее посетитель его не знает: сайт не обязан сообщать лимит.

Стенд: где срабатывает лимит

Мы подняли Apache 2.4 с PHP 8.3 без своих настроек и nginx 1.22 перед ним. Отправляли форму с текстовым полем и файлом из Chromium 149 и curl.

Что стоит на пути	1,5 МБ	3 МБ	10–30 МБ	100 МБ
PHP, настройки по умолчанию	принят	200, файл отброшен, поле дошло	200, пустая форма	200, пустая форма
nginx с лимитом по умолчанию	413	413	413	413
nginx с лимитом 50 МБ перед PHP	принят	200, файл отброшен	200, пустая форма	413
Apache с LimitRequestBody 1 МБ	413	413	413	413
PHP с лимитами 64 и 70 МБ	принят	принят	принят	200, пустая форма

Основные выводы.

nginx режет на 1 МБ. Директива client_max_body_size по умолчанию равна 1m. Файл в 1,5 МБ получил 413 и в обычной форме, и в запросе fetch. В журнале ошибок nginx — строка «client intended to send too large body» с размером в байтах.

nginx отвечает, не дожидаясь файла. Он смотрит на заголовок Content-Length, и 413 на файл в 100 МБ пришёл за полсекунды. Загружать весь файл ради отказа браузеру не пришлось.

PHP не отвечает 413 совсем. Файл больше upload_max_filesize (2 МБ) доходит до скрипта с ошибкой UPLOAD_ERR_INI_SIZE и размером 0, а остальные поля формы целы. Запрос больше post_max_size (8 МБ) хуже: PHP отдаёт скрипту пустые $_POST и $_FILES. Пропадает даже имя, введённое в форму. Сервер при этом отвечает 200, и в журнале доступа Apache всё выглядит нормально. Документация PHP описывает именно это: при превышении post_max_size «the $_POST and $_FILES superglobals are empty».

Поднять лимит в nginx мало. С лимитом 50 МБ nginx пропустил файл в 10 МБ дальше, PHP его выбросил, и форма пришла пустой. Это хуже 413: человек видит, что всё отправилось, а заявки нет.

Apache ставит свой лимит. С LimitRequestBody 1 МБ Apache вернул 413 на файл 1,5 МБ со своей страницей ошибки. По умолчанию лимит в Apache 1 ГБ; в версиях до 2.4.53 включительно его не было вовсе.

Наш замер: где 413 на nexforce.ru

17.10.2026 мы отправили POST с файлами 0,5, 1,5, 3 и 10 МБ на свой сайт nexforce.ru. Файл 0,5 МБ дошёл: сервер принял его целиком и ответил 404 за 3,1 секунды — адреса для загрузки на сайте нет. На 1,5 МБ и больше сервер ответил 413 за 0,4–0,5 секунды: лимит nginx по умолчанию, отказ до загрузки файла.

В Chromium по обычной сети форма с файлом 1,5 МБ получила 413 за 568 мс, с 30 МБ — за 2 секунды. Сброса соединения не было: браузер получал страницу 413 и показывал её.

Вывод: если на сайте есть форма с загрузкой, а лимит никто не менял, файлы больше 1 МБ до формы не дойдут.

Почему возникает ошибка

На стороне сайта:

Основные причины связаны с настройками сервера:

Лимит веб-сервера. nginx — client_max_body_size, по умолчанию 1 МБ; Apache — LimitRequestBody.
Лимит в цепочке прокси. Если перед сайтом стоит ещё один nginx, балансировщик или CDN, у каждого свой предел. Отказ даёт тот, у кого он меньше всех.
Лимит приложения. PHP, Node, фреймворки и CMS ограничивают размер запроса сами. PHP при этом часто не возвращает 413, а теряет данные.

На стороне посетителя:

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

Зачем сервер ограничивает размер

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

Поэтому допустимый размер необходимо выбирать под задачу. Форме заявки с резюме хватит 10–20 МБ, загрузке видео нужно больше — и такую загрузку лучше вынести на отдельный адрес со своим лимитом, а не поднимать предел для всего сайта.

Как исправить ошибку посетителю

Уменьшить файл

Сожмите фото или PDF, уменьшите разрешение скана, отправьте видео ссылкой. Ориентир — меньше 1 МБ: столько пропускает nginx без настройки.

Например, изображение с камеры телефона часто весит несколько мегабайт. Если сайт просит фото документа, его можно сохранить в меньшем разрешении или в формате JPG с более сильным сжатием: для чтения текста этого обычно достаточно. Скан многостраничного документа лучше сохранить в PDF с оптимизацией размера, а не набором снимков.

Отправить файлы по одному

Если форма принимает несколько файлов, отправьте их отдельными запросами. Лимит считается на весь запрос.

Написать владельцу сайта

Если файл уменьшить нельзя или вы не можете разделить его, попробуйте отправить его другим способом: напишите на почту сайта и приложите файл к письму или ссылку на любой облачный диск. Обратитесь к владельцу и сообщите, что форма отвечает 413: он может не знать, что загрузка не работает. Сайт отклонил файл, а не вас — повтор той же отправки не поможет.

Как исправить владельцу сайта

Узнать текущий лимит

Прежде чем вносить изменения, убедитесь, какой лимит установлен сейчас и кем:

nginx: команда nginx -T выводит всю действующую конфигурацию, в ней ищите client_max_body_size. Нет директивы — действует 1 МБ;
PHP: php -i в консоли или функция phpinfo() на странице сайта покажет upload_max_filesize и post_max_size. Учтите, что у консольного PHP и PHP сайта настройки могут отличаться;
WordPress: в разделе «Медиафайлы» → «Добавить новый» под полем загрузки написан максимальный размер файла, а в «Инструменты» → «Здоровье сайта» → «Информация» есть раздел про работу с медиафайлами с лимитами PHP.

Затем посмотрите на страницу ошибки: подпись «nginx» или «Apache» внизу подскажет, какой сервер ответил. Если подписи нет, а форма просто приходит пустой — причиной скорее всего лимит PHP.

nginx

Директива client_max_body_size задаётся в блоках http, server или location. Документация nginx: «Sets the maximum allowed size of the client request body. If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned». Значение 0 отключает проверку — делать так не стоит.

location /upload/ {
    client_max_body_size 20m;
}

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

Apache

LimitRequestBody задаётся в байтах. Добавьте директиву в конфигурацию сервера, виртуального хоста, каталога или в файле .htaccess — в соответствии с тем, где лежит форма загрузки:

LimitRequestBody 20971520

PHP и WordPress

Два параметра, оба нужно поднять:

upload_max_filesize — предел на один файл, по умолчанию 2 МБ;
post_max_size — предел на весь запрос, по умолчанию 8 МБ. Документация PHP требует, чтобы он был больше upload_max_filesize, а memory_limit — больше post_max_size.

Где их изменить, зависит от того, как запущен PHP. На стенде с mod_php сработали строки в .htaccess, вот пример:

php_value upload_max_filesize 64M
php_value post_max_size 70M

После этого файлы в 3 и 30 МБ дошли целиком. Если PHP работает через PHP-FPM, .htaccess не действует: параметры задают в php.ini или в настройках пула FPM, а затем перезапускают службу.

Хостинг, интернет-магазины и платформы

На виртуальном хостинге доступа к конфигурации nginx обычно нет. Лимиты PHP в таком случае меняют в панели управления хостингом, в разделе настроек PHP, а лимит веб-сервера — через поддержку хостинга. На платформах для сайтов и интернет-магазина, где сервер чужой, лимиты указаны в документации платформы, и поменять их сами вы обычно не сможете. Если администрирование сервера ведёт подрядчик, пришлите ему размер файла, адрес формы и время ошибки: по журналу он найдёт, какой лимит сработал.

Ловить пустую форму и предотвратить потерю заявок

Раз PHP молчит про превышение post_max_size, в некоторых ситуациях заявка пропадёт без следа. Чтобы этого не было, добавьте проверку в обработчик: если заголовок Content-Length больше нуля, а $_POST и $_FILES пустые, значит, запрос не влез. Покажите человеку понятное сообщение вместо «спасибо, заявка принята». В журнале ошибок PHP в этот момент пишет предупреждение «POST Content-Length of … bytes exceeds the limit of … bytes».

Почему 413 не исчезает

Правили не тот файл. У nginx может быть несколько конфигураций, и действует та, что ближе к адресу: location перекрывает server.
Не перезагрузили сервер. Правка в nginx, php.ini или настройках FPM начинает действовать после перезагрузки.
Лимит есть выше по цепочке. Внешний прокси или балансировщик отказывает раньше вашего сервера. Смотрите подпись на странице 413: в ней видно, чей это ответ.
post_max_size меньше upload_max_filesize. Тогда большой файл проходит одну проверку и проваливает другую — форма приходит пустой.

Безопасность и разумный объём

Не ставьте client_max_body_size 0 и не поднимайте лимиты до гигабайт «на всякий случай». Отдельный адрес для загрузки с понятным пределом позволяет принимать большие файлы и не открывает остальной сайт для запросов любого объёма. Это вопрос безопасности и ресурсов сервера, а не только удобства.

Как проверить, что ошибка исправлена

Выполните отправку файла нужного размера через curl — в любой системе, где он установлен:

curl -s -o /dev/null -w '%{http_code}\n' -F f=@test.bin https://example.ru/upload/

Код 413 — лимит ещё стоит. Код 200 — проверьте, что обработчик получил файл, а не пустую форму: загляните в заявку или в журнал ошибок PHP. Затем повторите отправку из браузера через саму форму и посмотрите логи сервера: при реальном размере файла ошибок в них быть не должно. Такая проверка поможет избежать ситуации, когда curl файл доставил, а форма на сайте всё ещё теряет его из-за собственных ограничений в коде.

Границы замера

Стенд — один Apache с mod_php, без PHP-FPM, CDN и балансировщиков. Лимиты облачных прокси и хостингов мы не проверяли: у каждого свои цифры, их нужно смотреть в документации провайдера. Сброса соединения вместо 413 мы не получили ни на стенде, ни на своём сайте, но при медленной сети и других серверах он возможен: стандарт разрешает закрыть соединение.

Коротко

Ошибка 413 — сервер не принял запрос из-за размера. Посетителю остаётся уменьшить файл. Владельцу — поднять client_max_body_size в nginx, LimitRequestBody в Apache и оба лимита PHP и проверить, что форма после этого не приходит пустой: превышение post_max_size PHP не показывает как ошибку.

Ошибка 413: файл слишком большой для сервера