# post_max_size- ja upload_max_filesize-rajojen järkevä asettaminen

> post_max_size ja upload_max_filesize: yhteispeli verkkopalvelimen rajojen kanssa, php.netin siirtymäarvot PHP2Shellille ja tyypilliset virhetilanteet.

Lähde: https://phpsos.de/fi/blog/post-max-size-upload-limits/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** `post_max_size` rajaa POST-pyynnön koko koon, `upload_max_filesize` yksittäisen tiedoston; oletukset ovat PHP-käsikirjan mukaan 8M ja 2M. Arvojen on sovittava yhteen verkkopalvelimen ja sovelluksen rajojen kanssa, muuten lataukset epäonnistuvat ilman selkeää ilmoitusta. PHP2Shell-päivitykseen asti php.net suosittelee arvoa `post_max_size = 8M` ilman latauksia tai `32M` latausten kanssa, `upload_max_filesize` niitä pienempänä, asetettuna niin, etteivät sovellukset voi ylikirjoittaa sitä.

## Kun hakulomake yhtäkkiä vaikenee

PHP2Shellin siirtymäajan toimenpiteiden jälkeen moni ylläpitäjä laski `post_max_size`-arvoa. Muutamaa päivää myöhemmin henkilöstöosasto ilmoittaa, ettei hakemuksia enää tule perille. Lomake latautuu vain uudelleen, virheilmoitusta ei ole. Syy: pyyntö kolmine PDF-liitteineen oli suurempi kuin uusi raja, ja PHP hylkäsi lomaketiedot.

