Nginx возвращает 413 Request Entity Too Large при загрузке файла в WordPress

Почему WordPress получает 413 Request Entity Too Large ещё до обработки файла

HTTP 413 от Nginx означает, что тело HTTP-запроса оказалось больше разрешённого лимита. В этот момент WordPress может вообще не получить запрос. То же относится к PHP-FPM: если Nginx остановил загрузку на входе, увеличение upload_max_filesize пока ничего не изменит.

В админке WordPress это выглядит одинаково для разных операций. Пользователь загружает ZIP-архив плагина, тему, видео, backup или файл импорта, браузер начинает отправлять POST-запрос, а вместо результата приходит 413. Та же проблема возможна в форме загрузки на фронтенде, REST API или плагине миграции. Меняется endpoint, но принцип остаётся тем же.

За ограничение размера request body в Nginx отвечает client_max_body_size. Если запрос превышает действующее значение, Nginx способен отвергнуть его раньше PHP.

Первое подтверждение можно получить в DevTools браузера: откройте Network, повторите загрузку и проверьте код ответа. Одновременно удобно смотреть журнал Nginx:

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

Путь к журналу может отличаться. Если причина именно в лимите Nginx, рядом со временем неудачной загрузки часто появляется сообщение с фразой:

client intended to send too large body

Лог есть — слой найден. Теперь имеет смысл искать действующий client_max_body_size. Если такого сообщения нет, это ещё не доказывает, что Nginx ни при чём: запрос мог попасть в другой virtual host, другой экземпляр Nginx или вообще остановиться на предыдущем proxy.

Как определить, какой сервер или прокси на самом деле возвращает ошибку 413

Изменение client_max_body_size не поможет, если HTTP 413 формирует другой компонент. На простом VPS цепочка короткая, но на реальном проекте запрос нередко проходит несколько уровней:

браузер
CDN или WAF
Nginx на VPS
reverse proxy
Nginx или Apache приложения
PHP-FPM
WordPress

Поэтому фраза «в Nginx уже стоит 512M» сама по себе ничего не доказывает. Нужно понимать, в каком именно Nginx стоит это значение.

Проверка по логам Nginx

Самый полезный тест — воспроизвести 413 и одновременно смотреть журналы того сервера, который вы подозреваете. Если в его error.log появляется client intended to send too large body, запрос дошёл до этого экземпляра Nginx и был отклонён здесь.

Если 413 есть в браузере, а журнал не меняется, проверьте access.log. Отсутствие запроса и там — сильный признак, что трафик не дошёл до этого узла. Причиной может быть внешний reverse proxy, Cloudflare или другой CDN, другой IP или другой virtual host.

Внешний Nginx и Nginx внутри Docker

Характерный случай: WordPress работает в контейнере, внутри него настроено client_max_body_size 512M, а входящий HTTPS принимает Nginx на хостовой системе с лимитом 64M.

Internet
    |
Nginx на хосте: 64M
    |
Nginx в контейнере: 512M
    |
PHP-FPM
    |
WordPress

Файл размером 100 МБ до контейнера не дойдёт. Внутренний error.log будет пуст, потому что внешний Nginx уже вернул 413. Менять конфигурацию контейнера в этом случае бессмысленно.

Обратная ситуация тоже возможна: внешний Nginx принимает большой запрос, передаёт его дальше, а 413 генерирует внутренний proxy. Тогда запрос будет виден на первом уровне, а сообщение о превышении request body появится на втором.

Когда 413 приходит ещё до VPS

Если в момент ошибки запрос отсутствует и в access.log, и в error.log входного Nginx на VPS, проверьте, что домен действительно ведёт на этот сервер, а перед ним нет CDN или WAF. Заголовки ответа в DevTools или вывод curl -v могут дать дополнительные признаки, но только по заголовкам не всегда можно точно определить источник.

curl -I здесь ограниченно полезен: HEAD-запрос не отправляет большое тело и не воспроизводит саму загрузку. Если у приложения есть известный тестовый endpoint для POST, проверять нужно реальным запросом с телом, а не только заголовками.

