Röviden: A post_max_size egy POST-kérés teljes méretét korlátozza, az upload_max_filesize az egyes fájlt; az alapértelmezés a PHP kézikönyve szerint 8M, illetve 2M. Az értékeknek illeszkedniük kell a webszerver és az alkalmazás határaihoz, különben a feltöltések egyértelmű üzenet nélkül hiúsulnak meg. A PHP2Shell-frissítésig a php.net a post_max_size = 8M értéket javasolja feltöltés nélkül, vagy 32M-t feltöltésekkel, az upload_max_filesize ez alatt, úgy beállítva, hogy az alkalmazások ne írhassák felül.
Amikor a jelentkezési űrlap hirtelen elnémul
A PHP2Shell átmeneti intézkedései után sok adminisztrátor csökkentette a post_max_size értékét. Néhány nappal később a személyzeti osztály jelzi, hogy a jelentkezések nem érkeznek meg. Az űrlap egyszerűen újratöltődik, hibaüzenet nincs. Az ok: a három PDF-mellékletet tartalmazó kérés nagyobb volt az új határnál, és a PHP elvetette az űrlapadatokat.
A példa az alapproblémát mutatja. A feltöltési határok egyszerre több helyen hatnak, és minden hely másképp reagál, ha túllépik. Aki ismeri a láncot, úgy állíthatja be az értékeket, hogy védjenek anélkül, hogy zavarnák az üzemet. Hogyan dolgozza fel belsőleg a PHP a feltöltéseket, azt a Hogyan dolgozza fel a PHP a fájlfeltöltéseket magyarázza; a feltöltési funkciók biztonságos programozását a Fájlfeltöltés biztonságos megvalósítása PHP-ban írja le.
A feltöltési határok lánca
Egy kérés több határon halad át, mielőtt az alkalmazás meglátja. A következő adatok az Nginx, az Apache és a PHP dokumentációjából származnak:
| Hely | Beállítás | Alapértelmezés a dokumentáció szerint | Túllépéskor |
|---|---|---|---|
| Nginx | client_max_body_size |
1m | 413-as hiba a böngészőnek |
| Apache 2.4.54-től | LimitRequestBody |
1 GiB (2.4.53-ig: korlátlan) | hibaválasz feldolgozás helyett |
| PHP | post_max_size |
8M | a $_POST és a $_FILES üres |
| PHP | upload_max_filesize |
2M | a fájlt hibakóddal elutasítják |
| PHP | max_file_uploads |
20 | a további fájlokat figyelmen kívül hagyják |
| PHP | max_input_vars |
1000 | a további űrlapmezők hiányoznak |
Ebből egy egyszerű szabály adódik: az upload_max_filesize kisebb legyen a post_max_size-nál, a post_max_size kisebb a webszerver határánál. A PHP kézikönyve ezenkívül azt javasolja, hogy a memory_limit általában nagyobb legyen a post_max_size-nál. A memory_limit=-1 PHP2Shell-átmeneti intézkedés idején ezt a szerepet a konténeren vagy cgroupon keresztüli határ veszi át; bővebben a memory_limit helyes beállítása cikkben.
post_max_size a PHP2Shell után: mit javasol a php.net
A 2026. 10. 21-i biztonsági közleményben a php.net a frissítés nélküli szerverekre az alacsony kérésméret-határokat nevezi meg átmeneti intézkedések egyikeként. Csökkentik az egyes támadási utak kockázatát, de kifejezetten nem teljes védelem:
- Fájlfeltöltés nélkül:
post_max_size = 8M. - Fájlfeltöltésekkel:
post_max_size = 32M. - Mindkét esetben: az
upload_max_filesizeapost_max_sizealatt maradjon. - Ezenkívül megfontolandó: határok a webszerverben vagy proxyban a dekódolt kérésméretre, a beviteli mezők számára, a multipart-részek számára, a fejlécsorok számára és a beágyazási mélységre. A php.net szerint ezeknek a határoknak az érvényes
Content-Lengthmegadás nélküli kéréseket is le kell fedniük.
Az értékek oda valók, ahol az alkalmazások nem írhatják felül őket. Mivel a post_max_size és az upload_max_filesize a kézikönyv szerint könyvtárszinten módosítható, egy .user.ini vagy mod_php esetén egy .htaccess különben újra megemelhetné őket:
; A weboldal FPM-poolja, feltöltésekkel (átmenet a frissítésig)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
A webszerverben a határt kissé fölé húzza, hogy a túl nagy kérések el se jussanak a PHP-hoz:
# Nginx, a server- vagy location-blokkban
client_max_body_size 32m;
# Apache, a VirtualHostban: 32 MiB bájtban
LimitRequestBody 33554432
Ezután töltse újra az összes PHP-workert és a webszervert. Az összes átmeneti intézkedés áttekintése az Azonnali intézkedések, ha még nem tud javítani oldalon található. Hogy a feltöltési kérések ezenfelül szűrhetők-e a proxyn, és hogyan, azt a Feltöltési kérések szűrése a peremen világítja meg.
Minden módosítás után tesztelje az űrlapokat a legnagyobb jogos kérésekkel: több melléklettel rendelkező jelentkezésekkel, termékimportokkal, képgalériákkal. Egy túl szűk érték megbénítja az üzleti folyamatokat anélkül, hogy bárki hibaüzenetet látna.
A weboldalához illő érték meghatározása
Az általános értékek helyett megéri egy rövid állapotfelmérés. Sorolja fel az összes feltöltéses űrlapot, és jegyezze fel a legnagyobb jogos fájlt és az egyidejű fájlok legmagasabb számát. Ebből adódik az igény: az upload_max_filesize a legnagyobb egyedi fájlt fedi le, a post_max_size egy kérés összes fájljának összegét plusz némi tartalékot az űrlapmezőknek.
Ha az igény 32M fölött van, nem illik a php.net átmeneti javaslatához. Ez újabb ok a frissítés előrehozására. A nagy feltöltések saját aldomainen, saját poolon keresztül is lebonyolíthatók, hogy a többi weboldal szűk határokat tartson meg.
A 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy egy megerősített backport frissítése után az értékeket ismét a tényleges igényhez igazíthatja. A szükségesnél nagyvonalúbbak mégsem legyenek: minden, az igényt meghaladó határ haszon nélkül növeli a támadási felületet. Ha egy weboldalnak egyáltalán nincs szüksége feltöltésekre, a file_uploads = Off a legtisztább megoldás.
A hibaképek helyes értelmezése
Ha a feltöltések meghiúsulnak, a viselkedés elárulja, melyik határ hat. A 413-as hibát mutató oldal a webszervertől származik. Egy űrlap, amely üzenet nélkül újratöltődik, vagy „érvénytelen kérést” jelez, üres $_POST-adatokra, tehát a post_max_size-ra utal. Az alkalmazás egyetlen fájlra vonatkozó üzenete az upload_max_filesize-hoz illik. A nagyon nagy űrlapokban hiányzó mezők, például terméklehetőségeknél, a max_input_vars mellett szólnak. A PHP hibanaplója túllépett post_max_size esetén általában figyelmeztetést tartalmaz a kérés méretével.
Hogy a felhasználók ne maradjanak tanácstalanul, az alkalmazásnak fel kell ismernie az esetet. A PHP kézikönyve erre egy egyszerű utat javasol: az űrlap egy jelölőt ad át a címben, például ?processed=1. Ha ez a jelölő megérkezik, de a $_POST és a $_FILES üres, a kérés túl nagy volt, és az alkalmazás érthető üzenetet jeleníthet meg a megengedett mérettel.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a weboldalai összes feltöltési útját, és megállapítjuk a ténylegesen szükséges méreteket.
- A webszerver-, PHP- és poolhatárokat egymással összhangban és a felülírás ellen zárolva állítjuk be, a php.net átmeneti értékeivel együtt.
- Az átállás után teszteljük az űrlapokat, importokat és feltöltéseket, és célzottan igazítjuk az értékeket.
- A szerverkeményítés keretében a frissítés után visszavezetjük az értékeket a tartós igényre.
Gyakori kérdések
Mi a különbség a post_max_size és az upload_max_filesize között?
Az upload_max_filesize egyetlen feltöltött fájl méretét korlátozza. A post_max_size egy POST-kérés teljes adatmennyiségét korlátozza, vagyis az összes fájlt és űrlapmezőt együtt. A PHP kézikönyve szerint a post_max_size-nak ezért nagyobbnak kell lennie az upload_max_filesize-nál.
Mi történik, ha egy kérés nagyobb a post_max_size-nál?
A PHP kézikönyve szerint ekkor a $_POST és a $_FILES üres. Az alkalmazás tehát egyáltalán nem kap űrlapadatokat, és gyakran csak egy érthetetlen hibaüzenetet jelenít meg, vagy újratölti az űrlapot. Ettől nehéz felismerni ezt a hibát.
Milyen értékeket javasol a php.net a PHP2Shell miatt?
A frissítésig tartó átmeneti intézkedésként: post_max_size = 8M fájlfeltöltés nélküli alkalmazásokhoz, 32M feltöltéses alkalmazásokhoz, az upload_max_filesize pedig ez alatt. A php.net szerint ez nem teljes védelem; csak a javított PHP-verzióra való frissítés zárja le a réseket.
Módosíthatom a post_max_size-t az ini_set()-tel a kódban?
Nem. A PHP kézikönyve szerint a post_max_size csak könyvtárszinten módosítható, például a php.ini-ben, az FPM-poolban, a .user.ini-ben vagy mod_php esetén a .htaccess-ben. Aki az értéket ki akarja kényszeríteni, a php_admin_value-val állítja be, így egy .user.ini sem írhatja felül.