HTTP 400

Last change on 2025-09-04 • Created on 2025-05-06 • ID: ST-B80E5

Wenn du unerwartet einen HTTP-400-Fehler erhältst, könnte dies verursacht werden durch:

Inaktivität

Das Hochladen großer Datenmengen kann mehrere Minuten dauern. Um eine aktive Verbindung aufrechtzuerhalten, müssen kontinuierlich Daten übermittelt werden, auch wenn nur eine sehr geringe Datenmenge übertragen wird. Wenn der Client inaktiv ist, das heißt 60 Sekunden oder länger keine Daten gesendet hat, wird die Verbindung automatisch beendet.

Mögliche Ursachen für Inaktivität:

Ursache Beschreibung
Zwangstrennung Manche Internetanbieter erzwingen eine regelmäßige Trennung vom Internet (z.B einmal pro Tag).
Instabile Internetverbindung Wenn du vorübergehend kein Netz mehr hast, wurde der Upload unter Umständen bereits beendet, bevor die Verbindung wiederhergestellt werden konnte.
Geplante Wartung oder Updates Systemupdates können Netzwerkdienste unterbrechen.
Firewall Wenn Firewall-Einstellungen während einer aktiven Verbindung geändert werden, kann dies dazu führen, dass bestimmter Datenverkehr blockiert wird.
Fehlkonfiguration des Routers Wenn du ein privates Gerät mit einem Router verwendest, können falsche Einstellungen dazu führen, dass der Router Verbindungen unerwartet trennt.

Falscher Host-Header

Wenn Object Storage eine Anfrage erhält, muss der Host-Header – also der angeforderte Domainname – der Bucket-Domain entsprechen. Wenn im Host-Header eine Domain angegeben ist, die nicht der Bucket-Domain entspricht, wird die Anfrage verworfen.

Gängige Tools wie der MinIO Client und die AWS CLI setzen den Host-Header standardmäßig auf die Bucket-Domain.

Wenn du jedoch einen eigenen Client oder eine eigene Domain (siehe den FAQ-Eintrag "Kann ich einem Bucket eine eigene Domain / CNAME zuweisen?") verwendest, kann es passieren, dass in der Anfrage der falsche Host-Header angegeben wird.

  • Eigener Client

    Um zu prüfen, ob das Problem mit dem Host-Header zusammenhängt, benötigst du die Header, die dein Client mit der Anfrage sendet. Dein Client muss dafür eine Möglichkeit bieten, Debug-Informationen auszugeben, zum Beispiel über eine Flag wie --debug. Mit der AWS CLI würde es beispielsweise so aussehen:

    holu@example:/$ aws s3api get-object --debug --bucket <bucket_name> --key <object_name> <local_target_location>
[...]
GET
/<object_name>

host:<bucket_name>.fsn1.your-objectstorage.com
x-amz-content-sha256:<hash>
x-amz-date:<date>
[...]

    In dem oberen Beispiel wird in der Anfrage der richtige Host-Header angegeben — die Bucket-Domain. Wenn in deinem Output eine andere Domain angegeben ist, die nicht der Bucket-Domain entspricht, bestätigt das, dass dein Problem mit dem Host-Header zusammenhängt. In diesem Fall solltest du prüfen, ob es mit dem Client, den du verwendest, möglich ist, den Host-Header zu überschreiben.


  • Eigene Domain

    Führe die folgenden beiden Befehle aus, um zu prüfen, ob der Host-Header die Ursache deines Problems ist:

    Ersetze example.com mit deiner eigenen Domain, test.txt mit einer Datei in deinem Bucket und <bucket_name>.<region> mit dem Namen und der Region deines Buckets.

    holu@example:/$ curl --insecure https://example.com/test.txt
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

holu@example:/$ curl --insecure https://example.com/test.txt -H "Host: <bucket_name>.<region>.your-objectstorage.com"
Hello World! This is the content of the test file!

    Wenn das Hinzufügen des Host-Headers dein Problem löst, musst du den Host-Header auch in allen künftigen Anfragen überschreiben. Wenn du einen Reverse Proxy verwendest, kannst du den Host-Header direkt in der "Reverse Proxy"-Konfiguration ergänzen (z.B. mit NGINX). Wenn du einen CNAME-Record verwendest, hilft eventuell das How-To "Eigene Domain mit CNAME", das anhand von zwei Beispielen erklärt, wie man den Host-Header ändern kann.