Сначала выясняем, кто режет запрос. Потом меняем лимиты.

Где Nginx задаёт client_max_body_size и какой конфиг реально работает

Администратор меняет /etc/nginx/nginx.conf, выполняет reload, а WordPress по-прежнему получает 413. Одна из частых причин — сайт обслуживается настройками из подключённого файла, а изменённая директива не действует на нужный server или перекрыта в location.

Где допустима директива client_max_body_size

client_max_body_size можно задавать в контекстах http, server и location. Если на более конкретном уровне собственного значения нет, используется унаследованное. Если есть — для запросов, попавших в этот контекст, действует именно оно.

http {
    client_max_body_size 64M;

    server {
        server_name example.com;
        client_max_body_size 256M;

        location /upload/ {
            client_max_body_size 32M;
        }
    }
}

В таком примере запрос к обычному URL сайта может иметь лимит 256 МБ, а запрос, который попал в /upload/, — только 32 МБ. Глобальные 64 МБ тоже никуда не исчезли: они останутся для тех серверов, где нет собственного значения.

Поэтому строка client_max_body_size 256M;, найденная в одном месте, ещё не означает, что именно 256 МБ разрешены проблемному запросу.

Почему редактирование nginx.conf иногда ничего не меняет

Главный nginx.conf часто только собирает конфигурацию через include. В зависимости от системы и панели настройки сайтов могут находиться в conf.d, sites-enabled, отдельных каталогах virtual host или автоматически созданных файлах.

Посмотреть объединённую конфигурацию, которую Nginx реально загружает, можно так:

nginx -T 2>&1

Быстрый поиск всех лимитов:

nginx -T 2>&1 | grep -n "client_max_body_size"

Поиск домена:

nginx -T 2>&1 | grep -n "server_name"

Если сервер большой, удобнее искать конкретное имя:

nginx -T 2>&1 | grep -n -B 5 -A 30 "server_name example.com"

В полном выводе nginx -T Nginx также показывает комментарии с путями подключённых конфигурационных файлов. Это помогает понять не только значение директивы, но и какой файл нужно редактировать.

Что делать, если nginx -T показывает несколько client_max_body_size

Не выбирайте самое большое значение. Сначала найдите server_name проблемного сайта, затем посмотрите его location и определите, куда попадает URL загрузки. После этого станет понятно, какое значение реально относится к запросу.

Если в http стоит 64M, в server — 256M, а в совпавшем location — 32M, повышение глобального лимита до 1G ничего не изменит. Запрос продолжит упираться в 32M.

Как правильно увеличить client_max_body_size для WordPress

Для одного WordPress-сайта лимит обычно удобнее задавать в его server-блоке. Это оставляет остальные сайты VPS с их текущими ограничениями и делает конфигурацию понятнее при следующей диагностике.

server {
    server_name example.com;

    client_max_body_size 128M;

    ...
}

128M здесь только пример. Лимит выбирают под реальные операции сайта, а не по принципу «чем больше, тем лучше».

server или location: куда ставить лимит

Если увеличенный размер нужен всему WordPress-сайту — например, для установки тем, плагинов, загрузки медиа и нескольких импортёров — логичнее использовать server. Если большой POST нужен только отдельному endpoint, можно ограничить изменение подходящим location.

При этом нельзя просто добавить произвольный location ради одной директивы, не понимая существующую маршрутизацию. В рабочем конфиге location может содержать try_files, proxy_pass, FastCGI-настройки и другие параметры. Ошибка при объединении блоков способна сломать обработку WordPress сильнее, чем исходный 413.

Если на VPS много сайтов, глобальная директива в http тоже работает, но область действия будет шире. Для проекта, где один сайт принимает большие архивы, а остальные этого не требуют, отдельный server обычно проще сопровождать.

Значение 0 отключает проверку размера тела запроса на этом уровне. Для обычного исправления WordPress-загрузки это редко необходимо. Если нужен файл порядка 100 МБ, нет технического смысла сразу снимать ограничение полностью.

