Ошибка 413 Content Too Large: что делать владельцу сайта

Ошибка 413 Content Too Large означает, что один из серверов на пути запроса отказался принимать его тело из-за размера. Чаще всего пользователь видит её при загрузке файла, отправке большой формы, импорте данных или обращении к API. Простое повторение запроса обычно не помогает: сначала нужно найти, где установлен самый низкий лимит, и понять, какой размер действительно нужен приложению.

Ниже — последовательная диагностика для владельца сайта и администратора. Она поможет отличить ограничение веб-сервера от настройки PHP, приложения, прокси или внешнего защитного слоя и исправить причину без снятия всех ограничений.

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

В актуальном стандарте HTTP код 413 называется Content Too Large. Сервер возвращает его, когда содержимое запроса больше, чем он готов или способен обработать. В старых сообщениях и документации встречаются названия Payload Too Large и Request Entity Too Large — обычно речь идёт о том же коде.

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

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

Где может возникнуть 413

Запрос редко идёт прямо от браузера к приложению. Между ними могут находиться несколько уровней:

1. CDN, WAF или внешний reverse proxy;
2. балансировщик нагрузки;
3. Nginx или Apache;
4. runtime приложения, например PHP;
5. CMS, фреймворк или обработчик конкретного API;
6. собственная проверка размера в коде.

Каждый уровень может иметь отдельный предел. Запрос остановит первый компонент, чей лимит оказался меньше. Если увеличить настройку только в PHP, но оставить прежнее ограничение в Nginx, до PHP запрос вообще не дойдёт. И наоборот: после изменения Nginx загрузка может пройти дальше, но быть отклонена приложением.

Почему ошибка бывает только на одном адресе

Лимит нередко задают для отдельного виртуального хоста, каталога или location. Поэтому форма профиля может принимать файл, а импорт каталога на том же домене — возвращать 413. Различаться могут и маршруты через CDN: один URL идёт к origin-серверу напрямую, другой обрабатывается дополнительным прокси.

Как быстро найти ограничивающий слой

1. Зафиксируйте точный сценарий

Запишите:

• URL и HTTP-метод запроса;
• тип операции: загрузка файла, отправка формы, импорт или API;
• примерный размер тела запроса;
• время ошибки;
• возникает ли 413 у всех пользователей;
• проходит ли тот же запрос с меньшим объёмом.

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

2. Сравните маленький и большой запрос

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

Для API можно посмотреть запрос во вкладке Network инструментов разработчика. Полезны статус, URL, метод, заголовки ответа и фактический размер переданных данных. Заголовок Server иногда подсказывает источник ответа, но не является доказательством: прокси может изменить или скрыть его.

3. Сопоставьте логи по времени

Начните с самого внешнего слоя и двигайтесь к приложению. Если reverse proxy записал 413, а в журнале приложения запроса нет, ограничение сработало раньше. Если веб-сервер передал запрос дальше, но приложение вернуло собственный JSON с ошибкой, проверяйте runtime и код обработчика.

Ищите конкретный запрос по времени, маршруту и идентификатору корреляции, если он используется. Не повышайте лимит по одному сообщению из браузера: одинаковую страницу ошибки способны показать разные компоненты.

Настройки Nginx, Apache и PHP

Изменения делайте только после резервной копии конфигурации и проверки синтаксиса. Конкретное место настройки зависит от архитектуры сайта и способа управления сервером.

Nginx: client_max_body_size

В Nginx размер тела запроса ограничивает директива client_max_body_size. Её можно задавать на уровнях http, server и location. Если запрос превышает настроенное значение, Nginx возвращает 413.

Пример для отдельного маршрута загрузки:

location /upload/ {
    client_max_body_size 25m;
    proxy_pass http://app_backend;
}

Значение 25m здесь — только пример, а не универсальная рекомендация. Выберите предел из реального бизнес-сценария и оставьте запас на служебные данные запроса. Не устанавливайте 0, отключающий проверку размера, без отдельного анализа рисков.

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

Apache: LimitRequestBody

В Apache для ограничения тела запроса используется LimitRequestBody. Значение задаётся в байтах и может применяться на уровне сервера, виртуального хоста, каталога или .htaccess, если это разрешено конфигурацией.

Пример лимита для нужного каталога:

<Directory "/var/www/example/upload">
    LimitRequestBody 26214400
</Directory>

Это иллюстрация лимита 25 МиБ. Не копируйте путь и число без проверки своей конфигурации. Сначала выясните, где именно обрабатывается загрузка и разрешено ли переопределение директивы.

PHP: upload_max_filesize и post_max_size

Для загрузки файлов в PHP важны как минимум две настройки:

upload_max_filesize = 20M
post_max_size = 25M

upload_max_filesize ограничивает отдельный загружаемый файл. post_max_size ограничивает весь POST-запрос, поэтому должен быть больше: тело multipart/form-data содержит не только файл, но и границы частей и другие поля формы.

