"413 Request Entity Too Large": Payload-Limits erhöhen (FAQ)

Der Fehler „413 Request Entity Too Large" taucht in n8n meist dann auf, wenn ein Webhook eine größere Datei entgegennimmt, etwa ein PDF, ein Bild oder ein umfangreiches JSON-Payload, und die konfigurierte Obergrenze überschritten wird. n8n setzt hier standardmäßig ein Limit von 16 MiB pro Payload, das sich über eine einzelne Umgebungsvariable anheben lässt. In vielen Fällen liegt die eigentliche Bremse aber gar nicht bei n8n selbst, sondern eine Ebene davor, im Reverse Proxy. Stand: Juli 2026.

Dieser FAQ-Artikel zeigt, welche Variable Sie setzen müssen, wie Sie zwischen einem n8n-internen und einem Proxy-Limit unterscheiden, und worauf Sie beim Erhöhen des Limits achten sollten, damit Ihre Instanz stabil bleibt.

Was bedeutet der 413-Fehler in n8n genau?

Der HTTP-Statuscode 413 signalisiert, dass der Server die eingehende Anfrage ablehnt, weil ihr Payload größer ist als erlaubt. Bei n8n greift dieses Limit vor allem an zwei Stellen:

• Webhook-Trigger, die Dateien oder große JSON-Bodies von außen entgegennehmen, etwa aus Formularen, Chat-Widgets oder externen Systemen.
• Interne Verarbeitung großer Datensätze innerhalb eines Workflows, wenn ein Node ein Ergebnis zurückgibt, das die konfigurierte Obergrenze überschreitet.

Laut der n8n-Dokumentation zu den Endpoint-Umgebungsvariablen liegt das Standardlimit bei 16 MiB. Für die meisten Automatisierungen mit Textdaten, kleinen Bildern oder normalen API-Antworten reicht das aus. Sobald aber PDFs, hochauflösende Bilder oder mehrseitige Dokumente durch einen Workflow laufen, ist die Grenze schnell erreicht.

Die zentrale Umgebungsvariable: N8N_PAYLOAD_SIZE_MAX

Die entscheidende Stellschraube heißt N8N_PAYLOAD_SIZE_MAX. Sie definiert die maximale Payload-Größe in MiB und ist laut offizieller Dokumentation standardmäßig auf 16 gesetzt. Um das Limit zu erhöhen, setzen Sie die Variable auf einen höheren Wert, zum Beispiel:

• `N8N_PAYLOAD_SIZE_MAX=64` für 64 MiB
• `N8N_PAYLOAD_SIZE_MAX=128` für 128 MiB

Bei einer Docker-Installation tragen Sie die Variable in Ihre Compose-Datei oder in die Docker-Run-Umgebung ein, bei einer npm-Installation setzen Sie sie vor dem Start, zum Beispiel per `N8N_PAYLOAD_SIZE_MAX=64 n8n`. Wichtig: Nach dem Setzen der Variable muss die n8n-Instanz neu gestartet werden, damit die Änderung greift. Ein einfaches Neuladen der Weboberfläche reicht nicht aus.

Für Formular-Uploads mit Dateien gibt es zusätzlich die separate Variable N8N_FORMDATA_FILE_SIZE_MAX, die laut derselben Dokumentation standardmäßig auf 200 MiB steht und speziell die Dateigröße innerhalb von Form-Data-Payloads regelt, etwa wenn ein Webhook Datei-Uploads aus einem Formular entgegennimmt. Wenn Sie also gezielt größere Dateianhänge zulassen wollen, prüfen Sie beide Variablen und stimmen Sie sie aufeinander ab.

Warum das Setzen der Variable manchmal nicht reicht

Ein häufiger Stolperstein aus der n8n-Community: Die Variable ist korrekt gesetzt, der Fehler bleibt trotzdem bestehen. Der Grund liegt fast immer bei einer vorgeschalteten Instanz, die die Anfrage schon abfängt, bevor sie n8n überhaupt erreicht. In einem Community-Thread zu 413-Fehlern beim PDF-Upload über Webhooks bestätigt sich das Muster: Nicht n8n selbst, sondern die vorgeschaltete Nginx-Konfiguration begrenzte die Anfrage, obwohl das n8n-interne Limit deutlich höher lag.

Prüfen Sie deshalb der Reihe nach:

• Nginx als Reverse Proxy: Die Direktive `client_max_body_size` begrenzt die Body-Größe unabhängig von n8n. Ein Wert wie `client_max_body_size 100M;` in der Server- oder Location-Konfiguration muss zum n8n-Limit passen oder großzügiger sein.
• Traefik oder Cloudflare-Tunnel: Auch hier existieren eigene Obergrenzen für Request-Bodies, die separat konfiguriert werden müssen.
• Docker-Setups mit vorgeschaltetem Load Balancer: Cloud-Load-Balancer bringen oft eigene, teils niedrigere Standardlimits mit, die unabhängig von n8n greifen.

