# Limitarea rezonabilă a post_max_size și upload_max_filesize

> Limitați post_max_size și upload_max_filesize: relația cu limitele serverului web, valorile provizorii de la php.net pentru PHP2Shell și tipare tipice de erori.

Sursa: https://phpsos.de/ro/blog/post-max-size-upload-limits/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** `post_max_size` limitează dimensiunea totală a unei cereri POST, `upload_max_filesize` fișierul individual; potrivit manualului PHP, valorile implicite sunt 8M și 2M. Valorile trebuie să se potrivească cu limitele din serverul web și din aplicație, altfel încărcările eșuează fără mesaj clar. Până la actualizarea PHP2Shell, php.net recomandă `post_max_size = 8M` fără încărcări sau `32M` cu încărcări, `upload_max_filesize` sub acestea, stabilite astfel încât aplicațiile să nu le suprascrie.

## Când formularul de candidatură tace brusc

După măsurile provizorii pentru PHP2Shell, mulți administratori au redus `post_max_size`. Câteva zile mai târziu, departamentul de resurse umane raportează că nu mai ajung candidaturile. Formularul pur și simplu se reîncarcă, fără niciun mesaj de eroare. Motivul: cererea cu trei atașamente PDF a fost mai mare decât noua limită, iar PHP a eliminat datele formularului.

