Was ist ein 400 Bad Request-Fehler und wie behebt man ihn?

Ein 400 Bad Request ist ein HTTP/1.1-Client-Fehlerstatuscode, der in RFC 9110 definiert ist und dem Server signalisiert, dass er eine Anfrage empfangen hat, die er nicht verarbeiten kann oder will, weil die Anfrage selbst fehlerhaft ist. Im Gegensatz zu 5xx-Fehlern, die auf der Serverseite entstehen, liegt die Schuld bei einem 400-Fehler eindeutig beim Client — das bedeutet, das Problem liegt in der gesendeten Anfrage, nicht in der Fähigkeit des Servers zu antworten.

In der Praxis wird ein 400-Fehler ausgelöst, bevor der Server überhaupt versucht, die Anfrage zu erfüllen. Der Server analysiert die eingehende HTTP-Nachricht, erkennt etwas strukturell oder semantisch Ungültiges — einen beschädigten Header, eine fehlerhafte URI, eine zu große Nutzlast, einen ungültigen Cookie — und gibt sofort 400 Bad Request zurück, anstatt fortzufahren. Diese Unterscheidung zu kennen ist der schnellste Weg zur richtigen Diagnose.

Was der 400-Statuscode auf Protokollebene tatsächlich bedeutet

HTTP basiert auf einem strengen Anfrage-Antwort-Vertrag. Jede Anfrage muss der in der HTTP-Spezifikation definierten Grammatik entsprechen. Wenn ein Client eine Nachricht sendet, die gegen diese Grammatik verstößt, ist der Server sowohl berechtigt als auch verpflichtet, sie mit einer 400-Antwort abzulehnen.

Der Server protokolliert einen 400-Fehler nicht als eigenen Fehler. Er protokolliert ihn als abgelehnte Client-Anfrage. Deshalb behebt ein blindes Neustarten eines Servers oder das Leeren eines CDN-Caches selten einen echten 400-Fehler — die Ursache liegt fast immer in der Anfragekonstruktion.

Häufige browserseitig dargestellte Varianten dieses Fehlers sind:

• 400 Bad Request
• HTTP Error 400
• Bad Request — Invalid URL
• 400. That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request. The server cannot or will not process the request due to something that is perceived to be a client error.

All diese Varianten beziehen sich auf denselben zugrunde liegenden HTTP-Statuscode. Die Formulierung unterscheidet sich je nach Serversoftware (Apache, Nginx, IIS, Cloudflare) und Anwendungs-Framework.

Ursachen eines 400 Bad Request-Fehlers

Das Verständnis des genauen Auslösers ist unerlässlich, bevor eine Lösung versucht wird. Die Ursachen lassen sich in zwei Kategorien einteilen: clientseitige und serverseitige Fehlkonfiguration.

Clientseitige Ursachen

Fehlerhafte oder falsch kodierte URL

Eine URL mit nicht kodierten Leerzeichen, unzulässigen Zeichen oder fehlerhaften Prozent-Kodierungssequenzen wird sofort abgelehnt. Die HTTP-Spezifikation erfordert, dass alle Zeichen außerhalb des nicht reservierten Zeichensatzes (A–Z, a–z, 0–9, -, _, ., ~) vor der Übertragung prozent-kodiert werden.

Beschädigte oder zu große Cookies

Cookies werden im Cookie-Anfrage-Header übertragen. Wenn ein Cookie-Wert fehlerhaft ist, die browserseitige Größenbeschränkung pro Cookie überschreitet (typischerweise 4096 Bytes) oder Zeichen enthält, die RFC 6265 verletzen, kann der Server die gesamte Anfrage ablehnen. Dies ist eine der am häufigsten übersehenen Ursachen für intermittierende 400-Fehler auf Websites, die ein Benutzer zuvor problemlos besucht hat.

Ungültige oder fehlende erforderliche Anfrage-Header

Einige APIs und Webanwendungen erzwingen eine strenge Header-Validierung. Ein fehlender Content-Type bei einer POST-Anfrage, ein fehlerhafter Authorization-Header oder ein Accept-Header mit einem nicht unterstützten Medientyp können alle einen 400-Fehler auslösen.

Zu große Anfrage-Nutzlast

