HTTP 413 Запит занадто великий: основні причини, виправлення та посібник з налаштування сервера

Помилка HTTP 413 Request Entity Too Large — це код статусу відповіді на стороні сервера, який виникає, коли тіло вхідного запиту — найчастіше завантаження файлу — перевищує максимальний розмір корисного навантаження, налаштований на рівні веб-сервера, зворотного проксі або застосунку. Сервер активно відхиляє запит до його обробки, повертаючи клієнту статус 413.

Ця помилка не є помилкою на стороні клієнта. Це навмисний механізм примусового виконання, вбудований у веб-сервери, такі як Nginx та Apache, конфігурації середовища виконання PHP та проміжне програмне забезпечення на рівні застосунку. Розуміння того, який саме рівень застосовує обмеження — і як визначити правильну директиву конфігурації — є різницею між чистим виправленням і годинами усунення несправностей.

Чому виникають помилки HTTP 413: Покроковий аналіз рівнів

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

Рівень 1: Директиви веб-сервера

Nginx застосовує обмеження розміру завантаження через директиву client_max_body_size. Її значення за замовчуванням становить 1MB, що є надто малим для більшості сучасних застосунків. Цю директиву можна встановити в контексті блоку http, server або location, і найбільш специфічний блок має пріоритет.

Apache використовує директиву LimitRequestBody, яка за замовчуванням дорівнює 0 (необмежено) у більшості дистрибутивів — але хостинг-провайдери регулярно перевизначають це значення у своїх глобальних конфігураціях або конфігураціях віртуальних хостів на обмежувальне значення. Apache також обробляє файли .htaccess, що означає, що обмеження може застосовуватися на рівні каталогу без зміни основної конфігурації.

Рівень 2: Конфігурація середовища виконання PHP

PHP вводить дві незалежні директиви, які обидві повинні бути виконані для успішного завантаження великого файлу:

• upload_max_filesize — максимальний розмір одного завантаженого файлу
• post_max_size — максимальний розмір усього тіла POST-запиту, який повинен бути рівним або більшим за upload_max_filesize

Поширена помилка конфігурації — встановлення upload_max_filesize = 50M при залишенні post_max_size зі значенням за замовчуванням 8M. Обмеження тіла POST оцінюється першим, тому завантаження мовчки завершується невдачею ще до перевірки обмеження розміру файлу.

Існує також третя директива, яку часто ігнорують: max_input_time, яка визначає, скільки часу PHP чекатиме на отримання вхідних даних. При повільних з’єднаннях під час завантаження великих файлів цей тайм-аут може спричинити збій, який проявляється як 413 або порожня відповідь.

Рівень 3: Зворотні проксі та балансувальники навантаження

Якщо ваша інфраструктура використовує зворотний проксі — HAProxy, Varnish, Cloudflare або екземпляр Nginx, що діє як проксі перед іншим сервером — цей рівень проксі має власні обмеження розміру тіла. Наприклад, 413, повернутий Cloudflare, має жорстке обмеження 100MB для планів Free та Pro, і жодна серверна конфігурація не може його перевизначити. Завжди перевіряйте заголовки відповіді вашого проксі-рівня, щоб визначити джерело 413.

Рівень 4: Обмеження застосунку та CMS

Системи керування контентом та фреймворки застосовують власні обмеження завантаження поверх рівнів сервера та PHP. WordPress зчитує ефективне обмеження завантаження зі значень середовища виконання PHP, але також застосовує власні обмеження медіатеки. Деякі плагіни WordPress додають додаткові рівні перевірки. Власні PHP-застосунки можуть використовувати логіку перевірки $_FILES, яка встановлює суворіші обмеження, ніж дозволяє сервер.

Конфігурація Nginx: Виправлення 413 на рівні веб-сервера

Для Nginx виправлення вимагає зміни client_max_body_size у правильному контексті конфігурації. Редагування блоку http застосовує обмеження глобально; редагування блоку server або location застосовує його лише до цього віртуального хоста або кінцевої точки.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Після редагування перевірте синтаксис конфігурації перед перезавантаженням:

nginx -t && systemctl reload nginx

Критичний граничний випадок: Якщо Nginx діє як зворотний проксі перед PHP-FPM або іншим сервером застосунків, вам також необхідно перевірити директиви proxy_read_timeout та proxy_send_timeout. Велике завантаження, яке займає більше часу, ніж тайм-аут, буде перервано посередині передачі, що призведе до помилки 413 або 504 залежно від поведінки проксі.

Конфігурація Apache: Виправлення 413 на рівні веб-сервера

Директива LimitRequestBody Apache приймає значення в байтах. Директиву можна розмістити в httpd.conf, блоці VirtualHost, блоці Directory або файлі .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

Значення 104857600 дорівнює 100MB (100 × 1024 × 1024). Після зміни httpd.conf або файлу віртуального хоста перезапустіть Apache:

