HTTP 413 Entitate de Cerere Prea Mare: Cauze Principale, Soluții și Ghid de Configurare a Serverului

Eroarea HTTP 413 Request Entity Too Large este un cod de stare de răspuns de la server care apare atunci când corpul unei cereri primite — cel mai frecvent un fișier încărcat — depășește dimensiunea maximă a payload-ului configurată la nivelul serverului web, al proxy-ului invers sau al stratului aplicației. Serverul respinge activ cererea înainte de a o procesa, returnând un status 413 clientului.

Această eroare nu este un bug de pe partea clientului. Este un mecanism deliberat de aplicare integrat în servere web precum Nginx și Apache, în configurațiile runtime PHP și în middleware-ul la nivel de aplicație. Înțelegerea exactă a stratului care aplică limita — și cum să vizezi directiva de configurare corectă — face diferența dintre o remediere curată și ore de depanare.

De ce apar erorile HTTP 413: O analiză strat cu strat

O cerere de încărcare a unui fișier trece prin mai multe straturi de procesare înainte de a ajunge la aplicația ta. Oricare dintre aceste straturi poate respinge independent cererea cu un răspuns 413. Diagnosticarea corectă a erorii necesită identificarea stratului responsabil.

Stratul 1: Directive ale serverului web

Nginx aplică limitele de dimensiune a încărcărilor prin directiva client_max_body_size. Valoarea sa implicită este de 1MB, care este extrem de mică pentru majoritatea aplicațiilor moderne. Această directivă poate fi setată în contextul blocului http, server sau location, iar blocul cel mai specific câștigă.

Apache folosește directiva LimitRequestBody, care implicit este 0 (nelimitat) în majoritatea distribuțiilor — dar furnizorii de hosting suprascriu de obicei această valoare în configurațiile lor globale sau ale gazdei virtuale la o valoare restrictivă. Apache procesează și fișierele .htaccess, ceea ce înseamnă că limita poate fi aplicată la nivel de director fără a atinge configurația principală.

Stratul 2: Configurarea runtime PHP

PHP introduce două directive independente care trebuie ambele satisfăcute pentru ca o încărcare mare să reușească:

• upload_max_filesize — dimensiunea maximă a unui singur fișier încărcat
• post_max_size — dimensiunea maximă a întregului corp al cererii POST, care trebuie să fie egală sau mai mare decât upload_max_filesize

O configurare greșită frecventă este setarea upload_max_filesize = 50M lăsând în același timp post_max_size la valoarea sa implicită de 8M. Limita corpului POST este evaluată prima, astfel încât încărcarea eșuează silențios înainte ca limita de dimensiune a fișierului să fie verificată.

Există și o a treia directivă care este adesea trecută cu vederea: max_input_time, care definește cât timp va aștepta PHP pentru a primi datele de intrare. Pe conexiuni lente care încarcă fișiere mari, acest timeout poate declanșa un eșec care se manifestă ca un 413 sau un răspuns gol.

Stratul 3: Proxy-uri inverse și echilibratoare de sarcină

Dacă infrastructura ta folosește un proxy invers — HAProxy, Varnish, Cloudflare sau o instanță Nginx care acționează ca proxy în fața altui server — acel strat proxy are propriile limite de dimensiune a corpului. Un 413 returnat de Cloudflare, de exemplu, are o limită strictă de 100MB pentru planurile Free și Pro, și nicio configurare de pe server nu o va suprascrie. Verificați întotdeauna antetele de răspuns ale proxy-ului pentru a identifica originea erorii 413.

Stratul 4: Restricții ale aplicației și CMS

Sistemele de gestionare a conținutului și framework-urile aplică propriile restricții de încărcare peste straturile serverului și PHP. WordPress citește limita efectivă de încărcare din valorile runtime ale PHP, dar aplică și propriile constrângeri ale bibliotecii media. Unele plugin-uri WordPress adaugă straturi suplimentare de validare. Aplicațiile PHP personalizate pot folosi logica de validare $_FILES care impune limite mai stricte decât cele permise de server.

Configurarea Nginx: Remedierea erorii 413 la nivelul serverului web

Pentru Nginx, remedierea necesită modificarea client_max_body_size în contextul de configurare corect. Editarea blocului http aplică limita global; editarea unui bloc server sau location o aplică doar acelei gazde virtuale sau acelui endpoint.

# 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;
    }
}

După editare, validați sintaxa configurației înainte de reîncărcare:

nginx -t && systemctl reload nginx

Caz limită critic: Dacă Nginx acționează ca proxy invers în fața PHP-FPM sau a altui server de aplicații, trebuie să verificați și directivele proxy_read_timeout și proxy_send_timeout. O încărcare mare care durează mai mult decât timeout-ul va fi terminată în mijlocul transferului, producând o eroare 413 sau 504 în funcție de comportamentul proxy-ului.

Configurarea Apache: Remedierea erorii 413 la nivelul serverului web

Directiva LimitRequestBody a Apache acceptă o valoare în octeți. Directiva poate fi plasată în httpd.conf, un bloc VirtualHost, un bloc Directory sau un fișier .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

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

