Ошибка 413 означает, что один из узлов обработки запроса отверг слишком большое тело. В WordPress это часто обнаруживается при загрузке изображения, ZIP с плагином или импорте. Увеличение лимита в PHP не помогает, если запрос раньше остановил Nginx, CDN или другой прокси. Цель диагностики — установить точный слой и согласовать ограничения, сохранив защиту от чрезмерных запросов.
Фото обложки: Dsimic; 19-inch rackmount Ethernet switches and patch panels.jpg, CC BY-SA 4.0. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Разведите размер файла и размер запроса
Форма загрузки отправляет не только содержимое файла, но и служебные поля с границами multipart. Поэтому лимит всего запроса нельзя рассчитывать впритык к размеру одного вложения. Несколько файлов в одном запросе тоже нужно учитывать суммарно. Сжатый архив и распакованные данные дополнительно различаются по потреблению диска: успешная передача ещё не означает возможность установки.
Проверьте исходный файл: фактический размер, расширение, допустимый тип и свободное место. Для воспроизводимого теста подготовьте два безопасных файла разрешённого формата: заведомо небольшой и близкий к нужному рабочему размеру. Не отправляйте многогигабайтные файлы ради поиска предела и не используйте рабочие персональные данные.
Какие ограничения участвуют
| Слой | Параметр или условие | Как отличить |
|---|---|---|
| Внешний прокси/CDN | Максимальное тело запроса у сервиса | Origin может вообще не получить запрос |
| Nginx | client_max_body_size в применимом контексте | В error log может быть причина отклонения |
| PHP | upload_max_filesize и post_max_size | Запрос дошёл до PHP, но файл или поля не приняты |
| WordPress | Фильтры, Multisite и ограничения приложения | Веб-сервер принял запрос, отказ оформлен приложением |
| Хранилище | Место, inode, временный каталог | Передача проходит, сохранение или распаковка — нет |
Шаг 1. Сохраните исходный ответ
В инструментах разработчика браузера откройте Network и повторите одну загрузку. Запишите URL, метод, код, время и размер отправляемого файла. Посмотрите тело ответа: страница Nginx, фирменная страница CDN и JSON WordPress дают разные зацепки. Заголовок Server сам по себе не является окончательным доказательством, поскольку его может менять прокси.
Не сохраняйте в общий отчёт Cookie, Authorization и содержимое форм. Для администратора достаточно обезличенного пути, точного времени и идентификатора запроса, если он есть. Сопоставьте наблюдение с access/error log того virtual host, который реально обслуживает домен.
Шаг 2. Найдите применимое правило Nginx
Официальная документация Nginx определяет client_max_body_size как ограничение тела запроса; превышение приводит к 413. Директива может задаваться на разных уровнях конфигурации. Поэтому искать одну строку во всём сервере недостаточно: нужно понять выбранные server и location и наследование настройки.
Владельцу управляемого VPS лучше передать провайдеру конкретный запрос и ожидаемый рабочий размер. На самостоятельном сервере сначала сохраните относящуюся к сайту конфигурацию и определите, управляет ли ею панель. Правка сгенерированного файла может исчезнуть при следующем сохранении домена; предпочтителен штатный механизм пользовательских включений.
# Учебный фрагмент внутри подходящего server/location: client_max_body_size 32m; # Проверка синтаксиса выполняется штатным nginx -t # Применение — только после проверки конфигурации и плана возврата.
32m — пример, а не универсальное значение. Сначала сформулируйте максимальный допустимый рабочий запрос. Не устанавливайте ноль ради устранения симптома: отключение ограничения расширяет ресурсный риск и не исправляет остальные слои.
Шаг 3. Сверьте PHP в веб-окружении
PHP CLI и PHP-FPM могут читать разные настройки. Вывод команды php -i из SSH не доказывает, какие лимиты действуют в запросе WordPress. Проверьте конфигурацию нужного пула и доступные сведения в штатной диагностике сайта, не публикуя общедоступный phpinfo.
upload_max_filesize относится к отдельному загружаемому файлу, post_max_size — к телу POST целиком. Пример с файлом 24 МБ требует запаса под multipart и другие поля. Не связывайте механически memory_limit с размером архива: обработка изображения или распаковка имеют собственные расходы. При импорте также проверьте поддерживаемый способ фоновой обработки.
Шаг 4. Проверьте приложение и временные данные
Когда 413 устранён, может проявиться другая ошибка: запрещённый MIME, отсутствие прав записи, заполненный временный каталог или квота Multisite. Это новый результат, а не доказательство, что первый шаг не помог. Разделите передачу, сохранение и обработку файла в протоколе.
Не исправляйте отказ сохранения через chmod 777. Определите пользователя PHP-FPM, владельца каталога и необходимые минимальные права. Если файл нужен однократно для большого переноса, рассмотрите штатный импорт из подготовленного каталога вместо постоянного увеличения лимитов публичной формы.
Приёмка и возврат
- Повторите загрузку небольшого файла и рабочего файла одного формата.
- Проверьте появление вложения в медиатеке и открытие самого файла.
- Для ZIP проверьте завершение распаковки и достаточный остаток места.
- Сверьте журналы и убедитесь, что изменён только нужный сайт.
- Запишите окончательные лимиты, причину выбора и исходное значение для возврата.
Если ошибка осталась на внешнем сервисе с неизменяемым пределом, дальнейшее повышение PHP бессмысленно. Нужен другой поддерживаемый маршрут загрузки или изменение процесса. Не обходите защиту публикацией незащищённого origin.
FAQ
413 всегда связан с WordPress?
Нет. Ответ может возникнуть до запуска PHP. Сначала определите узел, который его вернул.
Можно увеличить только upload_max_filesize?
Только если именно это ограничение мешает. Внешний прокси, Nginx и общий POST проверяются отдельно.
Почему один файл проходит, а другой такого же размера — нет?
Проверьте формат, число частей запроса, маршрут и дальнейшую обработку. Одинаковый размер не делает запросы идентичными.
Вывод
Правильное решение ограничивает запрос разумным рабочим размером на всех нужных слоях и проверяет полный путь до сохранённого результата. Повышение всех лимитов сервера без установления причины не является диагностикой.
Связанные материалы: 403 Forbidden на WordPress: права, WAF и доступ к нужному маршруту, Логи WordPress и PHP: как собрать данные для исправления ошибки, Заканчивается место на хостинге: диск, inode, архивы и безопасная очистка.
Техническое основание: официальная документация. Проверено 29.10.2026. Порядок приёмки и учебные примеры — редакционная разработка HOSTIO.
Если выбираете площадку с SSH, сначала проверьте состав услуги и ответственность администратора. Посмотреть услуги Beget — партнёрская ссылка HOSTIO; она не подтверждает пригодность любого тарифа для описанной настройки.