Webserver und Reverse-Proxies erzwingen maximale Body-Größenbeschränkungen. Nginx verwendet client_max_body_size (Standard: 1 MB); Apache verwendet LimitRequestBody. Das Überschreiten dieser Schwellenwerte erzeugt je nach Konfiguration eine 400- oder 413-Antwort.

Veralteter oder falscher DNS-Cache

Während DNS-Auflösungsfehler typischerweise Verbindungsfehler statt HTTP-400-Fehler erzeugen, kann ein vergifteter oder veralteter DNS-Cache, der eine Anfrage an den falschen Server weiterleitet — einen, der den Host-Header nicht erkennt — dazu führen, dass ein 400-Fehler vom falschen Ursprungsserver zurückgegeben wird.

Browser-Erweiterungen, die Anfrage-Header beeinflussen

Bestimmte Werbeblocker, Datenschutz-Tools und Entwickler-Erweiterungen modifizieren ausgehende HTTP-Header. Wenn eine Erweiterung einen fehlerhaften oder doppelten Header einfügt, kann der Server die Anfrage ablehnen.

Serverseitige Ursachen

Falsch konfigurierte .htaccess-Regeln (Apache)

Rewrite-Regeln, Redirect-Direktiven oder Zugriffskontrolleinträge mit Syntaxfehlern können dazu führen, dass Apache einen 400-Fehler generiert, bevor die Anfrage die Anwendungsschicht erreicht.

Nginx-Konfigurationsfehler

Ungültige server_name-Direktiven, fehlerhafte location-Blöcke oder falsche proxy_pass-Einstellungen können dazu führen, dass Nginx einen 400-Fehler für Anfragen zurückgibt, die es nicht weiterleiten kann.

WAF oder Sicherheits-Plugin blockiert zu viel

Web Application Firewalls — ob auf Serverebene (ModSecurity), CDN-Ebene (Cloudflare WAF) oder Anwendungsebene (WordPress-Sicherheits-Plugins) — können legitime Anfragen als bösartig einstufen und einen 400- oder 403-Fehler zurückgeben. Dies ist häufig der Fall, wenn Anfrageparameter Zeichenketten enthalten, die SQL-Injection- oder XSS-Signaturen entsprechen.

Validierungsfehler auf Anwendungsebene

Frameworks wie Laravel, Django oder Express.js geben 400 zurück, wenn die Eingabevalidierung fehlschlägt — zum Beispiel wenn ein erforderliches JSON-Feld fehlt, ein Datumsfeld im falschen Format vorliegt oder ein numerischer Parameter einen Zeichenkettenwert erhält.

So beheben Sie einen 400 Bad Request-Fehler: Clientseitige Schritte

1. URL validieren und korrigieren

Überprüfen Sie die URL Zeichen für Zeichen. Achten Sie besonders auf:

• Nicht kodierte Leerzeichen: Ein Leerzeichen muss %20 sein, kein wörtliches Leerzeichen oder + (außerhalb von Formulardaten).
• Doppelte Schrägstriche oder fehlende Schrägstriche: https://example.com//path oder https://example.com/path? mit einem hängenden Fragezeichen.
• Fehlerhafte Prozent-Kodierung: Ein %, dem nicht genau zwei hexadezimale Ziffern folgen, ist unzulässig.
• Nicht-ASCII-Zeichen: Domainnamen mit Unicode-Zeichen müssen Punycode verwenden; Pfadsegmente mit Unicode müssen in UTF-8 prozent-kodiert werden.

Eine korrekt kodierte URL sieht so aus:

https://example.com/search?q=hello%20world&lang=en

Nicht so:

https://example.com/search?q=hello world&lang=en

2. Browser-Cookies und Cache leeren

Dies löst die Mehrheit der 400-Fehler, die auf Websites auftreten, die der Benutzer zuvor besucht hat.

Google Chrome:

1. Öffnen Sie chrome://settings/clearBrowserData
2. Setzen Sie den Zeitraum auf Gesamte Zeit
3. Aktivieren Sie Cookies und andere Websitedaten und Bilder und Dateien im Cache
4. Klicken Sie auf Daten löschen

Mozilla Firefox:

1. Öffnen Sie about:preferences#privacy
2. Klicken Sie unter Cookies und Website-Daten auf Daten entfernen
3. Wählen Sie beide Optionen aus und bestätigen Sie

Safari (macOS):