Если POST превышает post_max_size, PHP может оставить $_POST и $_FILES пустыми. Приложению стоит распознавать этот случай и показывать понятное сообщение, а не сообщать пользователю, что файл «не выбран».

Уточните, какой php.ini использует именно веб-процесс. Значения в командной строке и в PHP-FPM могут различаться. После изменения примените настройки тем способом, который предусмотрен вашей инфраструктурой, и проверьте фактическую конфигурацию веб-приложения без публикации лишней служебной информации.

Как согласовать лимиты между слоями

Рабочая схема выглядит так:

1. Определите максимальный размер, который действительно нужен пользователю.
2. Учтите служебный объём формы или API-запроса.
3. Проверьте ограничения внешнего прокси, веб-сервера, runtime и приложения.
4. Настройте их согласованно, чтобы внешний слой не обрывал разрешённый приложением запрос.
5. Оставьте явную серверную валидацию типа, количества и размера файлов.
6. Проверьте свободное место, временный каталог и права записи.
7. Добавьте понятную подсказку о допустимом размере рядом с полем загрузки.
8. Протестируйте запрос немного меньше предела, на границе и немного больше него.

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

Практические сценарии

Большое изображение не загружается в CMS

Сначала проверьте, проходит ли уменьшенная копия того же изображения. Затем сопоставьте лимиты Nginx или Apache с upload_max_filesize и post_max_size. Если запрос доходит до CMS, проверьте её собственное ограничение и обработку формата. Не увеличивайте предел только ради одного исходного файла, если его разумнее заранее оптимизировать.

Импорт или резервная копия обрывается сразу

Большой архив может быть отклонён ещё до запуска PHP. Отсутствие записи в журнале импортера при наличии 413 в логе прокси указывает на внешний слой. Для действительно крупных данных надёжнее может быть загрузка частями или специализированный канал импорта, чем неограниченный POST через публичную форму.

API принимает короткий JSON, но отклоняет большой

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

Чего не стоит делать

• Не отключайте лимиты на всём сервере ради одной формы.
• Не меняйте сразу несколько уровней без промежуточной проверки: так сложнее найти настоящую причину.
• Не путайте 413 с ошибкой 414, которая относится к слишком длинному URL, или с 415, связанной с неподдерживаемым форматом содержимого.
• Не тестируйте production случайными пользовательскими файлами.
• Не забывайте про место на диске, временные каталоги, антивирусную проверку и таймауты: после устранения 413 следующий предел может проявиться отдельно.
• Не полагайтесь только на текст страницы ошибки — проверяйте HTTP-статус и журналы.

Как контролировать проблему после исправления

Обычная проверка главной страницы методом GET не воспроизводит загрузку файла и сама по себе не обнаружит 413 на /upload/. Для критичной формы нужен отдельный безопасный сценарий: тестовый маршрут, синтетический запрос без персональных данных либо метрика приложения, которая показывает долю отказов по статусам.

Web-Puls можно использовать для регулярной проверки общей доступности сайта и быстрого уведомления о недоступности. Это дополняет, но не заменяет журналы приложения и целевую проверку загрузки. Если проблема возникает только при большом POST-запросе, контролировать нужно именно этот пользовательский путь.

Полезно добавить в наблюдение:

• количество ответов 413 по маршрутам;
• источник ответа: внешний прокси, веб-сервер или приложение;
• размер отклонённого запроса без сохранения его содержимого;
• заполнение диска и временного каталога;
• успешное прохождение безопасного теста после релиза конфигурации.

Чеклист исправления 413

1. Подтвердить статус 413 и точный URL.
2. Сравнить маленький и большой безопасные запросы.
3. Найти первый слой, который зарегистрировал отказ.
4. Определить необходимый продуктовый предел.
5. Согласовать настройки прокси, веб-сервера, PHP и приложения.
6. Сохранить проверку типа, количества и размера файлов.
7. Проверить конфигурацию и безопасно применить её.
8. Протестировать значения ниже и выше границы.
9. Сделать сообщение пользователю понятным.
10. Настроить наблюдение за конкретным сценарием.

Когда нужна профессиональная помощь

Если вы не управляете частью инфраструктуры, не можете определить источник 413 или боитесь нарушить работу production, лучше остановиться после сбора безопасной диагностики. Через форму профессиональной поддержки Web-Puls можно передать адрес сайта, время ошибки и описание сценария. Для другого способа связи используйте контактную информацию. Не прикладывайте секреты и пользовательские данные.

Официальные источники

• RFC 9110: 413 Content Too Large
• Документация Nginx: client_max_body_size
• Документация Apache: LimitRequestBody
• Руководство PHP: post_max_size и upload_max_filesize

Вывод

Ошибка 413 появляется не из-за «неисправного файла», а потому, что один из компонентов отказался принимать тело запроса такого размера. Надёжное исправление — найти первый ограничивающий слой, выбрать обоснованный предел, согласовать настройки по всей цепочке и сохранить защитную валидацию. После этого проверьте реальный пользовательский сценарий по обе стороны границы и наблюдайте не только главную страницу, но и критичный маршрут загрузки.