Erst wenn alle Ebenen, also Proxy und n8n selbst, auf ein ausreichend hohes Limit gesetzt sind, verschwindet der 413-Fehler zuverlässig. In einem älteren, mittlerweile behobenen Fall aus dem n8n-Community-Forum lag die Ursache sogar an einem Bug in einer früheren n8n-Version, der Payloads schon ab 100 KB blockierte, unabhängig vom gesetzten Limit. Ein Update auf eine aktuelle n8n-Version behebt solche Altlasten zuverlässig mit.

Grenzen bewusst setzen statt pauschal maximieren

Bevor Sie das Limit reflexartig auf einen sehr hohen Wert setzen, lohnt sich ein kurzer Blick auf die Kehrseite. Die Dokumentation weist ausdrücklich darauf hin, dass ein höheres Payload-Limit mehr Arbeitsspeicher und mehr Rechenleistung beansprucht und sich auf die Performance der gesamten Instanz auswirken kann. Wer produktiv mit vielen parallelen Workflows arbeitet, sollte das Limit deshalb an den tatsächlichen Bedarf anpassen, nicht an das theoretisch Mögliche.

Ein paar praktische Leitplanken:

• Setzen Sie den Wert so hoch wie nötig, nicht so hoch wie möglich. Für PDF-Verarbeitung reichen oft 32 bis 64 MiB, für Videodaten kann mehr nötig sein.
• Beobachten Sie den Speicherverbrauch Ihrer Instanz nach der Anpassung, besonders bei Self-Hosting mit begrenzten Ressourcen.
• Kombinieren Sie große Payload-Limits nach Möglichkeit mit dem Filesystem-Modus für binäre Daten, gesteuert über N8N_DEFAULT_BINARY_DATA_MODE, statt große Dateien im Arbeitsspeicher zu halten. Laut Dokumentation hält n8n binäre Daten standardmäßig im Modus „default" im Arbeitsspeicher vor, was bei großen Payloads schnell zu Speicherdruck führt.

Wer eine n8n-Instanz produktiv betreibt und nicht bei jedem Infrastrukturthema selbst nachforschen möchte, kann Konfiguration, Monitoring und Fehlerbehebung im Rahmen einer n8n-Beratung und -Betreuung durch NordFlux auslagern. Du behältst dabei die Kontrolle über deine Workflows und Daten, während die technische Feinjustierung im Hintergrund läuft.

Häufige Fragen

Welche Umgebungsvariable erhöht das Payload-Limit in n8n?

Die Variable N8N_PAYLOAD_SIZE_MAX legt die maximale Payload-Größe in MiB fest und steht laut n8n-Dokumentation standardmäßig auf 16. Sie erhöhen sie, indem Sie die Variable auf einen höheren Wert setzen und die Instanz danach neu starten.

Warum bekomme ich trotz erhöhtem N8N_PAYLOAD_SIZE_MAX weiterhin einen 413-Fehler?

In den meisten dieser Fälle sitzt eine weitere Grenze vor n8n, etwa in einer Nginx-Konfiguration mit `client_max_body_size`, in Traefik oder in einem vorgeschalteten Load Balancer. n8n selbst lässt die Anfrage vielleicht schon zu, der Proxy blockiert sie aber vorher. Prüfen Sie deshalb jede Ebene der Infrastruktur einzeln.

Was ist der Unterschied zwischen N8N_PAYLOAD_SIZE_MAX und N8N_FORMDATA_FILE_SIZE_MAX?

N8N_PAYLOAD_SIZE_MAX begrenzt die Gesamtgröße einer Anfrage an n8n. N8N_FORMDATA_FILE_SIZE_MAX regelt speziell die maximale Dateigröße innerhalb von Form-Data-Payloads, etwa bei Datei-Uploads über ein Webhook-Formular, und liegt standardmäßig bei 200 MiB. Für reine Datei-Uploads über Formulare ist meist diese zweite Variable relevant.

Muss ich n8n nach dem Setzen der Variable neu starten?

Ja. Umgebungsvariablen wie N8N_PAYLOAD_SIZE_MAX werden beim Start des n8n-Prozesses eingelesen. Ein Neuladen der Weboberfläche reicht nicht, die Instanz beziehungsweise der Container muss neu gestartet werden, damit die neue Grenze wirksam wird.

Gibt es Nachteile, wenn ich das Limit sehr hoch setze?

Ja. Ein höheres Payload-Limit erhöht laut Dokumentation den Bedarf an Arbeitsspeicher und Rechenleistung und kann sich auf die Performance der gesamten Instanz auswirken. Setzen Sie das Limit deshalb bewusst auf den tatsächlichen Bedarf statt pauschal auf einen sehr hohen Wert.