1. Gehen Sie zu Safari > Einstellungen > Datenschutz
2. Klicken Sie auf Website-Daten verwalten, dann auf Alle entfernen

Für einen gezielteren Ansatz — besonders nützlich, wenn Sie nicht alle Sitzungsdaten verlieren möchten — verwenden Sie die Entwicklertools des Browsers, um nur die Cookies für die betreffende Domain zu löschen:

1. Öffnen Sie DevTools (F12 oder Cmd+Option+I)
2. Navigieren Sie zu Anwendung > Speicher > Cookies
3. Wählen Sie die Domain aus und löschen Sie einzelne Cookies

3. DNS-Cache leeren

Windows:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Linux (nscd):

sudo service nscd restart

Überprüfen Sie nach dem Leeren, ob die Auflösung korrekt ist, bevor Sie es erneut versuchen:

nslookup example.com

4. Browser-Erweiterungen deaktivieren

Erweiterungen, die HTTP-Header modifizieren, sind die wahrscheinlichsten Verursacher. Anstatt alle Erweiterungen gleichzeitig zu deaktivieren, verwenden Sie zunächst den Inkognito- oder Privatmodus des Browsers — die meisten Erweiterungen sind in privaten Fenstern standardmäßig deaktiviert. Wenn die Seite im Inkognito-Modus korrekt lädt, ist eine Erweiterung verantwortlich.

So isolieren Sie die spezifische Erweiterung in Chrome:

1. Navigieren Sie zu chrome://extensions/
2. Deaktivieren Sie alle Erweiterungen
3. Aktivieren Sie sie einzeln wieder und laden Sie die Seite nach jeder Aktivierung neu

5. In einem anderen Browser, Gerät oder Netzwerk testen

Dieser Schritt ermittelt schnell, ob das Problem umgebungsspezifisch ist. Wenn die Seite auf einem Mobilgerät mit Mobilfunkdaten lädt, aber auf Ihrem Desktop nicht, liegt das Problem wahrscheinlich lokal vor — entweder in der Browser-Konfiguration, einem Proxy auf Netzwerkebene oder einer Unternehmens-Firewall, die Anfrage-Header modifiziert.

So beheben Sie einen 400 Bad Request-Fehler: Serverseitige Schritte

Diese Schritte gelten für Website-Besitzer, Entwickler und Systemadministratoren mit Zugang zum Server oder Hosting-Kontrollpanel.

6. Server-Zugriffs- und Fehlerprotokolle analysieren

Server-Protokolle sind das maßgebliche Diagnosewerkzeug. Ein 400-Eintrag im Zugriffsprotokoll zeigt die rohe Anfragezeile, die abgelehnt wurde.

Nginx-Fehlerprotokoll (Standardpfad):

tail -n 100 /var/log/nginx/error.log | grep " 400 "

Apache-Fehlerprotokoll:

tail -n 100 /var/log/apache2/error.log

Nginx-Zugriffsprotokoll — nach 400-Antworten filtern:

awk '$9 == 400' /var/log/nginx/access.log | tail -20

Suchen Sie nach Mustern: Kommen die 400-Fehler von einem bestimmten Endpunkt, einem bestimmten User-Agent oder einem bestimmten Parameter? Dies schränkt die Ursache erheblich ein.

Wenn Sie eine VPS Hosting-Umgebung betreiben, haben Sie direkten SSH-Zugang zu diesen Protokollen. Bei verwaltetem Shared Web Hosting sind Zugriffsprotokolle typischerweise über den Fehler-Bereich von cPanel oder über den Raw Access-Protokoll-Download verfügbar.

7. .htaccess-Datei prüfen (Apache)

Ein einzelner Syntaxfehler in .htaccess kann dazu führen, dass Apache für jede Anfrage 400- oder 500-Fehler zurückgibt. Überprüfen Sie die Dateisyntax, ohne Apache neu zu starten:

apachectl -t

Häufige .htaccess-Probleme, die 400-Fehler erzeugen:

• RewriteRule-Muster mit nicht maskierten Sonderzeichen
• LimitRequestBody auf einen unerwartet niedrigen Wert gesetzt
• Fehlerhafte Header-Direktiven

Beispiel einer problematischen Direktive:

# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""

Korrigierte Version:

RequestHeader set X-Custom-Header "value with escaped quotes"

8. Nginx-Konfiguration prüfen