Valoarea 104857600 este egală cu 100MB (100 × 1024 × 1024). După modificarea httpd.conf sau a unui fișier de gazdă virtuală, reporniți Apache:

apachectl configtest && systemctl restart apache2

Nuanță importantă: În mediile de hosting partajat, modificările .htaccess pot fi ignorate dacă furnizorul de hosting a setat AllowOverride None în configurația lor la nivel de server. În acest caz, doar furnizorul de hosting poate schimba limita. Acesta este unul dintre principalele motive tehnice pentru a lua în considerare migrarea la un mediu de VPS Hosting unde aveți acces root complet la configurația serverului.

Configurarea PHP: Remedierea erorii 413 la nivelul runtime

Fișierul php.ini este sursa autoritativă pentru limitele de încărcare PHP. Fișierul corect de editat depinde de modelul de execuție PHP (mod_php, PHP-FPM, CLI). Folosiți phpinfo() sau php --ini pentru a identifica care php.ini este efectiv încărcat.

; 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

După editarea php.ini, reporniți serviciul corespunzător:

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

# For Apache with mod_php
systemctl restart apache2

Metode alternative când php.ini nu este accesibil:

Dacă vă aflați pe un plan de hosting partajat fără acces direct la php.ini, puteți suprascrie setările PHP folosind:

