# post_max_size und upload_max_filesize sinnvoll begrenzen

> post_max_size und upload_max_filesize begrenzen: Zusammenspiel mit Webserver-Limits, Übergangswerte von php.net zu PHP2Shell und typische Fehlerbilder.

Quelle: https://phpsos.de/blog/post-max-size-upload-limits/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** `post_max_size` begrenzt die gesamte Größe einer POST-Anfrage, `upload_max_filesize` die einzelne Datei; Standard sind laut PHP-Handbuch 8M und 2M. Die Werte müssen zu den Grenzen im Webserver und in der Anwendung passen, sonst scheitern Uploads ohne klare Meldung. Bis zum PHP2Shell-Update rät php.net zu `post_max_size = 8M` ohne Uploads oder `32M` mit Uploads, `upload_max_filesize` darunter, gesetzt so, dass Anwendungen es nicht überschreiben.

## Wenn das Bewerbungsformular plötzlich schweigt

Nach den Übergangsmaßnahmen zu PHP2Shell haben viele Admins `post_max_size` gesenkt. Wenige Tage später meldet die Personalabteilung, dass Bewerbungen nicht mehr ankommen. Das Formular lädt einfach neu, eine Fehlermeldung gibt es nicht. Der Grund: Die Anfrage mit drei PDF-Anhängen war größer als die neue Grenze, und PHP hat die Formulardaten verworfen.