Überprüfen Sie die gesamte Nginx-Konfiguration, bevor Sie Änderungen anwenden:

nginx -t

Achten Sie auf client_max_body_size, wenn Benutzer Dateien hochladen:

http {
    client_max_body_size 50M;
}

Überprüfen Sie auch large_client_header_buffers — wenn Anfrage-Header (einschließlich Cookies) die Puffergröße überschreiten, gibt Nginx einen 400-Fehler zurück:

http {
    large_client_header_buffers 4 16k;
}

Nach der Bearbeitung ohne Ausfallzeit neu laden:

nginx -s reload

9. Datei-Upload-Limits erhöhen

Wenn der 400-Fehler speziell beim Hochladen von Dateien auftritt, überschreitet der Anfrage-Body wahrscheinlich das konfigurierte Limit des Servers.

PHP (php.ini):

upload_max_filesize = 50M
post_max_size = 55M

Apache (httpd.conf oder .htaccess):

LimitRequestBody 52428800

Nginx (nginx.conf):

client_max_body_size 50M;

Beachten Sie, dass post_max_size in PHP immer größer als upload_max_filesize sein muss, sonst verwirft PHP den Upload stillschweigend und die Anwendung gibt möglicherweise einen 400-Fehler zurück.

10. WAF-Regeln und Sicherheits-Plugins überprüfen

Wenn Sie ModSecurity, Cloudflare WAF oder ein WordPress-Sicherheits-Plugin (Wordfence, iThemes Security) betreiben, deaktivieren Sie vorübergehend den WAF-Regelsatz und testen Sie, ob der 400-Fehler verschwindet. Wenn ja, überprüfen Sie das WAF-Prüfprotokoll, um zu ermitteln, welche Regel ausgelöst wird:

tail -f /var/log/modsec_audit.log

Deaktivieren Sie die WAF nicht dauerhaft. Erstellen Sie stattdessen eine gezielte Ausnahme für das legitime Anfragemuster, das blockiert wird.

400 Bad Request im Vergleich zu verwandten HTTP-Fehlercodes

Das Verständnis, wo 400 in der HTTP-Fehlertaxonomie steht, verhindert Fehldiagnosen.

Ein wichtiger operativer Unterschied: 413 (Content Too Large) ist der semantisch präzisere Code für zu große Uploads, aber viele Server — insbesondere ältere Apache- und Nginx-Konfigurationen — geben stattdessen 400 zurück. Wenn Sie bei einem Datei-Upload einen 400-Fehler sehen, überprüfen Sie immer zuerst die Body-Größenlimits.

400-Fehler in API-Kontexten

REST- und GraphQL-APIs verwenden 400 häufig als Standardantwort für Eingabevalidierungsfehler. Wenn Sie eine API erstellen oder nutzen, enthält ein 400-Antwort-Body typischerweise eine strukturierte Fehler-Nutzlast:

{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}

Beim Debuggen von API-400-Fehlern:

• Überprüfen Sie, ob der Content-Type-Header dem Body-Format entspricht (application/json für JSON-Nutzlasten, multipart/form-data für Datei-Uploads)
• Bestätigen Sie, dass erforderliche Felder vorhanden und korrekt typisiert sind
• Prüfen Sie, ob Zeichenkettenwerte die maximalen Längenbeschränkungen nicht überschreiten
• Validieren Sie Datums- und Zeitformate anhand der API-Spezifikation (ISO 8601 ist Standard: 2024-01-15T10:30:00Z)
• Überprüfen Sie das Authorization-Header-Format — Bearer-Tokens müssen mit Bearer vorangestellt werden, nicht roh übergeben werden

Für Teams, die API-Dienste auf Dedicated Servers betreiben, ist die Aktivierung detaillierter Anfrage-Protokollierung auf Anwendungsebene (nicht nur auf Webserver-Ebene) entscheidend für die Diagnose von 400-Mustern im großen Maßstab.

400-Fehler mit Browser-Entwicklertools diagnostizieren

Das Netzwerk-Panel des Browsers ist das präziseste clientseitige Diagnosewerkzeug.

