# Begränsa post_max_size och upload_max_filesize förnuftigt

> Begränsa post_max_size och upload_max_filesize: samspelet med webbserverns gränser, php.nets övergångsvärden för PHP2Shell och typiska felbilder.

Källa: https://phpsos.de/sv/blog/post-max-size-upload-limits/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**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](https://phpsos.de/sv/php/datei-uploads-intern/); säker programmering av uppladdningsfunktioner beskriver [Implementera filuppladdningar i PHP säkert](https://phpsos.de/sv/ratgeber/datei-upload-sicher/).

## 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](https://phpsos.de/sv/blog/memory-limit-richtig-setzen/).

## 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:

1. **Utan filuppladdningar:** `post_max_size = 8M`.
2. **Med filuppladdningar:** `post_max_size = 32M`.
3. **I båda fallen:** håll `upload_max_filesize` under `post_max_size`.
4. **Ö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:

```ini
; 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
# Nginx, i server- eller location-blocket
client_max_body_size 32m;
```

```apache
# 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](https://phpsos.de/sv/php2shell/sofortmassnahmen-ohne-patch/). Om och hur uppladdningsförfrågningar dessutom kan filtreras i proxyn belyser [Filtrera uppladdningsförfrågningar i kanten](https://phpsos.de/sv/blog/upload-anfragen-am-rand-filtern/).

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

## Källor

- [php.net: säkerhetsmeddelande från 21.10.2026](https://www.php.net/)
- [PHP-manualen: kärninställningar (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Nginx-dokumentation: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache-dokumentation: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)