# A post_max_size és az upload_max_filesize értelmes korlátozása

> A post_max_size és az upload_max_filesize korlátozása: összhang a webszerver határaival, a php.net átmeneti értékei a PHP2Shellhez, tipikus hibaképek.

Forrás: https://phpsos.de/hu/blog/post-max-size-upload-limits/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php/datei-uploads-intern/) 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](https://phpsos.de/hu/ratgeber/datei-upload-sicher/) í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](https://phpsos.de/hu/blog/memory-limit-richtig-setzen/) 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:

1. **Fájlfeltöltés nélkül:** `post_max_size = 8M`.
2. **Fájlfeltöltésekkel:** `post_max_size = 32M`.
3. **Mindkét esetben:** az `upload_max_filesize` a `post_max_size` alatt maradjon.
4. **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-Length` megadá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:

```ini
; 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
# Nginx, a server- vagy location-blokkban
client_max_body_size 32m;
```

```apache
# 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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) 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](https://phpsos.de/hu/blog/upload-anfragen-am-rand-filtern/) világítja meg.

> **Fontos:**
> 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](https://phpsos.de/hu/leistungen/server-haertung/) 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.

## Források

- [php.net: 2026. 10. 21-i biztonsági közlemény](https://www.php.net/)
- [PHP kézikönyv: alapbeállítások (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Nginx dokumentáció: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache dokumentáció: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)