1. Öffnen Sie DevTools (F12)
2. Navigieren Sie zur Registerkarte Netzwerk
3. Reproduzieren Sie die Anfrage, die den 400-Fehler auslöst
4. Klicken Sie auf die fehlgeschlagene Anfrage im Wasserfall
5. Überprüfen Sie die Registerkarte Header — prüfen Sie sowohl Anfrage-Header als auch Antwort-Header
6. Überprüfen Sie die Registerkarte Antwort auf etwaige vom Server zurückgegebene Fehlerdetails

Das Panel Anfrage-Header zeigt genau, was der Browser gesendet hat. Vergleichen Sie dies mit dem, was der Server erwartet. Achten Sie besonders auf:

• Host-Header-Wert
• Cookie-Header-Größe und -Inhalt
• Content-Type und Content-Length für POST/PUT-Anfragen
• Alle benutzerdefinierten Header, die von Erweiterungen eingefügt werden

400-Fehler in Webanwendungen verhindern

Für Entwickler und Serveradministratoren reduzieren proaktive Maßnahmen das Auftreten von 400-Fehlern erheblich.

Eingabe-Bereinigung und -Validierung auf Anwendungsebene — Validieren Sie alle vom Benutzer bereitgestellten Eingaben, bevor sie die Routing-Schicht des Servers erreichen. Geben Sie beschreibende 400-Antworten mit feldspezifischen Fehlermeldungen zurück, anstatt generische Fehler zu liefern.

Korrekte URL-Kodierung im Client-Code implementieren — Verwenden Sie integrierte Kodierungsfunktionen anstatt manueller Zeichenkettenmanipulation:

// JavaScript — correct approach
const query = encodeURIComponent("hello world & more");
const url = `https://example.com/search?q=${query}`;

# Python — correct approach
from urllib.parse import urlencode
params = urlencode({"q": "hello world & more"})
url = f"https://example.com/search?{params}"

Explizite und angemessene Body-Größenlimits festlegen — Lassen Sie client_max_body_size nicht beim Standard von 1 MB, wenn Ihre Anwendung Datei-Uploads akzeptiert. Setzen Sie es aber auch nicht auf unbegrenzt — das schafft einen Denial-of-Service-Angriffsvektor.

400-Raten in der Produktion überwachen — Ein plötzlicher Anstieg der 400-Fehler ist oft der erste Hinweis auf einen Bot, der nach Schwachstellen sucht, ein defektes clientseitiges Formular oder eine Bereitstellung, die eine breaking API-Änderung eingeführt hat. Richten Sie Alarme für Ihre 4xx-Fehlerrate in Ihrem Monitoring-Stack ein (Grafana, Datadog, CloudWatch).

HTTPS mit einem gültigen SSL-Zertifikat verwenden — Einige 400-Fehler entstehen, wenn Clients HTTPS-Anfragen an einen Server senden, der nicht ordnungsgemäß für TLS konfiguriert ist, oder wenn ein Zertifikatsfehler dazu führt, dass der TLS-Handshake fehlschlägt, bevor die HTTP-Schicht überhaupt erreicht wird. Wenn Sie sicherstellen, dass Ihre SSL-Zertifikate gültig, korrekt installiert und für alle erforderlichen Subdomains gültig sind, wird diese Fehlerklasse vollständig beseitigt.

Kontrollpanel-Umgebungen korrekt konfigurieren — Wenn Sie mehrere Websites über ein Kontrollpanel verwalten, sind falsch konfigurierte Virtual-Host-Definitionen eine häufige Quelle von 400-Fehlern. Umgebungen, die VPS mit cPanel verwenden, sollten sicherstellen, dass das Dokumentenstammverzeichnis, die SSL-Bindung und die Rewrite-Regeln jeder Domain korrekt abgegrenzt sind, um domainübergreifende Anfragekontamination zu vermeiden.

Entscheidungsmatrix: Diagnose eines 400-Fehlers nach Symptom

Technische Checkliste: Behebung eines 400 Bad Request

Für Endbenutzer:

• URL manuell prüfen und neu eingeben, dabei Kodierungsprobleme korrigieren
• Cookies und Cache speziell für die betroffene Domain löschen
• In einem privaten/Inkognito-Fenster testen, um Erweiterungen auszuschließen
• Lokalen DNS-Cache leeren
• In einem anderen Browser, auf einem anderen Gerät und über eine andere Netzwerkverbindung testen

Für Entwickler und API-Nutzer:

