# post_max_size ir upload_max_filesize prasmingas ribojimas

> post_max_size ir upload_max_filesize ribojimas: sąveika su žiniatinklio serverio ribomis, php.net pereinamosios reikšmės dėl PHP2Shell ir tipinės klaidų formos.

Šaltinis: https://phpsos.de/lt/blog/post-max-size-upload-limits/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** `post_max_size` riboja visos POST užklausos dydį, `upload_max_filesize` atskirą failą; pasak PHP vadovo, numatytosios reikšmės yra 8M ir 2M. Reikšmės turi derėti su žiniatinklio serverio ir programos ribomis, kitaip įkėlimai nepavyksta be aiškaus pranešimo. Iki PHP2Shell atnaujinimo php.net pataria `post_max_size = 8M` be įkėlimų arba `32M` su įkėlimais, `upload_max_filesize` žemiau, nustatytą taip, kad programos jo neperrašytų.

## Kai paraiškos forma staiga nutyla

Po PHP2Shell pereinamųjų priemonių daugelis administratorių sumažino `post_max_size`. Po kelių dienų personalo skyrius praneša, kad paraiškos nebepasiekia. Forma tiesiog persikrauna, klaidos pranešimo nėra. Priežastis: užklausa su trimis PDF priedais buvo didesnė už naują ribą, ir PHP atmetė formos duomenis.