apachectl configtest && systemctl restart apache2

Важливий нюанс: У середовищах спільного хостингу зміни .htaccess можуть ігноруватися, якщо хостинг-провайдер встановив AllowOverride None у своїй конфігурації на рівні сервера. У такому випадку лише хостинг-провайдер може змінити обмеження. Це одна з основних технічних причин розглянути перехід на середовище VPS Хостингу, де ви маєте повний root-доступ до конфігурації сервера.

Конфігурація PHP: Виправлення 413 на рівні середовища виконання

Файл php.ini є авторитетним джерелом для обмежень завантаження PHP. Правильний файл для редагування залежить від вашої моделі виконання PHP (mod_php, PHP-FPM, CLI). Використовуйте phpinfo() або php --ini, щоб визначити, який php.ini фактично завантажено.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Після редагування php.ini перезапустіть відповідний сервіс:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Альтернативні методи, коли php.ini недоступний:

Якщо ви на плані спільного хостингу без прямого доступу до php.ini, ви можете спробувати перевизначити налаштування PHP за допомогою:

1. Файлу .user.ini у кореневому каталозі веб-сайту (працює з PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Директиви .htaccess (працює лише з mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Коду PHP під час виконання (обмежена ефективність, не рекомендується для виробничого середовища):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Зверніть увагу, що ini_set() не може перевизначити upload_max_filesize або post_max_size під час виконання в PHP 7.x і пізніших версіях — ці директиви оцінюються до початку виконання скрипту. Методи .user.ini або .htaccess є значно надійнішими.

Виправлення помилок 413 для WordPress

WordPress відображає своє ефективне обмеження завантаження на екрані Медіа > Додати новий. Якщо показане обмеження нижче, ніж те, що ви налаштували в php.ini, проблема зазвичай полягає в тому, що WordPress зчитує дані з іншого PHP-процесу або рівень кешування обслуговує застарілі дані конфігурації.

Додайте наступне до wp-config.php, щоб явно визначити розмір завантаження:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Для інсталяцій WordPress Multisite розмір завантаження на рівні мережі контролюється окремо в розділі Network Admin > Settings > Network Settings > Max upload file size. Це налаштування не залежить від обмежень PHP і повинно бути налаштоване на додаток до змін на рівні сервера.

Порівняння: Де виправляти 413 залежно від середовища хостингу

Діагностика того, який рівень повертає 413

Перш ніж застосовувати будь-яке виправлення, підтвердіть джерело відповіді 413. Використовуйте curl з детальним виводом для перевірки заголовків відповіді:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Перевірте заголовок відповіді Server та будь-які заголовки X-Powered-By або CF-RAY. Заголовок CF-RAY вказує на те, що 413 виник на Cloudflare, а не на вашому сервері. Відповідь від nginx/1.x.x вказує на рівень Nginx. Відсутність заголовка Server може вказувати на балансувальник навантаження або WAF вище за вашим застосунком.

Також перевірте журнали помилок сервера одразу після виникнення 413:

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

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Коли конфігурації сервера недостатньо: Міркування щодо інфраструктури

Для застосунків, які регулярно обробляють великі передачі файлів — відеоплатформи, системи резервного копіювання, медична візуалізація, великомасштабні каталоги продуктів електронної комерції — жорстке кодування високих обмежень завантаження в конфігурацію спільного сервера не є стійкою архітектурою. Розгляньте такі альтернативи:

• Завантаження частинами: Розбивайте великі файли на менші частини на стороні клієнта за допомогою бібліотек, таких як Resumable.js або Uppy. Кожна частина знаходиться в межах обмеження сервера, і сервер збирає їх разом. Це повністю обходить 413.
• Завантаження безпосередньо до об’єктного сховища: Генеруйте попередньо підписану URL-адресу для S3-сумісного сховища та дозвольте клієнту завантажувати безпосередньо, повністю обходячи ваш веб-сервер. Веб-сервер обробляє лише транзакцію метаданих.
• Виділені кінцеві точки завантаження: Налаштуйте окремий блок location в Nginx з вищим client_max_body_size спеціально для маршрутів завантаження, зберігаючи обмеження за замовчуванням обмежувальним для всіх інших кінцевих точок.

Для обчислювально інтенсивних робочих навантажень, пов’язаних з обробкою великих файлів — транскодування відео, висновок машинного навчання на завантажених даних — середовище GPU Хостингу забезпечує обчислювальну потужність для обробки як завантаження, так і подальших обчислень без вузьких місць.

Якщо ваш застосунок вимагає керованого середовища панелі керування з повним доступом до конфігурації PHP, VPS з cPanel надає вам редактор MultiPHP INI у WHM, що дозволяє перевизначати директиви PHP для кожного домену без використання командного рядка.

Міркування безпеки при підвищенні обмежень завантаження

Збільшення обмежень завантаження без відповідного посилення безпеки створює реальну поверхню атаки. Сервер, який приймає POST-запити розміром 500MB, є реальною ціллю для атак типу «відмова в обслуговуванні», які вичерпують дисковий I/O, пам’ять або пули з’єднань.

Впровадьте такі засоби контролю разом із будь-яким збільшенням обмежень:

• Обмеження частоти запитів на кінцевих точках завантаження: У Nginx використовуйте limit_req_zone для обмеження частоти завантаження на IP-адресу.
• Перевірка типу файлу: Ніколи не покладайтеся на MIME-тип, наданий клієнтом. Перевіряйте сигнатури файлів (магічні байти) на стороні сервера.
• Дозволи каталогу завантаження: Каталог, що отримує завантаження, не повинен бути доступним через веб або виконуваним. Зберігайте завантаження поза кореневим каталогом документів.
• Сканування на віруси: Інтегруйте ClamAV або подібний сканер у конвеєр завантаження для будь-якої публічно доступної кінцевої точки завантаження.
• Лише автентифіковані завантаження: Вимагайте автентифікацію перед прийняттям великих корисних навантажень. Неавтентифіковані кінцеві точки великого завантаження легко зловживаються.

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

Матриця технічних рішень: Вибір правильного виправлення

Практичний контрольний список для вирішення HTTP 413

• Визначте рівень, що повертає 413, за допомогою curl -v та журналів помилок сервера перед внесенням будь-яких змін
• У Nginx встановіть client_max_body_size у найбільш специфічному застосовному блоці (location має пріоритет над server над http)
• Переконайтеся, що post_max_size завжди більше або дорівнює upload_max_filesize у php.ini
• Збільшіть max_input_time та max_execution_time для великих файлів при повільних з’єднаннях
• Перевірте, чи дозволені перевизначення .htaccess (AllowOverride All або AllowOverride Options) перед тим, як покладатися на них
• Перевіряйте всі рівні проксі незалежно — CDN, балансувальник навантаження та сервер застосунків кожен окремо застосовують обмеження
• Після будь-якої зміни конфігурації перезавантажте (а не просто перезапустіть) відповідний сервіс і очистіть будь-який кеш опкодів або сторінок
• Для WordPress Multisite налаштуйте обмеження завантаження на рівні мережі на додаток до директив PHP
• Впровадьте обмеження частоти запитів та перевірку типу файлу перед підвищенням обмежень на публічно доступних кінцевих точках завантаження
• Якщо спільний хостинг перешкоджає доступу до конфігурації, перейдіть на середовище VPS Хостингу або Виділених серверів для повного контролю

Часті запитання

Яке обмеження завантаження за замовчуванням у Nginx спричиняє помилку 413?

Nginx за замовчуванням встановлює client_max_body_size на 1MB. Будь-яке тіло запиту, що перевищує 1MB, поверне 413, якщо ця директива явно не збільшена в конфігурації Nginx.

Чи можна виправити помилку 413 без root-доступу до сервера?

На спільному хостингу ви можете спробувати виправлення через .htaccess (лише Apache, якщо AllowOverride дозволяє) або файл .user.ini (лише PHP-FPM). Однак якщо хостинг-провайдер встановив обмежувальні глобальні обмеження, ці методи будуть неефективними, і вам потрібно буде звернутися до підтримки або перейти на план VPS.

Чому моє завантаження завершується невдачею навіть після збільшення upload_max_filesize у php.ini?

Найпоширеніша причина полягає в тому, що post_max_size залишається зі своїм нижчим значенням за замовчуванням. PHP оцінює обмеження розміру тіла POST перед обмеженням розміру окремого файлу, тому завантаження відхиляється ще до перевірки upload_max_filesize. Завжди збільшуйте обидві директиви одночасно.

Чи спричиняє Cloudflare помилки 413?

Так. Cloudflare застосовує власні обмеження розміру тіла запиту: 100MB для планів Free та Pro, 200MB для Business та 500MB для Enterprise. Якщо ваш запит перевищує ці обмеження, Cloudflare повертає 413 до того, як запит досягне вашого сервера-джерела. Жодна зміна конфігурації на стороні сервера не вирішить цю проблему — вам потрібно або оновити план Cloudflare, використовувати пряме обходження завантаження (попередньо підписані URL-адреси), або впровадити завантаження частинами.

Як назавжди виправити 413 у WordPress на сервері cPanel?

Використовуйте редактор MultiPHP INI у WHM для збільшення upload_max_filesize та post_max_size для конкретної версії PHP та домену. Потім перевірте, чи відображається зміна у WordPress у розділі Медіа > Додати новий. Для WordPress Multisite додатково оновіть максимальний розмір завантаження в розділі Network Admin > Settings. Зміни .htaccess або wp-config.php не потрібні при безпосередньому використанні редактора INI у WHM.