После правки проверьте синтаксис:

nginx -t

При успешном тесте перечитайте конфигурацию:

systemctl reload nginx

И снова посмотрите нужный фрагмент через nginx -T. Важен не сам факт наличия нового числа, а то, что оно находится в правильном контексте.

Не надо лечить 50-мегабайтный архив лимитом в несколько гигабайт.

Что делать, если nginx -t или reload завершается ошибкой

Если nginx -t не проходит, новую конфигурацию применять нельзя. Здесь не нужно возвращаться к диагностике WordPress: сначала исправьте сам конфиг Nginx.

Запустите:

nginx -t

При ошибке Nginx обычно указывает файл и строку. Это намного полезнее общего сообщения «Nginx не запускается».

После добавления client_max_body_size появилась syntax error

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

client_max_body_size 128M;

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

Nginx сообщает duplicate directive

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

Для поиска:

nginx -T 2>&1 | grep -n "client_max_body_size"

nginx -t успешен, а reload не выполняется

Проверьте статус сервиса:

systemctl status nginx

И сообщения systemd:

journalctl -u nginx

Но не на каждом сервере Nginx управляется именно этим unit. В контейнере или кастомной сборке команда systemctl reload nginx может вообще не относиться к экземпляру, который обслуживает сайт.

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

Почему после исправления Nginx WordPress всё равно не загружает большой файл

Если 413 исчезла, а WordPress теперь сообщает о слишком большом файле или загрузка обрывается уже позже, запрос прошёл Nginx. Продолжать увеличивать client_max_body_size в этот момент бессмысленно.

upload_max_filesize

upload_max_filesize задаёт максимальный размер одного файла, который принимает PHP. Если Nginx разрешает 128 МБ, PHP — только 20 МБ, а файл весит 50 МБ, Nginx его пропустит, но PHP не обработает как допустимую загрузку.

post_max_size

post_max_size ограничивает размер всего POST-запроса. Поэтому для загрузки файла его нельзя бездумно делать меньше upload_max_filesize. Запрос содержит не только полезные байты самого файла, поэтому обычно оставляют некоторый запас.

Пример согласованных значений:

client_max_body_size 128M;

upload_max_filesize = 100M
post_max_size = 128M

Это пример соотношения, а не универсальная конфигурация.

memory_limit не является лимитом размера upload

memory_limit ограничивает память PHP-процесса. Нельзя автоматически считать, что для загрузки файла 500 МБ нужно установить memory_limit больше 500 МБ. Расход памяти зависит от дальнейшей обработки: WordPress может перемещать временный файл, распаковывать архив, импортировать данные или декодировать изображение.

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

Как убедиться, что вы проверяете PHP-FPM сайта, а не CLI PHP

Команда:

php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

показывает настройки CLI PHP. На VPS с несколькими версиями PHP WordPress может работать через другой PHP-FPM и использовать другой php.ini.

Быстрая проверка со стороны WordPress — раздел «Инструменты → Здоровье сайта → Информация → Сервер». Для более точной диагностики можно временно открыть phpinfo() через веб-SAPI и посмотреть:

• Server API;
• Loaded Configuration File;
• каталог дополнительных ini-файлов;
• upload_max_filesize;
• post_max_size;
• memory_limit.

После проверки файл с phpinfo() нужно удалить.

На сервере также можно посмотреть процессы PHP-FPM и конфигурацию pool, но пути зависят от дистрибутива и способа установки PHP. Поэтому сначала выясните, какая версия и какой FPM обслуживают именно этот virtual host, а уже потом редактируйте ini-файл.

Новый текст ошибки здесь полезнее старого. Если 413 пропала и появился PHP upload limit, Nginx уже пройден.

Что проверять, если client_max_body_size увеличен, а 413 всё равно остаётся

Если в конфигурации стоит client_max_body_size 256M, файл весит заметно меньше, nginx -t успешен, reload выполнен, а WordPress продолжает получать 413, не увеличивайте значение ещё раз. Проблема почти наверняка в области действия настройки или в другом узле цепочки.