Pavyzdys rodo esminę problemą. Įkėlimo ribos veikia keliose vietose vienu metu, ir kiekviena vieta, jei ją viršija, reaguoja skirtingai. Kas žino grandinę, gali reikšmes nustatyti taip, kad jos saugotų netrikdydamos veiklos. Kaip PHP viduje apdoroja įkėlimus, paaiškina [Kaip PHP apdoroja failų įkėlimus](https://phpsos.de/lt/php/datei-uploads-intern/); saugų įkėlimo funkcijų programavimą aprašo [Saugus failų įkėlimas PHP](https://phpsos.de/lt/ratgeber/datei-upload-sicher/).

## Įkėlimo ribų grandinė

Užklausa kerta kelias ribas, kol programa ją pamato. Šie duomenys paimti iš Nginx, Apache ir PHP dokumentacijų:

| Vieta | Nustatymas | Numatytasis pagal dokumentaciją | Viršijus |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | 413 klaida naršyklei |
| Apache nuo 2.4.54 | `LimitRequestBody` | 1 GiB (iki 2.4.53: neribota) | klaidos atsakymas užuot apdorojus |
| PHP | `post_max_size` | 8M | `$_POST` ir `$_FILES` tušti |
| PHP | `upload_max_filesize` | 2M | failas atmetamas su klaidos kodu |
| PHP | `max_file_uploads` | 20 | kiti failai ignoruojami |
| PHP | `max_input_vars` | 1000 | trūksta kitų formos laukų |

Iš to išplaukia paprasta taisyklė: `upload_max_filesize` mažesnis už `post_max_size`, `post_max_size` mažesnis už žiniatinklio serverio ribą. PHP vadovas taip pat rekomenduoja, kad `memory_limit` apskritai būtų didesnis už `post_max_size`. PHP2Shell pereinamosios priemonės su `memory_limit=-1` metu šį vaidmenį perima riba per konteinerį ar cgroup; daugiau apie tai skyriuje [memory_limit teisingas nustatymas](https://phpsos.de/lt/blog/memory-limit-richtig-setzen/).

## post_max_size po PHP2Shell: ką pataria php.net

2026-10-21 saugumo pranešime php.net serveriams be atnaujinimo kaip vieną iš pereinamųjų priemonių nurodo žemas užklausų ribas. Jos sumažina atskirų atakos kelių riziką, bet aiškiai nėra pilna apsauga:

1. **Be failų įkėlimų:** `post_max_size = 8M`.
2. **Su failų įkėlimais:** `post_max_size = 32M`.
3. **Abiem atvejais:** `upload_max_filesize` laikyti žemiau `post_max_size`.
4. **Papildomai apsvarstyti:** žiniatinklio serverio ar tarpinio serverio (proxy) ribas dekoduotos užklausos dydžiui, įvesties laukų skaičiui, multipart dalių skaičiui, antraštės eilučių skaičiui ir įdėjimo gyliui. Pasak php.net, šios ribos turi apimti ir užklausas be pagrįsto `Content-Length` nurodymo.

Reikšmės turi būti ten, kur programos negali jų perrašyti. Kadangi `post_max_size` ir `upload_max_filesize`, pasak vadovo, keičiami katalogo lygiu, `.user.ini` arba su mod_php `.htaccess` kitaip galėtų jas vėl padidinti:

```ini
; Svetainės FPM baseinas, su įkėlimais (pereinamasis laikotarpis iki atnaujinimo)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

Žiniatinklio serveryje ribą nustatykite šiek tiek aukščiau, kad per dideli užklausos net nepasiektų PHP:

```nginx
# Nginx, server arba location bloke
client_max_body_size 32m;
```

```apache
# Apache, VirtualHost: 32 MiB baitais
LimitRequestBody 33554432
```

Po to iš naujo įkelkite visus PHP darbinius procesus (worker) ir žiniatinklio serverį. Visų pereinamųjų priemonių apžvalga pateikta skyriuje [Skubios priemonės, kai dar negalite pataisyti](https://phpsos.de/lt/php2shell/sofortmassnahmen-ohne-patch/). Ar ir kaip įkėlimo užklausas papildomai galima filtruoti tarpiniame serveryje, nagrinėja [Įkėlimo užklausų filtravimas pakraštyje](https://phpsos.de/lt/blog/upload-anfragen-am-rand-filtern/).

> **Svarbu:**
> Po kiekvieno pakeitimo išbandykite formas su didžiausiomis teisėtomis užklausomis: paraiškos su keliais priedais, produktų importai, paveikslėlių galerijos. Per siaura reikšmė paralyžiuoja verslo procesus, nors niekas nemato klaidos pranešimo.

## Tinkamos reikšmės nustatymas jūsų svetainei

Užuot taikius bendras reikšmes, verta atlikti trumpą inventorizaciją. Surašykite visas formas su įkėlimais ir užsirašykite didžiausią teisėtą failą bei didžiausią vienu metu įkeliamų failų skaičių. Iš to išplaukia poreikis: `upload_max_filesize` apima didžiausią atskirą failą, `post_max_size` visų užklausos failų sumą plius šiek tiek rezervo formos laukams.

Jei poreikis viršija 32M, jis netinka php.net pereinamajai rekomendacijai. Tada tai dar viena priežastis atnaujinimą paankstinti. Dideli įkėlimai taip pat gali būti vykdomi per atskirą subdomeną su savu baseinu, kad likusi svetainė išlaikytų siauras ribas.

Po atnaujinimo į 8.5.12, 8.4.27, 8.3.36, 8.2.35 ar patvirtintą atgalinį pataisų perkėlimą (backport) reikšmes vėl galite derinti prie tikrojo poreikio. Vis dėlto jos neturėtų būti dosnesnės nei būtina: kiekviena riba, viršijanti poreikį, didina atakos paviršių be naudos. Jei svetainei įkėlimų visai nereikia, švariausias sprendimas yra `file_uploads = Off`.

## Klaidų formų teisingas aiškinimas

Kai įkėlimai nepavyksta, elgsena išduoda, kuri riba suveikė. Puslapis su 413 klaida ateina iš žiniatinklio serverio. Forma, kuri persikrauna be pranešimo arba praneša „netinkama užklausa“, rodo tuščius `$_POST` duomenis, taigi `post_max_size`. Programos pranešimas apie atskirą failą atitinka `upload_max_filesize`. O trūkstami laukai labai didelėse formose, pavyzdžiui, produktų variantuose, kalba už `max_input_vars`. PHP klaidų žurnale viršijus `post_max_size` paprastai yra įspėjimas su užklausos dydžiu.

Kad naudotojai nelikti bejėgiai, programa turėtų atpažinti šį atvejį. PHP vadovas siūlo paprastą kelią: forma perduoda žymą adrese, pavyzdžiui, `?processed=1`. Jei žyma atkeliauja, bet `$_POST` ir `$_FILES` yra tušti, užklausa buvo per didelė, ir programa gali parodyti suprantamą pranešimą su leistinu dydžiu.

## Kaip PHP SOS padeda konkrečiai?

- Surenkame visus jūsų svetainių įkėlimo kelius ir nustatome tikrai reikalingus dydžius.
- Žiniatinklio serverio, PHP ir baseino ribas nustatome darniai ir užrakintas nuo perrašymo, įskaitant php.net pereinamąsias reikšmes.
- Po perėjimo išbandome formas, importus ir įkėlimus ir tikslingai koreguojame reikšmes.
- [Serverio sutvirtinimo](https://phpsos.de/lt/leistungen/server-haertung/) rėmuose po atnaujinimo reikšmes grąžiname prie nuolatinio poreikio.


## Dažni klausimai

**Kuo skiriasi post_max_size ir upload_max_filesize?**  
upload_max_filesize riboja vieno įkelto failo dydį. post_max_size riboja visus POST užklausos duomenis, taigi visus failus ir formos laukus kartu. Pasak PHP vadovo, todėl post_max_size turi būti didesnis už upload_max_filesize.

**Kas atsitinka, jei užklausa didesnė už post_max_size?**  
Pasak PHP vadovo, tada $_POST ir $_FILES yra tušti. Programa apskritai negauna formos duomenų ir dažnai parodo tik neaiškų klaidos pranešimą arba iš naujo įkelia formą. Dėl to šią klaidą sunku atpažinti.

**Kokias reikšmes dėl PHP2Shell rekomenduoja php.net?**  
Kaip pereinamąją priemonę iki atnaujinimo: post_max_size = 8M programoms be failų įkėlimų, 32M programoms su įkėlimais, o upload_max_filesize žemiau. Pasak php.net, tai nėra pilna apsauga; spragas uždaro tik atnaujinimas į ištaisytą PHP versiją.

**Ar galiu post_max_size keisti kode per ini_set()?**  
Ne. Pasak PHP vadovo, post_max_size keičiamas tik katalogo lygiu, pavyzdžiui, php.ini, FPM baseine, .user.ini arba su mod_php .htaccess. Kas nori reikšmę primesti, nustato ją su php_admin_value, tada jos neperrašys ir .user.ini.

## Šaltiniai

- [php.net: saugumo pranešimas, 2026-10-21](https://www.php.net/)
- [PHP vadovas: pagrindiniai nustatymai (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Nginx dokumentacija: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache dokumentacija: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)