Exemplul arată problema de fond. Limitele de upload acționează simultan în mai multe locuri, iar fiecare loc reacționează diferit când este depășit. Cine cunoaște lanțul poate stabili valorile astfel încât să protejeze fără a perturba activitatea. Cum procesează PHP intern încărcările explică [Cum procesează PHP încărcările de fișiere](https://phpsos.de/ro/php/datei-uploads-intern/); programarea sigură a funcțiilor de upload o descrie [Implementarea sigură a încărcărilor de fișiere în PHP](https://phpsos.de/ro/ratgeber/datei-upload-sicher/).

## Lanțul limitelor de upload

O cerere trece prin mai multe limite înainte ca aplicația să o vadă. Datele următoare provin din documentațiile Nginx, Apache și PHP:

| Loc | Setare | Valoare implicită conform documentației | La depășire |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | eroarea 413 către browser |
| Apache de la 2.4.54 | `LimitRequestBody` | 1 GiB (până la 2.4.53: nelimitat) | răspuns de eroare în loc de prelucrare |
| PHP | `post_max_size` | 8M | `$_POST` și `$_FILES` goale |
| PHP | `upload_max_filesize` | 2M | fișierul este respins cu un cod de eroare |
| PHP | `max_file_uploads` | 20 | fișierele suplimentare sunt ignorate |
| PHP | `max_input_vars` | 1000 | câmpurile de formular suplimentare lipsesc |

De aici rezultă o regulă simplă: `upload_max_filesize` mai mic decât `post_max_size`, `post_max_size` mai mic decât limita din serverul web. Manualul PHP recomandă, în plus, ca `memory_limit` să fie, în general, mai mare decât `post_max_size`. În timpul măsurii provizorii PHP2Shell cu `memory_limit=-1`, acest rol îl preia limita prin container sau cgroup; mai multe la [Setarea corectă a memory_limit](https://phpsos.de/ro/blog/memory-limit-richtig-setzen/).

## post_max_size după PHP2Shell: ce recomandă php.net

În anunțul de securitate din 21.10.2026, php.net indică, pentru serverele fără actualizare, limite scăzute ale cererilor drept una dintre măsurile provizorii. Ele reduc riscul unor căi de atac individuale, dar nu sunt în mod explicit o protecție completă:

1. **Fără încărcări de fișiere:** `post_max_size = 8M`.
2. **Cu încărcări de fișiere:** `post_max_size = 32M`.
3. **În ambele cazuri:** păstrați `upload_max_filesize` sub `post_max_size`.
4. **Luați în considerare suplimentar:** limite în serverul web sau în proxy pentru dimensiunea decodată a cererii, numărul câmpurilor de intrare, numărul părților multipart, numărul liniilor de antet și adâncimea de imbricare. Potrivit php.net, aceste limite trebuie să cuprindă și cererile fără o indicație utilizabilă `Content-Length`.

Valorile aparțin unde aplicațiile nu le pot suprascrie. Deoarece, potrivit manualului, `post_max_size` și `upload_max_filesize` pot fi modificate la nivel de director, un `.user.ini` sau, la mod_php, un `.htaccess` le-ar putea ridica din nou:

```ini
; Pool-ul FPM al site-ului, cu încărcări (tranziție până la actualizare)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

În serverul web trageți limita puțin mai sus, pentru ca cererile prea mari să nu mai ajungă deloc la PHP:

```nginx
# Nginx, în blocul server sau location
client_max_body_size 32m;
```

```apache
# Apache, în VirtualHost: 32 MiB în octeți
LimitRequestBody 33554432
```

Apoi reîncărcați toți workerii PHP și serverul web. Prezentarea tuturor măsurilor provizorii se află la [Măsuri imediate dacă nu puteți încă aplica patchul](https://phpsos.de/ro/php2shell/sofortmassnahmen-ohne-patch/). Dacă și cum pot fi filtrate suplimentar cererile de upload la proxy analizează [Filtrarea cererilor de upload la margine](https://phpsos.de/ro/blog/upload-anfragen-am-rand-filtern/).

> **Important:**
> După fiecare modificare, testați formularele cu cele mai mari cereri legitime: candidaturi cu mai multe atașamente, importuri de produse, galerii de imagini. O valoare prea strânsă paralizează procese de afaceri, fără ca cineva să vadă un mesaj de eroare.

## Stabilirea valorii potrivite pentru site-ul dumneavoastră

În locul unor valori generale merită o scurtă inventariere. Listați toate formularele cu încărcări și notați cel mai mare fișier legitim și cel mai mare număr de fișiere simultane. De aici rezultă necesarul: `upload_max_filesize` acoperă cel mai mare fișier individual, `post_max_size` suma tuturor fișierelor unei cereri plus o mică rezervă pentru câmpurile de formular.

Dacă necesarul depășește 32M, el nu se potrivește cu recomandarea provizorie de la php.net. Atunci este un motiv în plus de a devansa actualizarea. Încărcările mari pot fi tratate și printr-un subdomeniu propriu, cu pool propriu, pentru ca restul site-ului să păstreze limite strânse.

După actualizarea la 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau la un backport confirmat, puteți alinia din nou valorile la necesarul real. Totuși, ele nu ar trebui să fie mai generoase decât este nevoie: orice limită care depășește necesarul mărește suprafața de atac fără beneficiu. Dacă un site nu are nevoie deloc de încărcări, `file_uploads = Off` este cea mai curată soluție.

## Interpretarea corectă a tiparelor de erori

Când încărcările eșuează, comportamentul trădează care limită se aplică. O pagină cu eroarea 413 provine de la serverul web. Un formular care se reîncarcă fără mesaj sau raportează „cerere nevalidă” indică date `$_POST` goale, deci `post_max_size`. Un mesaj al aplicației despre un singur fișier se potrivește cu `upload_max_filesize`. Iar câmpurile lipsă în formulare foarte mari, de exemplu la variante de produs, indică `max_input_vars`. Jurnalul de erori PHP conține, de regulă, la depășirea `post_max_size`, un avertisment cu dimensiunea cererii.

Pentru ca utilizatorii să nu rămână descumpăniți, aplicația ar trebui să recunoască acest caz. Manualul PHP sugerează în acest scop o cale simplă: formularul transmite un marker în adresă, de exemplu `?processed=1`. Dacă markerul ajunge, dar `$_POST` și `$_FILES` sunt goale, cererea a fost prea mare, iar aplicația poate afișa un mesaj ușor de înțeles, cu dimensiunea admisă.

## Cum ajută PHP SOS concret?

- Inventariem toate căile de upload ale site-urilor dumneavoastră și stabilim dimensiunile necesare în realitate.
- Stabilim coerent limitele serverului web, ale PHP și ale pool-ului, blocate împotriva suprascrierii, inclusiv valorile provizorii de la php.net.
- Testăm formularele, importurile și încărcările după trecere și ajustăm țintit valorile.
- În cadrul [securizării serverului](https://phpsos.de/ro/leistungen/server-haertung/) readucem valorile, după actualizare, la necesarul permanent.


## Întrebări frecvente

**Care este diferența dintre post_max_size și upload_max_filesize?**  
upload_max_filesize limitează dimensiunea unui singur fișier încărcat. post_max_size limitează totalul datelor unei cereri POST, deci toate fișierele și câmpurile de formular la un loc. Potrivit manualului PHP, post_max_size trebuie de aceea să fie mai mare decât upload_max_filesize.

**Ce se întâmplă dacă o cerere este mai mare decât post_max_size?**  
Potrivit manualului PHP, $_POST și $_FILES sunt atunci goale. Aplicația nu primește deci deloc datele formularului și afișează adesea doar un mesaj de eroare neclar sau reîncarcă formularul. Aceasta face eroarea greu de recunoscut.

**Ce valori recomandă php.net din cauza PHP2Shell?**  
Ca măsură provizorie până la actualizare: post_max_size = 8M pentru aplicații fără încărcări de fișiere, 32M pentru aplicații cu încărcări, iar upload_max_filesize sub aceste valori. Potrivit php.net, aceasta nu este o protecție completă; doar actualizarea la o versiune PHP corectată închide vulnerabilitățile.

**Pot modifica post_max_size prin ini_set() în cod?**  
Nu. Potrivit manualului PHP, post_max_size poate fi modificat doar la nivel de director, de exemplu în php.ini, în pool-ul FPM, în .user.ini sau, la mod_php, în .htaccess. Cine vrea să impună valoarea o stabilește cu php_admin_value; atunci nici un .user.ini nu o poate suprascrie.

## Surse

- [php.net: anunț de securitate din 21.10.2026](https://www.php.net/)
- [Manualul PHP: setări Core (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Documentația Nginx: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Documentația Apache: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)