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; lataustoimintojen turvallisen ohjelmoinnin kuvaa Tiedostolatausten turvallinen toteutus PHP:ssä.
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.
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:
- Ilman tiedostolatauksia:
post_max_size = 8M. - Tiedostolatausten kanssa:
post_max_size = 32M. - Molemmissa tapauksissa: pitäkää
upload_max_filesizearvonpost_max_sizealapuolella. - 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:
; 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, server- tai location-lohkossa
client_max_body_size 32m;
# 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ää. Voiko ja miten upload-pyyntöjä suodatetaan lisäksi välityspalvelimella, valottaa Upload-pyyntöjen suodatus reunalla.
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 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ä.