В error.log есть client intended to send too large body

Это означает, что запрос режет именно тот Nginx, чей журнал вы смотрите. Дальше задача локальная:

1. найти нужный server_name;
2. найти все client_max_body_size;
3. проверить совпавший location;
4. убедиться, что изменён именно подключённый конфигурационный файл;
5. выполнить nginx -t и reload;
6. повторить тот же запрос.

Если сообщение продолжает показывать фактический размер тела, который превышает действующий лимит, значит нужная директива всё ещё не применяется к этому запросу.

В error.log ничего нет

HTTP 413 в браузере при пустом журнале входного Nginx — повод подняться на уровень выше. Проверьте внешний proxy, CDN, WAF, другой IP или другой экземпляр Nginx.

Если используется схема host Nginx → Docker, сравнивайте журналы обоих уровней в одно и то же время. Запись появилась на host и отсутствует в контейнере — запрос не дошёл до контейнера. Host молчит, а container пишет too large body — внешний слой запрос пропустил.

Конфиг меняется панелью управления

На сервере с панелью управления virtual host может генерироваться автоматически. Ручная строка в таком файле способна работать до следующего сохранения настроек сайта, после чего панель создаст конфиг заново и 413 вернётся.

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

nginx -T 2>&1 | grep -n "client_max_body_size"

Если директива исчезла или вернулась к старому значению, настройку нужно задавать через предусмотренный панелью механизм, пользовательский include или шаблон конфигурации. Конкретный способ зависит от панели. Если сайт размещён на хостинге для WordPress без root-доступа, лимит Nginx обычно меняют через доступные настройки панели или поддержку сервиса, а не прямой правкой системного конфига.

Если лог пустой — идём на proxy выше. Если лог есть — разбираем конфигурацию именно этого Nginx.

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

Главная ошибка при 413 — менять несколько уровней одновременно. Можно поставить 1G в Nginx, PHP и панели, получить рабочую загрузку и всё равно не понять, где находилось ограничение. При следующей регенерации конфига проблема возвращается.

Не путайте client_max_body_size с другими директивами request body

В Nginx есть параметры, связанные с буферизацией, временными файлами и чтением тела запроса. Наличие слова body в названии не означает, что директива задаёт максимальный разрешённый размер upload. Для ошибки 413, вызванной превышением размера request body, основная проверка — именно client_max_body_size.

Изменение текста ошибки — часть диагностики

После исправления Nginx WordPress может вместо 413 показать ограничение PHP. Позже может появиться timeout, ошибка распаковки архива или нехватка места. Если диагностика приводит к смене версии PHP и после этого WordPress показывает белый экран, это уже отдельный сценарий. Не возвращайтесь автоматически к исходной настройке 413.

Запрос прошёл дальше. Смотрите, где он остановился теперь.

Как быстро диагностировать 413 на WordPress VPS

Если есть SSH-доступ, проблему удобно пройти одним маршрутом. На простой конфигурации он занимает несколько минут, на схеме с proxy, контейнерами и CDN — больше, но порядок проверки остаётся тем же.

Успешное исправление Nginx подтверждается не только тем, что страница 413 исчезла. Запрос должен перестать создавать запись too large body на этом уровне и пройти дальше.

Когда лучше не увеличивать лимит, а изменить способ загрузки

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

Но одноразовый backup на несколько гигабайт — другой сценарий. Если ради него приходится поднимать Nginx, PHP, ограничения плагина, таймауты и параметры импорта, браузерная загрузка может быть просто неудачным способом передачи.

После устранения 413 очень большой файл может упереться уже не в размер HTTP-запроса. Тогда проверяют новую ошибку, свободное место, временные каталоги, PHP-FPM и ограничения самого импортёра. Например:

df -h
df -i

Эти команды не диагностируют 413. Они нужны только тогда, когда 413 уже устранена, а дальнейшая обработка большого файла всё равно срывается.

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