# Begræns post_max_size og upload_max_filesize fornuftigt

> Begræns post_max_size og upload_max_filesize: samspillet med webserverens grænser, overgangsværdier fra php.net til PHP2Shell og typiske fejlbilleder.

Kilde: https://phpsos.de/da/blog/post-max-size-upload-limits/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** `post_max_size` begrænser den samlede størrelse af en POST-forespørgsel, `upload_max_filesize` den enkelte fil; standarderne er ifølge PHP-manualen 8M og 2M. Værdierne skal passe til grænserne i webserveren og i applikationen, ellers mislykkes uploads uden tydelig meddelelse. Indtil PHP2Shell-opdateringen råder php.net til `post_max_size = 8M` uden uploads eller `32M` med uploads, `upload_max_filesize` derunder, sat så applikationer ikke overskriver det.

## Når ansøgningsformularen pludselig tier

Efter overgangsforanstaltningerne til PHP2Shell har mange administratorer sænket `post_max_size`. Få dage senere melder personaleafdelingen, at ansøgninger ikke længere kommer frem. Formularen genindlæser bare, en fejlmeddelelse er der ikke. Årsagen: Forespørgslen med tre PDF-bilag var større end den nye grænse, og PHP har kasseret formulardataene.

Eksemplet viser grundproblemet. Upload-grænser virker flere steder samtidig, og hvert sted reagerer forskelligt, når det overskrides. Den, der kender kæden, kan sætte værdierne, så de beskytter uden at forstyrre driften. Hvordan PHP behandler uploads internt, forklarer [Sådan behandler PHP filuploads](https://phpsos.de/da/php/datei-uploads-intern/); den sikre programmering af upload-funktioner beskriver [Gennemfør filuploads i PHP sikkert](https://phpsos.de/da/ratgeber/datei-upload-sicher/).

## Kæden af upload-grænser

En forespørgsel passerer flere grænser, før applikationen ser den. Oplysningerne nedenfor stammer fra dokumentationen til Nginx, Apache og PHP:

| Sted | Indstilling | Standard ifølge dok. | Ved overskridelse |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | fejl 413 til browseren |
| Apache fra 2.4.54 | `LimitRequestBody` | 1 GiB (til 2.4.53: ubegrænset) | fejlsvar i stedet for behandling |
| PHP | `post_max_size` | 8M | `$_POST` og `$_FILES` tomme |
| PHP | `upload_max_filesize` | 2M | filen afvises med fejlkode |
| PHP | `max_file_uploads` | 20 | yderligere filer ignoreres |
| PHP | `max_input_vars` | 1000 | yderligere formularfelter mangler |

Heraf følger en enkel regel: `upload_max_filesize` mindre end `post_max_size`, `post_max_size` mindre end grænsen i webserveren. PHP-manualen anbefaler desuden, at `memory_limit` generelt er større end `post_max_size`. Under PHP2Shell-overgangsforanstaltningen med `memory_limit=-1` overtager grænsen via container eller cgroup den rolle; mere herom under [Sæt memory_limit rigtigt](https://phpsos.de/da/blog/memory-limit-richtig-setzen/).

## post_max_size efter PHP2Shell: hvad php.net råder til

I sikkerhedsmeddelelsen af 21.10.2026 nævner php.net for servere uden opdatering lave forespørgselsgrænser som en af overgangsforanstaltningerne. De mindsker risikoen ved enkelte angrebsveje, men er udtrykkeligt ingen fuldstændig beskyttelse:

1. **Uden filuploads:** `post_max_size = 8M`.
2. **Med filuploads:** `post_max_size = 32M`.
3. **I begge tilfælde:** Hold `upload_max_filesize` under `post_max_size`.
4. **Overvej desuden:** Grænser i webserveren eller proxyen for den afkodede forespørgselsstørrelse, antallet af inputfelter, antallet af multipart-dele, antallet af headerlinjer og indlejringsdybden. Ifølge php.net skal disse grænser også omfatte forespørgsler uden anvendelig `Content-Length`-angivelse.

Værdierne hører hjemme dér, hvor applikationer ikke kan overskrive dem. Fordi `post_max_size` og `upload_max_filesize` ifølge manualen kan ændres på mappeniveau, kunne en `.user.ini` eller ved mod_php en `.htaccess` ellers hæve dem igen:

```ini
; Websitets FPM-pool, med uploads (overgang indtil opdateringen)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

I webserveren trækker I grænsen lige over, så for store forespørgsler slet ikke når frem til PHP:

```nginx
# Nginx, i server- eller location-blokken
client_max_body_size 32m;
```

```apache
# Apache, i VirtualHost: 32 MiB i bytes
LimitRequestBody 33554432
```

Genindlæs derefter alle PHP-workers og webserveren. Oversigten over alle overgangsforanstaltninger står under [Akutforanstaltninger, hvis I endnu ikke kan patche](https://phpsos.de/da/php2shell/sofortmassnahmen-ohne-patch/). Om og hvordan upload-forespørgsler desuden kan filtreres ved proxyen, belyser [Filtrér upload-forespørgsler i kanten](https://phpsos.de/da/blog/upload-anfragen-am-rand-filtern/).

> **Vigtigt:**
> Test efter hver ændring formularerne med de største legitime forespørgsler: ansøgninger med flere bilag, produktimporter, billedgallerier. En for snæver værdi lammer forretningsprocesser, uden at nogen ser en fejlmeddelelse.

## Find den rigtige værdi til jeres website

I stedet for generelle værdier er en kort beholdningsopgørelse umagen værd. Opregn alle formularer med uploads, og notér den største legitime fil og det højeste antal samtidige filer. Heraf fremgår behovet: `upload_max_filesize` dækker den største enkeltfil, `post_max_size` summen af alle filer i en forespørgsel plus lidt reserve til formularfelter.

Ligger behovet over 32M, passer det ikke til php.nets overgangsanbefaling. Så er det endnu en grund til at fremskynde opdateringen. Store uploads kan også afvikles via et eget subdomæne med egen pool, så det øvrige website beholder snævre grænser.

Efter opdateringen til 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekræftet backport kan I igen rette værdierne efter det faktiske behov. Rundhåndere end nødvendigt bør de alligevel ikke være: Hver grænse, der går ud over behovet, forøger angrebsfladen uden nytte. Har et website slet ikke brug for uploads, er `file_uploads = Off` den reneste løsning.

## Tolk fejlbilleder rigtigt

Når uploads mislykkes, afslører adfærden, hvilken grænse der virker. En side med fejl 413 stammer fra webserveren. En formular, der genindlæser uden meddelelse eller melder "ugyldig forespørgsel", peger på tomme `$_POST`-data, altså `post_max_size`. En meddelelse fra applikationen om en enkelt fil passer til `upload_max_filesize`. Og manglende felter i meget store formularer, f.eks. ved produktvarianter, taler for `max_input_vars`. PHP-fejllogget indeholder ved overskredet `post_max_size` som regel en advarsel med forespørgslens størrelse.

For at brugerne ikke står rådvilde tilbage, bør applikationen genkende tilfældet. PHP-manualen foreslår en enkel vej: Formularen overfører en markør i adressen, f.eks. `?processed=1`. Kommer markøren frem, men `$_POST` og `$_FILES` er tomme, var forespørgslen for stor, og applikationen kan vise en forståelig meddelelse med den tilladte størrelse.

## Hvordan hjælper PHP SOS konkret?

- Vi registrerer alle upload-veje på jeres websites og finder ud af de faktisk nødvendige størrelser.
- Vi sætter webserver-, PHP- og poolgrænser konsistent og låst mod overskrivning, inklusive php.nets overgangsværdier.
- Vi tester formularer, importer og uploads efter omstillingen og tilpasser værdier målrettet.
- Inden for rammerne af [serverhærdningen](https://phpsos.de/da/leistungen/server-haertung/) fører vi værdierne efter opdateringen tilbage til det varige behov.


## Ofte stillede spørgsmål

**Hvad er forskellen på post_max_size og upload_max_filesize?**  
upload_max_filesize begrænser størrelsen på en enkelt uploadet fil. post_max_size begrænser de samlede data i en POST-forespørgsel, altså alle filer og formularfelter tilsammen. Ifølge PHP-manualen skal post_max_size derfor være større end upload_max_filesize.

**Hvad sker der, hvis en forespørgsel er større end post_max_size?**  
Ifølge PHP-manualen er $_POST og $_FILES så tomme. Applikationen modtager altså slet ingen formulardata og viser ofte kun en uklar fejlmeddelelse eller genindlæser formularen. Det gør fejlen svær at genkende.

**Hvilke værdier anbefaler php.net på grund af PHP2Shell?**  
Som overgangsforanstaltning indtil opdateringen: post_max_size = 8M for applikationer uden filuploads, 32M for applikationer med uploads, og upload_max_filesize derunder. Det er ifølge php.net ingen fuldstændig beskyttelse; kun opdateringen til en rettet PHP-version lukker sårbarhederne.

**Kan jeg ændre post_max_size med ini_set() i koden?**  
Nej. Ifølge PHP-manualen kan post_max_size kun ændres på mappeniveau, f.eks. i php.ini, i FPM-poolen, i .user.ini eller ved mod_php i .htaccess. Den, der vil gennemtvinge værdien, sætter den med php_admin_value, så kan heller ikke en .user.ini overskrive den.

## Kilder

- [php.net: Sikkerhedsmeddelelse af 21.10.2026](https://www.php.net/)
- [PHP-manual: Kerneindstillinger (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)