• Überprüfen, ob Content-Type dem Anfrage-Body-Format entspricht
• Bestätigen, dass alle erforderlichen Felder und Header vorhanden und korrekt typisiert sind
• Prüfen, ob Zeichenkettenwerte, Datumsangaben und numerische Typen dem API-Vertrag entsprechen
• curl mit ausführlicher Ausgabe verwenden, um den rohen HTTP-Austausch zu prüfen:

curl -v -X POST https://api.example.com/endpoint 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d '{"key": "value"}'

Für Serveradministratoren:

• Server-Fehlerprotokolle abrufen und nach 400-Einträgen durchsuchen
• Webserver-Konfigurationssyntax validieren (nginx -t / apachectl -t)
• client_max_body_size (Nginx) und LimitRequestBody (Apache) prüfen
• large_client_header_buffers in Nginx überprüfen, wenn Cookie-intensive Anfragen fehlschlagen
• WAF-Regeln prüfen und das ModSecurity-Prüfprotokoll kontrollieren
• Gültigkeit und Abdeckung des SSL/TLS-Zertifikats überprüfen
• Sicherstellen, dass .htaccess-Rewrite-Regeln syntaktisch korrekt sind

—

FAQ

Was ist der Unterschied zwischen einem 400- und einem 404-Fehler?

Ein 400-Fehler bedeutet, dass der Server die Anfrage nicht verstehen konnte, weil sie fehlerhaft war — der Fehler liegt in der Art und Weise, wie die Anfrage konstruiert wurde. Ein 404-Fehler bedeutet, dass die Anfrage gültig und verständlich war, die angeforderte Ressource jedoch einfach nicht auf dem Server existiert. Sie erfordern völlig unterschiedliche Lösungsansätze.

Kann ein 400 Bad Request-Fehler durch den Server und nicht durch den Client verursacht werden?

Ja, indirekt. Eine Serverkonfiguration — wie eine zu restriktive WAF-Regel, eine falsche Nginx-large_client_header_buffers-Einstellung oder eine fehlerhafte .htaccess-Direktive — kann dazu führen, dass der Server technisch gültige Anfragen ablehnt. In diesen Fällen wird die HTTP-Spezifikation zwar noch eingehalten (der Server lehnt ab, was er als fehlerhafte Anfrage wahrnimmt), aber der eigentliche Fehler liegt in der Serverkonfiguration, nicht in der Anfrage des Clients.

Warum behebt das Löschen von Cookies einen 400-Fehler?

Cookies werden bei jeder Anfrage an die betreffende Domain im Cookie-Anfrage-Header gesendet. Wenn ein im Browser gespeicherter Cookie fehlerhaft ist, auf eine Weise abgelaufen ist, die der Server nicht akzeptiert, oder zu groß geworden ist (die large_client_header_buffers-Limits in Nginx überschreitet), lehnt der Server die gesamte Anfrage mit einem 400-Fehler ab, bevor er sie verarbeitet. Das Löschen des beschädigten Cookies entfernt die fehlerhaften Daten aus dem Header.

Wie behebe ich einen 400-Fehler beim Hochladen von Dateien auf meine Website?

Der Upload überschreitet entweder das Body-Größenlimit des Webservers oder das Upload-Größenlimit von PHP. Erhöhen Sie bei Nginx client_max_body_size in nginx.conf. Passen Sie bei Apache LimitRequestBody in .htaccess oder httpd.conf an. Aktualisieren Sie für PHP-Anwendungen upload_max_filesize und post_max_size in php.ini und stellen Sie sicher, dass post_max_size größer als upload_max_filesize ist. Starten Sie die entsprechenden Dienste nach den Änderungen neu.

Wie kann ich feststellen, ob ein 400-Fehler von einem CDN oder WAF und nicht von meinem Ursprungsserver kommt?

Überprüfen Sie die Antwort-Header. Cloudflare fügt cf-ray– und server: cloudflare-Header hinzu. AWS CloudFront fügt x-amz-cf-id hinzu. Wenn diese Header in der 400-Antwort vorhanden sind, erfolgte die Ablehnung am Edge, nicht an Ihrem Ursprungsserver. Überprüfen Sie die WAF-Protokolle des CDN oder das Firewall-Ereignis-Dashboard, um zu ermitteln, welche Regel die Blockierung ausgelöst hat, und erstellen Sie dann eine gezielte Ausnahme für das legitime Datenverkehrsmuster.