Kort sagt: post_max_size begränsar den samlade storleken på en POST-förfrågan, upload_max_filesize den enskilda filen; standard är enligt PHP-manualen 8M respektive 2M. Värdena måste passa gränserna i webbservern och i applikationen, annars misslyckas uppladdningar utan tydligt meddelande. Fram till PHP2Shell-uppdateringen rekommenderar php.net post_max_size = 8M utan uppladdningar eller 32M med uppladdningar, upload_max_filesize under det, satt så att applikationer inte skriver över det.
När ansökningsformuläret plötsligt tystnar
Efter övergångsåtgärderna för PHP2Shell har många administratörer sänkt post_max_size. Några dagar senare rapporterar personalavdelningen att ansökningar inte längre kommer fram. Formuläret laddar bara om, något felmeddelande finns inte. Orsaken: förfrågan med tre PDF-bilagor var större än den nya gränsen, och PHP har kastat formulärdata.
Exemplet visar grundproblemet. Uppladdningsgränser verkar på flera ställen samtidigt, och varje ställe reagerar olika när den överskrids. Den som känner kedjan kan sätta värdena så att de skyddar utan att störa driften. Hur PHP hanterar uppladdningar internt förklarar Hur PHP hanterar filuppladdningar; säker programmering av uppladdningsfunktioner beskriver Implementera filuppladdningar i PHP säkert.
Kedjan av uppladdningsgränser
En förfrågan passerar flera gränser innan applikationen ser den. Uppgifterna nedan kommer från dokumentationen för Nginx, Apache och PHP:
| Ställe | Inställning | Standard enligt dok. | Vid överskridande |
|---|---|---|---|
| Nginx | client_max_body_size |
1m | Fel 413 till webbläsaren |
| Apache från 2.4.54 | LimitRequestBody |
1 GiB (till 2.4.53: obegränsat) | Felsvar i stället för bearbetning |
| PHP | post_max_size |
8M | $_POST och $_FILES tomma |
| PHP | upload_max_filesize |
2M | Filen avvisas med felkod |
| PHP | max_file_uploads |
20 | ytterligare filer ignoreras |
| PHP | max_input_vars |
1000 | ytterligare formulärfält saknas |
Därav följer en enkel regel: upload_max_filesize mindre än post_max_size, post_max_size mindre än gränsen i webbservern. PHP-manualen rekommenderar dessutom att memory_limit i allmänhet är större än post_max_size. Under PHP2Shell-övergångsåtgärden med memory_limit=-1 tar gränsen via container eller cgroup över den rollen; mer om det under Ställ in memory_limit rätt.
post_max_size efter PHP2Shell: vad php.net rekommenderar
I säkerhetsmeddelandet från 21.10.2026 nämner php.net låga förfrågningsgränser som en av övergångsåtgärderna för servrar utan uppdatering. De minskar risken för enskilda angreppsvägar men är uttryckligen inget fullständigt skydd:
- Utan filuppladdningar:
post_max_size = 8M. - Med filuppladdningar:
post_max_size = 32M. - I båda fallen: håll
upload_max_filesizeunderpost_max_size. - Överväg dessutom: gränser i webbservern eller proxyn för den avkodade förfrågningsstorleken, antalet inmatningsfält, antalet multipart-delar, antalet huvudrader och nästlingsdjupet. Enligt php.net måste dessa gränser också fånga förfrågningar utan användbar
Content-Length-uppgift.
Värdena hör hemma där applikationer inte kan skriva över dem. Eftersom post_max_size och upload_max_filesize enligt manualen kan ändras på katalognivå skulle en .user.ini eller, vid mod_php, en .htaccess annars kunna höja dem igen:
; FPM-pool för webbplatsen, med uppladdningar (övergång fram till uppdateringen)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
I webbservern drar ni gränsen strax ovanför, så att för stora förfrågningar inte ens når PHP:
# Nginx, i server- eller location-blocket
client_max_body_size 32m;
# Apache, i VirtualHost: 32 MiB i byte
LimitRequestBody 33554432
Ladda därefter om alla PHP-workers och webbservern. Översikten över alla övergångsåtgärder finns under Akuta åtgärder när ni ännu inte kan patcha. Om och hur uppladdningsförfrågningar dessutom kan filtreras i proxyn belyser Filtrera uppladdningsförfrågningar i kanten.
Testa efter varje ändring formulären med de största legitima förfrågningarna: ansökningar med flera bilagor, produktimporter, bildgallerier. Ett för snävt värde lamslår affärsprocesser utan att någon ser ett felmeddelande.
Ta reda på rätt värde för er webbplats
I stället för generella värden lönar sig en kort inventering. Lista alla formulär med uppladdningar och anteckna den största legitima filen och det högsta antalet samtidiga filer. Därav framgår behovet: upload_max_filesize täcker den största enskilda filen, post_max_size summan av alla filer i en förfrågan plus lite reserv för formulärfält.
Ligger behovet över 32M passar det inte med php.nets övergångsrekommendation. Då är det ytterligare ett skäl att tidigarelägga uppdateringen. Stora uppladdningar kan också hanteras via en egen underdomän med egen pool, så att resten av webbplatsen behåller snäva gränser.
Efter uppdateringen till 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekräftad backport kan ni åter rikta värdena mot det faktiska behovet. Mer generösa än nödvändigt bör de ändå inte vara: varje gräns som går utöver behovet förstorar angreppsytan utan nytta. Behöver en webbplats inga uppladdningar alls är file_uploads = Off den renaste lösningen.
Tolka felbilderna rätt
När uppladdningar misslyckas avslöjar beteendet vilken gräns som slår till. En sida med fel 413 kommer från webbservern. Ett formulär som laddar om utan meddelande eller rapporterar ”ogiltig förfrågan” tyder på tomma $_POST-data, alltså post_max_size. Ett meddelande från applikationen om en enskild fil passar upload_max_filesize. Och saknade fält i mycket stora formulär, till exempel vid produktvarianter, talar för max_input_vars. PHP-felloggen innehåller vid överskriden post_max_size i regel en varning med förfrågans storlek.
För att användare inte ska lämnas ratlösa bör applikationen känna igen fallet. PHP-manualen föreslår en enkel väg: formuläret skickar med en markör i adressen, till exempel ?processed=1. Kommer markören fram men $_POST och $_FILES är tomma var förfrågan för stor, och applikationen kan visa ett begripligt meddelande med den tillåtna storleken.
Hur hjälper PHP SOS konkret?
- Vi kartlägger alla uppladdningsvägar på era webbplatser och tar reda på de faktiskt nödvändiga storlekarna.
- Vi sätter gränser i webbserver, PHP och pool samstämmigt och spärrade mot överskrivning, inklusive php.nets övergångsvärden.
- Vi testar formulär, importer och uppladdningar efter omställningen och justerar värden riktat.
- Inom ramen för serverhärdningen för vi efter uppdateringen tillbaka värdena till det varaktiga behovet.
Vanliga frågor
Vad är skillnaden mellan post_max_size och upload_max_filesize?
upload_max_filesize begränsar storleken på en enskild uppladdad fil. post_max_size begränsar hela datamängden i en POST-förfrågan, alltså alla filer och formulärfält tillsammans. Enligt PHP-manualen måste post_max_size därför vara större än upload_max_filesize.
Vad händer om en förfrågan är större än post_max_size?
Enligt PHP-manualen är då $_POST och $_FILES tomma. Applikationen får alltså inga formulärdata alls och visar ofta bara ett oklart felmeddelande eller laddar om formuläret. Det gör felet svårt att känna igen.
Vilka värden rekommenderar php.net på grund av PHP2Shell?
Som övergångsåtgärd fram till uppdateringen: post_max_size = 8M för applikationer utan filuppladdningar, 32M för applikationer med uppladdningar, och upload_max_filesize under det. Det är enligt php.net inget fullständigt skydd; bara uppdateringen till en rättad PHP-version stänger sårbarheterna.
Kan jag ändra post_max_size med ini_set() i koden?
Nej. Enligt PHP-manualen kan post_max_size bara ändras på katalognivå, till exempel i php.ini, i FPM-poolen, i .user.ini eller vid mod_php i .htaccess. Den som vill tvinga fram värdet sätter det med php_admin_value, då kan inte heller en .user.ini skriva över det.