Esimerkki näyttää perusongelman. Upload-rajat vaikuttavat useassa kohdassa yhtä aikaa, ja jokainen kohta reagoi ylitykseen eri tavalla. Joka tuntee ketjun, voi asettaa arvot niin, että ne suojaavat häiritsemättä toimintaa. Miten PHP käsittelee latauksia sisäisesti, selittää [Miten PHP käsittelee tiedostolataukset](https://phpsos.de/fi/php/datei-uploads-intern/); lataustoimintojen turvallisen ohjelmoinnin kuvaa [Tiedostolatausten turvallinen toteutus PHP:ssä](https://phpsos.de/fi/ratgeber/datei-upload-sicher/).

## Upload-rajojen ketju

Pyyntö läpäisee useita rajoja ennen kuin sovellus näkee sen. Seuraavat tiedot ovat peräisin Nginxin, Apachen ja PHP:n dokumentaatioista:

| Kohta | Asetus | Oletus dokumentaation mukaan | Ylityksessä |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | virhe 413 selaimelle |
| Apache versiosta 2.4.54 | `LimitRequestBody` | 1 GiB (versioon 2.4.53 asti: rajoittamaton) | virhevastaus käsittelyn sijaan |
| PHP | `post_max_size` | 8M | `$_POST` ja `$_FILES` tyhjiä |
| PHP | `upload_max_filesize` | 2M | tiedosto hylätään virhekoodilla |
| PHP | `max_file_uploads` | 20 | muut tiedostot ohitetaan |
| PHP | `max_input_vars` | 1000 | muut lomakekentät puuttuvat |

Tästä seuraa yksinkertainen sääntö: `upload_max_filesize` pienempi kuin `post_max_size`, `post_max_size` pienempi kuin verkkopalvelimen raja. PHP-käsikirja suosittelee lisäksi, että `memory_limit` on yleensä suurempi kuin `post_max_size`. PHP2Shellin siirtymäajan toimenpiteessä arvolla `memory_limit=-1` tämän roolin ottaa kontin tai cgroupin kautta asetettu raja; lisää kohdassa [memory_limit-asetuksen määrittäminen oikein](https://phpsos.de/fi/blog/memory-limit-richtig-setzen/).

## post_max_size PHP2Shellin jälkeen: mitä php.net suosittelee

21.10.2026 päivätyssä tietoturvailmoituksessa php.net nimeää päivittämättömille palvelimille matalat pyyntörajat yhdeksi siirtymäajan toimenpiteeksi. Ne pienentävät yksittäisten hyökkäysreittien riskiä, mutta eivät nimenomaisesti ole täydellinen suoja:

1. **Ilman tiedostolatauksia:** `post_max_size = 8M`.
2. **Tiedostolatausten kanssa:** `post_max_size = 32M`.
3. **Molemmissa tapauksissa:** pitäkää `upload_max_filesize` arvon `post_max_size` alapuolella.
4. **Lisäksi harkittavaksi:** verkkopalvelimen tai välityspalvelimen rajat dekoodatulle pyynnön koolle, syöttökenttien määrälle, multipart-osien määrälle, otsikkorivien määrälle ja sisäkkäisyyden syvyydelle. php.net:n mukaan näiden rajojen on katettava myös pyynnöt, joilla ei ole käyttökelpoista `Content-Length`-tietoa.

Arvojen kuuluu olla siellä, missä sovellukset eivät voi ylikirjoittaa niitä. Koska `post_max_size` ja `upload_max_filesize` ovat käsikirjan mukaan muutettavissa hakemistotasolla, `.user.ini` tai mod_php:n kanssa `.htaccess` voisi muuten nostaa ne takaisin:

```ini
; Verkkosivuston FPM-pooli, latausten kanssa (siirtymäaika päivitykseen asti)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

Verkkopalvelimessa asetatte rajan hieman ylemmäs, jotta liian suuret pyynnöt eivät pääse PHP:lle asti:

```nginx
# Nginx, server- tai location-lohkossa
client_max_body_size 32m;
```

```apache
# Apache, VirtualHostissa: 32 MiB tavuina
LimitRequestBody 33554432
```

Sen jälkeen ladatkaa kaikki PHP-workerit ja verkkopalvelin uudelleen. Kaikkien siirtymäajan toimenpiteiden yleiskatsaus on kohdassa [Pikatoimet, jos ette voi vielä päivittää](https://phpsos.de/fi/php2shell/sofortmassnahmen-ohne-patch/). Voiko ja miten upload-pyyntöjä suodatetaan lisäksi välityspalvelimella, valottaa [Upload-pyyntöjen suodatus reunalla](https://phpsos.de/fi/blog/upload-anfragen-am-rand-filtern/).

> **Tärkeää:**
> Testatkaa jokaisen muutoksen jälkeen lomakkeet suurimmilla oikeutetuilla pyynnöillä: hakemukset useine liitteineen, tuotetuonnit, kuvagalleriat. Liian niukka arvo lamauttaa liiketoimintaprosesseja ilman, että kukaan näkee virheilmoitusta.

## Oikean arvon määrittäminen verkkosivustollenne

Yleisten arvojen sijaan kannattaa tehdä lyhyt inventaario. Luetteloikaa kaikki lomakkeet, joissa on latauksia, ja kirjatkaa suurin oikeutettu tiedosto ja suurin yhtäaikaisten tiedostojen määrä. Tästä saadaan tarve: `upload_max_filesize` kattaa suurimman yksittäisen tiedoston, `post_max_size` pyynnön kaikkien tiedostojen summan ja hieman varaa lomakekentille.

Jos tarve on yli 32M, se ei sovi php.net:n siirtymäsuositukseen. Se on silloin toinen syy aikaistaa päivitystä. Suuret lataukset voi hoitaa myös omalla aliverkkotunnuksella ja omalla poolilla, jotta muu verkkosivusto säilyttää tiukat rajat.

Päivityksen jälkeen versioihin 8.5.12, 8.4.27, 8.3.36, 8.2.35 tai vahvistettuun backportiin voitte taas sovittaa arvot todelliseen tarpeeseen. Anteliaampia kuin tarpeen niiden ei silti pitäisi olla: jokainen tarvetta suurempi raja kasvattaa hyökkäyspinta-alaa ilman hyötyä. Jos verkkosivusto ei tarvitse latauksia lainkaan, `file_uploads = Off` on puhtain ratkaisu.

## Virhetilanteiden oikea tulkinta

Kun lataukset epäonnistuvat, käyttäytyminen paljastaa, mikä raja on voimassa. Sivu virheellä 413 tulee verkkopalvelimelta. Lomake, joka latautuu uudelleen ilman ilmoitusta tai ilmoittaa ”virheellinen pyyntö”, viittaa tyhjiin `$_POST`-tietoihin, eli `post_max_size`-arvoon. Sovelluksen ilmoitus yksittäisestä tiedostosta sopii arvoon `upload_max_filesize`. Ja puuttuvat kentät hyvin suurissa lomakkeissa, esimerkiksi tuotevariaateissa, viittaavat arvoon `max_input_vars`. PHP:n virheloki sisältää ylitetyn `post_max_size`-rajan yhteydessä yleensä varoituksen pyynnön koosta.

Jotta käyttäjät eivät jää ymmälleen, sovelluksen pitäisi tunnistaa tapaus. PHP-käsikirja ehdottaa siihen yksinkertaista tapaa: lomake välittää osoitteessa merkin, esimerkiksi `?processed=1`. Jos merkki saapuu mutta `$_POST` ja `$_FILES` ovat tyhjiä, pyyntö oli liian suuri, ja sovellus voi näyttää ymmärrettävän ilmoituksen sallitusta koosta.

## Miten PHP SOS auttaa konkreettisesti?

- Kartoitamme verkkosivustojenne kaikki latausreitit ja selvitämme todella tarvittavat koot.
- Asetamme verkkopalvelimen, PHP:n ja poolin rajat yhteensopiviksi ja ylikirjoitukselta lukituiksi, php.net:n siirtymäarvot mukaan lukien.
- Testaamme lomakkeet, tuonnit ja lataukset muutoksen jälkeen ja mukautamme arvoja kohdennetusti.
- [Palvelimen koventamisen](https://phpsos.de/fi/leistungen/server-haertung/) yhteydessä palautamme arvot päivityksen jälkeen pysyvään tarpeeseen.


## Usein kysytyt kysymykset

**Mitä eroa on post_max_sizellä ja upload_max_filesizellä?**  
upload_max_filesize rajaa yksittäisen ladatun tiedoston koon. post_max_size rajaa POST-pyynnön kaikki tiedot, eli kaikki tiedostot ja lomakekentät yhteensä. PHP-käsikirjan mukaan post_max_size:n on siksi oltava suurempi kuin upload_max_filesize.

**Mitä tapahtuu, jos pyyntö on suurempi kuin post_max_size?**  
PHP-käsikirjan mukaan $_POST ja $_FILES ovat silloin tyhjiä. Sovellus ei siis saa lomaketietoja lainkaan ja näyttää usein vain epäselvän virheilmoituksen tai lataa lomakkeen uudelleen. Siksi tämä virhe on vaikea tunnistaa.

**Mitä arvoja php.net suosittelee PHP2Shellin vuoksi?**  
Siirtymäajan toimenpiteenä päivitykseen asti: post_max_size = 8M sovelluksille ilman tiedostolatauksia, 32M sovelluksille, joissa on latauksia, ja upload_max_filesize niitä pienempi. php.net:n mukaan tämä ei ole täydellinen suoja; vain päivitys korjattuun PHP-versioon sulkee aukot.

**Voinko muuttaa post_max_sizen koodissa funktiolla ini_set()?**  
Et. PHP-käsikirjan mukaan post_max_size on muutettavissa vain hakemistotasolla, esimerkiksi tiedostossa php.ini, FPM-poolissa, .user.ini-tiedostossa tai mod_php:n kanssa .htaccess-tiedostossa. Joka haluaa pakottaa arvon, asettaa sen komennolla php_admin_value, jolloin edes .user.ini ei voi ylikirjoittaa sitä.

## Lähteet

- [php.net: tietoturvailmoitus 21.10.2026](https://www.php.net/)
- [PHP-käsikirja: ydinasetukset (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Nginx-dokumentaatio: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache-dokumentaatio: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)