Das Beispiel zeigt das Grundproblem. Upload-Grenzen wirken an mehreren Stellen gleichzeitig, und jede Stelle reagiert anders, wenn sie überschritten wird. Wer die Kette kennt, kann die Werte so setzen, dass sie schützen, ohne den Betrieb zu stören. Wie PHP Uploads intern verarbeitet, erklärt [Wie PHP Datei-Uploads verarbeitet](https://phpsos.de/php/datei-uploads-intern/); die sichere Programmierung von Upload-Funktionen beschreibt [Datei-Uploads in PHP sicher umsetzen](https://phpsos.de/ratgeber/datei-upload-sicher/).

## Die Kette der Upload-Grenzen

Eine Anfrage durchläuft mehrere Grenzen, bevor die Anwendung sie sieht. Die folgenden Angaben stammen aus den Dokumentationen von Nginx, Apache und PHP:

| Stelle | Einstellung | Standard laut Doku | Bei Überschreitung |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | Fehler 413 an den Browser |
| Apache ab 2.4.54 | `LimitRequestBody` | 1 GiB (bis 2.4.53: unbegrenzt) | Fehlerantwort statt Verarbeitung |
| PHP | `post_max_size` | 8M | `$_POST` und `$_FILES` leer |
| PHP | `upload_max_filesize` | 2M | Datei wird mit Fehlercode abgelehnt |
| PHP | `max_file_uploads` | 20 | weitere Dateien werden ignoriert |
| PHP | `max_input_vars` | 1000 | weitere Formularfelder fehlen |

Daraus ergibt sich eine einfache Regel: `upload_max_filesize` kleiner als `post_max_size`, `post_max_size` kleiner als die Grenze im Webserver. Das PHP-Handbuch empfiehlt zudem, dass `memory_limit` im Allgemeinen größer ist als `post_max_size`. Während der PHP2Shell-Übergangsmaßnahme mit `memory_limit=-1` übernimmt diese Rolle die Grenze über Container oder cgroup; mehr dazu unter [memory_limit richtig setzen](https://phpsos.de/blog/memory-limit-richtig-setzen/).

## post_max_size nach PHP2Shell: was php.net rät

In der Sicherheitsmeldung vom 21.10.2026 nennt php.net für Server ohne Update niedrige Anfragegrenzen als eine der Übergangsmaßnahmen. Sie verringern das Risiko einzelner Angriffswege, sind aber ausdrücklich kein vollständiger Schutz:

1. **Ohne Datei-Uploads:** `post_max_size = 8M`.
2. **Mit Datei-Uploads:** `post_max_size = 32M`.
3. **In beiden Fällen:** `upload_max_filesize` unter `post_max_size` halten.
4. **Zusätzlich erwägen:** Grenzen im Webserver oder Proxy für die dekodierte Anfragegröße, die Zahl der Eingabefelder, die Zahl der Multipart-Teile, die Zahl der Kopfzeilen und die Verschachtelungstiefe. Laut php.net müssen diese Grenzen auch Anfragen ohne verwertbare `Content-Length`-Angabe erfassen.

Die Werte gehören dorthin, wo Anwendungen sie nicht überschreiben können. Weil `post_max_size` und `upload_max_filesize` laut Handbuch auf Verzeichnisebene änderbar sind, könnte eine `.user.ini` oder bei mod_php eine `.htaccess` sie sonst wieder anheben:

```ini
; FPM-Pool der Website, mit Uploads (Übergang bis zum Update)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

Im Webserver ziehen Sie die Grenze knapp oberhalb, damit zu große Anfragen gar nicht erst bei PHP ankommen:

```nginx
# Nginx, im server- oder location-Block
client_max_body_size 32m;
```

```apache
# Apache, im VirtualHost: 32 MiB in Bytes
LimitRequestBody 33554432
```

Danach alle PHP-Worker und den Webserver neu laden. Die Übersicht aller Übergangsmaßnahmen steht unter [Sofortmaßnahmen, wenn Sie noch nicht patchen können](https://phpsos.de/php2shell/sofortmassnahmen-ohne-patch/). Ob und wie sich Upload-Anfragen zusätzlich am Proxy filtern lassen, beleuchtet [Upload-Anfragen am Rand filtern](https://phpsos.de/blog/upload-anfragen-am-rand-filtern/).

> **Wichtig:**
> Testen Sie nach jeder Änderung die Formulare mit den größten legitimen Anfragen: Bewerbungen mit mehreren Anhängen, Produktimporte, Bildergalerien. Ein zu knapper Wert legt Geschäftsprozesse lahm, ohne dass jemand eine Fehlermeldung sieht.

## Den richtigen Wert für Ihre Website ermitteln

Statt pauschaler Werte lohnt eine kurze Bestandsaufnahme. Listen Sie alle Formulare mit Uploads auf und notieren Sie die größte legitime Datei und die höchste Zahl gleichzeitiger Dateien. Daraus ergibt sich der Bedarf: `upload_max_filesize` deckt die größte Einzeldatei, `post_max_size` die Summe aller Dateien einer Anfrage plus etwas Reserve für Formularfelder.

Liegt der Bedarf über 32M, passt er nicht zur Übergangsempfehlung von php.net. Dann ist das ein weiterer Grund, das Update vorzuziehen. Große Uploads lassen sich auch über eine eigene Subdomain mit eigenem Pool abwickeln, damit die übrige Website enge Grenzen behält.

Nach dem Update auf 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einen bestätigten Backport können Sie die Werte wieder am tatsächlichen Bedarf ausrichten. Großzügiger als nötig sollten sie trotzdem nicht sein: Jede Grenze, die über den Bedarf hinausgeht, vergrößert die Angriffsfläche ohne Nutzen. Braucht eine Website gar keine Uploads, ist `file_uploads = Off` die sauberste Lösung.

## Fehlerbilder richtig deuten

Wenn Uploads scheitern, verrät das Verhalten, welche Grenze greift. Eine Seite mit Fehler 413 stammt vom Webserver. Ein Formular, das ohne Meldung neu lädt oder „ungültige Anfrage“ meldet, deutet auf leere `$_POST`-Daten, also `post_max_size`. Eine Meldung der Anwendung zu einer einzelnen Datei passt zu `upload_max_filesize`. Und fehlende Felder in sehr großen Formularen, etwa bei Produktvarianten, sprechen für `max_input_vars`. Das PHP-Fehlerlog enthält bei überschrittenem `post_max_size` in der Regel eine Warnung mit der Größe der Anfrage.

Damit Nutzer nicht ratlos zurückbleiben, sollte die Anwendung den Fall erkennen. Das PHP-Handbuch schlägt dafür einen einfachen Weg vor: Das Formular übergibt einen Marker in der Adresse, etwa `?processed=1`. Kommt dieser Marker an, sind aber `$_POST` und `$_FILES` leer, war die Anfrage zu groß, und die Anwendung kann eine verständliche Meldung mit der zulässigen Größe anzeigen.

## Wie hilft PHP SOS konkret?

- Wir erfassen alle Upload-Wege Ihrer Websites und ermitteln die tatsächlich nötigen Größen.
- Wir setzen Webserver-, PHP- und Pool-Grenzen stimmig und gegen Überschreiben gesperrt, einschließlich der Übergangswerte von php.net.
- Wir testen Formulare, Importe und Uploads nach der Umstellung und passen Werte gezielt an.
- Im Rahmen der [Server-Härtung](https://phpsos.de/leistungen/server-haertung/) führen wir die Werte nach dem Update auf den dauerhaften Bedarf zurück.


## Häufige Fragen

**Was ist der Unterschied zwischen post_max_size und upload_max_filesize?**  
upload_max_filesize begrenzt die Größe einer einzelnen hochgeladenen Datei. post_max_size begrenzt die gesamten Daten einer POST-Anfrage, also alle Dateien und Formularfelder zusammen. Laut PHP-Handbuch muss post_max_size deshalb größer sein als upload_max_filesize.

**Was passiert, wenn eine Anfrage größer als post_max_size ist?**  
Laut PHP-Handbuch sind dann $_POST und $_FILES leer. Die Anwendung erhält also gar keine Formulardaten und zeigt oft nur eine unklare Fehlermeldung oder lädt das Formular neu. Das macht diesen Fehler schwer zu erkennen.

**Welche Werte empfiehlt php.net wegen PHP2Shell?**  
Als Übergangsmaßnahme bis zum Update: post_max_size = 8M für Anwendungen ohne Datei-Uploads, 32M für Anwendungen mit Uploads, und upload_max_filesize darunter. Das ist laut php.net kein vollständiger Schutz; nur das Update auf eine behobene PHP-Version schließt die Lücken.

**Kann ich post_max_size per ini_set() im Code ändern?**  
Nein. Laut PHP-Handbuch ist post_max_size nur auf Verzeichnisebene änderbar, etwa in php.ini, im FPM-Pool, in .user.ini oder bei mod_php in .htaccess. Wer den Wert erzwingen will, setzt ihn mit php_admin_value, dann kann ihn auch eine .user.ini nicht überschreiben.

## Quellen

- [php.net: Sicherheitsmeldung vom 21.10.2026](https://www.php.net/)
- [PHP-Handbuch: Core-Einstellungen (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)