HTTP 413 Заявката е твърде голяма: Основни причини, решения и ръководство за конфигуриране на сървъра

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

Тази грешка не е проблем от страна на клиента. Тя е умишлен механизъм за прилагане, вграден в уеб сървъри като Nginx и Apache, конфигурации на PHP среда за изпълнение и middleware на ниво приложение. Разбирането точно кой слой прилага ограничението — и как да се насочите към правилната конфигурационна директива — е разликата между бързо решение и часове на отстраняване на проблеми.

Защо възникват грешки 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 за безплатните и 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 са значително по-надеждни.

Специфична поправка за WordPress за грешки 413

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, размерът на качването на ниво мрежа се контролира отделно под Администрация на мрежата > Настройки > Настройки на мрежата > Максимален размер на качвания файл. Тази настройка е независима от 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 Editor в 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 Хостинг или Dedicated сървъри за пълен контрол

Често задавани въпроси

Какво е ограничението за качване по подразбиране в 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 за безплатните и Pro планове, 200MB за Business и 500MB за Enterprise. Ако вашата заявка надвишава тези ограничения, Cloudflare връща 413, преди заявката да достигне вашия сървър на произход. Никаква промяна в конфигурацията от страна на сървъра няма да разреши това — трябва или да надградите вашия план за Cloudflare, да използвате директно заобикаляне на качването (предварително подписани URL адреси) или да внедрите качвания на части.

Как да поправя постоянно 413 в WordPress на cPanel сървър?

Използвайте MultiPHP INI Editor на WHM, за да увеличите upload_max_filesize и post_max_size за конкретната версия на PHP и домейн. След това проверете дали промяната се отразява в WordPress под Медия > Добавяне на ново. За WordPress Multisite, допълнително актуализирайте максималния размер на качване под Администрация на мрежата > Настройки. Не са необходими промени в .htaccess или wp-config.php при директно използване на INI редактора на WHM.