Der Fehler 414 Request-URI Too Large erscheint, wenn dein Browser eine URL sendet, die das maximale URI-Längenlimit deines Servers überschreitet. Auf WordPress-Seiten passiert das am häufigsten, wenn ein Plugin Produktfilterwerte, IDs oder Abfrageparameter so lange als GET-Variablen übergibt, bis die URL über das hinauswächst, was Apache oder Nginx akzeptieren.
Kurz gesagt: Der 414-Fehler bedeutet, dass dein Browser eine URL gesendet hat, die das Längenlimit deines Servers überschreitet. Bei Apache erhöhe
LimitRequestLine; bei Nginx erhöhelarge_client_header_buffers. Wenn du ein WordPress-Plugin betreust, das lange URLs erzeugt, stelle dessen Datenübermittlung auf POST um.
Was verursacht den 414-Fehler?
Ein 414-Fehler tritt auf, wenn die URI – der URL-Pfad plus die Abfragezeichenfolge – in einer HTTP-Anfrage das konfigurierte Maximum des Servers überschreitet. Häufige Auslöser auf WordPress-Seiten:
- Lange Abfragezeichenfolgen: WooCommerce-Filter-Plugins oder facettierte Suche, die jeden aktiven Filterwert in der URL codieren.
- GET-lastige Plugins: Plugins, die große Nutzlasten (Produkt-IDs, Nutzerdaten) als GET-Parameter statt als POST übergeben.
- Niedriges Serverlimit: Ein
LimitRequestLine-Wert (Apache) oderlarge_client_header_buffers-Wert (Nginx), der niedriger gesetzt ist als die URL-Länge deiner Seite. - Große Formularübermittlungen: Formulare, die Daten in die URL statt in den Anfragetext codieren.
Welche Lösung brauche ich?
| Symptom | Wahrscheinliche Ursache | Empfohlene Lösung |
|---|---|---|
| Fehler erscheint nur auf Seiten mit vielen aktiven Filtern | Plugin übergibt zu viele GET-Parameter | GET-Anfragen auf POST umstellen |
| Fehler erscheint sogar nach dem Kürzen der URL | URI-Limit des Servers ist zu niedrig | Apache- oder Nginx-Limit erhöhen |
| Fehler erscheint auf allen Seiten, unabhängig vom Inhalt | Serverlimit ist global zu niedrig | Apache- oder Nginx-Limit erhöhen |
| Beim Shared-Hosting ohne SSH-Zugang | Kein direkter Konfigurationszugriff | Hoster-Support mit der Direktive kontaktieren |
Lösung: Apache- oder Nginx-Serverlimits erhöhen
Wenn der 414-Fehler mehrere Seiten betrifft oder nach dem Kürzen der URL bestehen bleibt, muss das URI-Längenlimit deines Servers erhöht werden. Die Änderung ist eine einzelne Direktive in deiner Serverkonfigurationsdatei.
Finde deine Serverkonfigurationsdatei
Öffne deine WordPress-Seite in einem Browser, klicke mit der rechten Maustaste auf die Startseite und wähle Untersuchen.
Gehe in den Entwicklertools zum Tab Netzwerk. Klicke auf die erste Anfrage (deine Startseiten-URL), um ihre Header aufzuklappen.
Sieh dir in den Antwort-Headern die Zeile Server: an – dort steht Apache, nginx oder ein CDN-Name.
Die Standard-Speicherorte der Konfigurationsdateien sind:
- Apache 2.4:
/etc/apache2/apache2.conf - Nginx 1.24+:
/etc/nginx/nginx.conf
Für Nginx-Server
Navigiere in deinem Dateimanager oder per SSH zu /etc/nginx/nginx.conf.
Finde die Direktive large_client_header_buffers innerhalb des http { }-Blocks. Die Direktive nimmt zwei Werte an: die Anzahl der Puffer und ihre individuelle Größe. Ein Wert zwischen 8k und 128k sollte die meisten WordPress-Setups abdecken – nutze Vielfache von 4k:
large_client_header_buffers 4 16k;
Teste und lade Nginx nach dem Speichern neu:
sudo nginx -t && sudo systemctl reload nginxDie Dokumentation zu Nginx large_client_header_buffers enthält die vollständige Parametersyntax.
Für Apache-Server
Öffne /etc/apache2/apache2.conf.
Suche nach der Direktive LimitRequestLine. Ist sie nicht vorhanden, füge sie am Ende der Datei hinzu. In unseren Tests reicht Apaches Standard-LimitRequestLine von 8.190 Bytes für die meisten Seiten; du stößt typischerweise nur dann an das Limit, wenn WooCommerce-Filter-Plugins mehr als ~50 aktive Filterwerte in der URL stapeln. Du kannst sie auf 256.000 oder höher anheben, um den 414-Fehler zu beseitigen – stelle sicher, dass der Wert ein Vielfaches von 2 ist:
LimitRequestLine 256000
Teste deine Konfiguration und starte Apache neu:
sudo apachectl configtest && sudo systemctl restart apache2Die Dokumentation zu Apache LimitRequestLine enthält den vollständigen Bereich der erlaubten Werte.
Lösung: GET-Anfragen auf POST umstellen
Aus WP-STAGING-Support-Tickets ist der häufigste Auslöser beim Shared-Hosting ein Plugin, das Produkt-IDs oder Filterparameter in einer GET-URL übergibt – die Umstellung auf POST behebt das sofort.
Wenn der 414-Fehler nur auf bestimmten Plugin-Seiten erscheint – WooCommerce-Kategoriefilter, Ergebnisse der facettierten Suche oder REST-API-Endpunkte –, codiert das Plugin zu viele Parameter in die Abfragezeichenfolge. POST-Anfragen senden ihre Nutzlast im Anfragetext und umgehen so das URI-Längenlimit vollständig.
Prüfe die Einstellungen des Plugins auf eine Option mit der Bezeichnung „URL-basierte Filter", „GET-Filter" oder „Query-String-Modus". Existiert ein POST- oder AJAX-Modus, aktiviere ihn. Gibt es keine solche Einstellung, eröffne ein Support-Ticket beim Plugin-Autor und füge die konkrete URL bei, die den 414 auslöst.
Für Entwickler, die eigene Integrationen gegen die WordPress-REST-API bauen: nutze wp_remote_post() für große Nutzlasten statt wp_remote_get(). Die REST-API akzeptiert POST-Anfragen für alle Schreibvorgänge und für eigene Endpunkte, die eine POST-Methode bereitstellen.
Lösung: Einen URL-Verkürzer als Diagnoseschritt nutzen
Das Kürzen der URL bestätigt, ob der 414 allein durch die URL-Länge verursacht wird. Wenn ein Nutzer die verkürzte URL aufruft, leitet ihn der Verkürzer zur ursprünglichen langen URL weiter, ohne dass der Browser jemals die vollständige URI an deinen Server sendet. Lädt die verkürzte URL korrekt, ist das Problem als URI-Länge bestätigt. Wende nach der Bestätigung eine dauerhafte Lösung von oben an, statt dich in der Produktion auf eine verkürzte URL zu verlassen.
Bevor du Änderungen an der Serverkonfiguration vornimmst, empfehlen wir, ein vollständiges Seiten-Backup über WP Staging zu erstellen. HIER KLICKEN ZUM INSTALLIEREN
Hinweis: Verkürzte URLs verschleiern das Ziel, können ablaufen, wenn sich der Dienst des Verkürzers ändert, und bieten keinen SEO-Wert. Nutze das Kürzen von URLs nur zur Diagnose – nicht als Live-Lösung.
Was tun, wenn die Lösung nicht funktioniert
Arbeite diese Checkliste durch, wenn der 414-Fehler nach einer Änderung der Serverkonfiguration bestehen bleibt.
Konfigurationsdatei geändert, aber der Wert hatte keine Wirkung?
- Apache: führe
apachectl -t -D DUMP_VHOSTSaus, um zu bestätigen, welche Konfigurationsdatei für deinen virtuellen Host aktiv ist. Die globaleapache2.conf-Direktive kann durch eineLimitRequestLinein einem<VirtualHost>-Block innerhalb von/etc/apache2/sites-enabled/überschrieben werden. - Nginx: führe
nginx -T | grep large_client_headeraus, um die effektive zusammengeführte Konfiguration zu sehen. Ein Wert in einemserver { }-Block überschreibt den globalenhttp { }-Block.
Beim Shared-Hosting ohne SSH-Zugang?
Kontaktiere das Support-Team deines Hosters und gib die genaue Direktive an. Für Apache fordere LimitRequestLine 256000 an; für Nginx large_client_header_buffers 4 16k. Die meisten Managed-WordPress-Hoster können die Änderung auf deinem Konto anwenden, ohne serverweite Auswirkungen.
Nutzt du Cloudflare oder ein anderes CDN? CDNs und Reverse-Proxys erzwingen unabhängig von deinem Ursprungsserver ihre eigenen URI-Längenlimits. Gibt das CDN den 414 zurück, bevor die Anfrage Apache oder Nginx erreicht, hilft das Ändern deiner Serverkonfiguration nicht. In diesem Fall ist die Umstellung des Plugins von GET auf POST die einzige tragfähige Option – sieh in der Dokumentation des CDN nach seiner maximalen URL-Länge.
Fazit
Der Fehler 414 Request-URI Too Large wird durch eine URL verursacht, die das konfigurierte Limit deines Servers überschreitet. Auf den meisten WordPress-Seiten ist die Lösung entweder das Erhöhen des Limits in apache2.conf oder nginx.conf oder das Umstellen der Anfragemethode eines Plugins von GET auf POST. Nutze die Entscheidungstabelle oben, um die richtige Lösung für dein Setup zu ermitteln, und folge dann den Schritten für deinen Servertyp.
Verwandte Artikel