1. Un fișier .user.ini în rădăcina web (funcționează cu PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. O directivă .htaccess (funcționează doar cu mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Cod PHP runtime (eficiență limitată, nu este recomandat pentru producție):

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

Rețineți că ini_set() nu poate suprascrie upload_max_filesize sau post_max_size la runtime în PHP 7.x și versiunile ulterioare — aceste directive sunt evaluate înainte de începerea execuției scriptului. Metodele .user.ini sau .htaccess sunt mult mai fiabile.

Remediere specifică WordPress pentru erorile 413

WordPress afișează limita efectivă de încărcare în ecranul Media > Adaugă nou. Dacă limita afișată este mai mică decât cea configurată în php.ini, problema este de obicei că WordPress citește dintr-un proces PHP diferit sau că un strat de cache servește date de configurare vechi.

Adăugați următoarele în wp-config.php pentru a defini explicit dimensiunea de încărcare:

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

Pentru instalările WordPress Multisite, dimensiunea de încărcare la nivel de rețea este controlată separat sub Network Admin > Settings > Network Settings > Max upload file size. Această setare este independentă de limitele PHP și trebuie configurată în plus față de modificările la nivel de server.

Comparație: Unde să remediați eroarea 413 în funcție de mediul de hosting

Diagnosticarea stratului care returnează eroarea 413

Înainte de a aplica orice remediere, confirmați sursa răspunsului 413. Folosiți curl cu ieșire detaliată pentru a inspecta antetele de răspuns:

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

Examinați antetul de răspuns Server și orice antete X-Powered-By sau CF-RAY. Un antet CF-RAY indică faptul că eroarea 413 a provenit de la Cloudflare, nu de la serverul dvs. Un răspuns de la nginx/1.x.x indică stratul Nginx. Absența unui antet Server poate indica un echilibrator de sarcină sau un WAF din amonte față de aplicația dvs.

Verificați și jurnalele de erori ale serverului imediat după declanșarea erorii 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

Când configurarea serverului nu este suficientă: Considerații privind infrastructura

Pentru aplicațiile care gestionează în mod regulat transferuri mari de fișiere — platforme video, sisteme de backup, imagistică medicală, cataloage mari de produse e-commerce — codificarea hardcoded a unor limite mari de încărcare într-o configurație de server partajat nu este o arhitectură sustenabilă. Luați în considerare aceste alternative:

• Încărcări fragmentate (chunked uploads): Împărțiți fișierele mari în fragmente mai mici pe partea clientului folosind biblioteci precum Resumable.js sau Uppy. Fiecare fragment se încadrează în limita serverului, iar serverul le reasamblează. Aceasta ocolește complet eroarea 413.
• Încărcări directe în object storage: Generați un URL pre-semnat pentru stocarea compatibilă S3 și lăsați clientul să încarce direct, ocolind complet serverul web. Serverul web gestionează doar tranzacția de metadate.
• Endpoint-uri dedicate pentru încărcare: Configurați un bloc location separat în Nginx cu un client_max_body_size mai mare specific pentru rutele de încărcare, menținând limita implicită restrictivă pentru toate celelalte endpoint-uri.

Pentru sarcinile de lucru intensive din punct de vedere computațional care implică procesarea fișierelor mari — transcodare video, inferență de machine learning pe datele încărcate — un mediu de GPU Hosting oferă capacitatea de procesare necesară pentru a gestiona atât încărcarea, cât și calculul ulterior fără blocaje.

Dacă aplicația dvs. necesită un mediu de panou de control gestionat cu acces complet la configurarea PHP, un VPS cu cPanel vă oferă MultiPHP INI Editor în WHM, permițând suprascrierea directivelor PHP per domeniu fără a accesa linia de comandă.

Considerații de securitate la creșterea limitelor de încărcare

Creșterea limitelor de încărcare fără întărirea corespunzătoare a securității introduce o suprafață reală de atac. Un server care acceptă cereri POST de 500MB este o țintă viabilă pentru atacuri de tip denial-of-service care epuizează I/O-ul de disc, memoria sau pool-urile de conexiuni.

Implementați următoarele controale alături de orice creștere a limitei:

• Limitarea ratei pe endpoint-urile de încărcare: În Nginx, folosiți limit_req_zone pentru a restricționa frecvența încărcărilor per IP.
• Validarea tipului de fișier: Nu vă bazați niciodată pe tipul MIME furnizat de client. Validați semnăturile fișierelor (magic bytes) pe partea serverului.
• Permisiunile directorului de încărcare: Directorul care primește încărcările nu trebuie să fie accesibil web sau executabil. Stocați încărcările în afara rădăcinii documentului.
• Scanare antivirus: Integrați ClamAV sau un scanner similar în pipeline-ul de încărcare pentru orice endpoint de încărcare accesibil public.
• Încărcări doar autentificate: Solicitați autentificare înainte de a accepta payload-uri mari. Endpoint-urile de încărcare mare neautentificate sunt exploatate cu ușurință.

Pentru mediile de producție care gestionează date sensibile încărcate, asocierea infrastructurii de hosting cu Certificate SSL configurate corespunzător asigură că transferurile de fișiere sunt criptate în tranzit, prevenind interceptarea conținutului încărcat.

Matricea de decizie tehnică: Alegerea remedierii corecte

Listă de verificare practică pentru rezolvarea HTTP 413

• Identificați stratul care returnează eroarea 413 folosind curl -v și jurnalele de erori ale serverului înainte de a face orice modificări
• Pe Nginx, setați client_max_body_size în cel mai specific bloc aplicabil (location preferat față de server față de http)
• Asigurați-vă că post_max_size este întotdeauna mai mare sau egal cu upload_max_filesize în php.ini
• Creșteți max_input_time și max_execution_time pentru fișiere mari pe conexiuni lente
• Verificați că suprascrierile .htaccess sunt permise (AllowOverride All sau AllowOverride Options) înainte de a vă baza pe ele
• Verificați toate straturile proxy independent — CDN, echilibratorul de sarcină și serverul de aplicații aplică fiecare limite separat
• După orice modificare de configurare, reîncărcați (nu doar reporniți) serviciul relevant și ștergeți orice cache de opcode sau de pagină
• Pentru WordPress Multisite, configurați limita de încărcare la nivel de rețea în plus față de directivele PHP
• Implementați limitarea ratei și validarea tipului de fișier înainte de a crește limitele pe endpoint-urile de încărcare publice
• Dacă hostingul partajat împiedică accesul la configurare, migrați la un mediu de VPS Hosting sau Servere dedicate pentru control complet

Întrebări frecvente

Care este limita implicită de încărcare în Nginx care cauzează o eroare 413?

Nginx setează implicit client_max_body_size la 1MB. Orice corp de cerere care depășește 1MB va returna un 413 dacă această directivă nu este explicit mărită în configurația Nginx.

Pot remedia o eroare 413 fără acces root la server?

Pe hosting partajat, puteți încerca remedieri prin .htaccess (doar Apache, dacă AllowOverride permite) sau un fișier .user.ini (doar PHP-FPM). Cu toate acestea, dacă furnizorul de hosting a setat limite globale restrictive, aceste metode vor fi ineficiente și va trebui să contactați suportul sau să faceți upgrade la un plan VPS.

De ce eșuează încărcarea chiar și după creșterea upload_max_filesize în php.ini?

Cauza cea mai frecventă este că post_max_size rămâne la valoarea sa implicită mai mică. PHP evaluează limita de dimensiune a corpului POST înainte de limita individuală a dimensiunii fișierului, astfel încât încărcarea este respinsă înainte ca upload_max_filesize să fie verificat. Creșteți întotdeauna ambele directive simultan.

Cloudflare cauzează erori 413?

Da. Cloudflare aplică propriile limite de dimensiune a corpului cererii: 100MB pentru planurile Free și Pro, 200MB pentru Business și 500MB pentru Enterprise. Dacă cererea dvs. depășește aceste limite, Cloudflare returnează un 413 înainte ca cererea să ajungă la serverul dvs. de origine. Nicio modificare de configurare a serverului nu va rezolva acest lucru — trebuie fie să faceți upgrade la planul Cloudflare, să folosiți bypass direct de încărcare (URL-uri pre-semnate) sau să implementați încărcări fragmentate.

Cum remediez permanent eroarea 413 în WordPress pe un server cPanel?

Folosiți MultiPHP INI Editor din WHM pentru a crește upload_max_filesize și post_max_size pentru versiunea PHP și domeniul specific. Apoi verificați că modificarea se reflectă în WordPress sub Media > Adaugă nou. Pentru WordPress Multisite, actualizați suplimentar dimensiunea maximă de încărcare sub Network Admin > Settings. Nu sunt necesare modificări .htaccess sau wp-config.php când folosiți direct editorul INI din WHM.