HTTP 400 - Hetzner Docs

If you receive an unexpected HTTP 400 error, it could be caused by:

Inactivity
Wrong host header

Inactivity

Uploading large amounts of data may take several minutes. To maintain an active connection, progress must be made continuously, even if only a very small amount of data is being transferred. If the client is inactive, i.e. has not sent any data for 15 seconds or more, the connection will be automatically terminated.

Possible reasons for inactivity:

Reason	Description
Forced disconnect	Some Internet providers enforce periodic disconnections from the Internet (e.g. once a day).
Unstable Internet connection	If you temporarily lose your Internet connection, the upload may have already been terminated by the time you reconnect.
Scheduled maintenance or updates	System updates may interrupt network services.
Firewall	If firewall settings are modified while a connection is active, it may start blocking certain traffic.
Router misconfigured	If you're using a private device with a router, incorrect settings may cause the router to drop connections unexpectedly.

Wrong host header

When Object Storage receives a request, the host header — which specifies the requested domain name — has to be the Bucket domain. If the host header is any domain other than the Bucket domain, the request will fail. Common tools like the MinIO Client and the AWS CLI set the host header to the Bucket domain by default.

However, if you're using a custom client or a custom domain (see the FAQ entry "Can I assign a custom domain name / CNAME to a Bucket?"), the request may use a different host header.

Custom client

You need to check the headers of the request. Your client needs to provide a way to output debug information, for example, using a flag like --debug. With the AWS CLI, it would look like this, for example:
```
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 the example above, the request uses the correct host header — the Bucket domain. If your output shows any domain other than the Bucket domain, it confirms that the host header is the cause of your issue. If this is the case, you have to check if it is possible to overwrite the host header with the client you're using.

Custom domain

Run these two commands to confirm if the host header is in fact your issue:

Replace example.com with your own domain, test.txt with a file in your Bucket, and <bucket_name>.<region> with the name and region of your Bucket.
```
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!
```
If adding the host header solves your problem, you need to overwrite the host header in all future requests as well. If you're using a reverse proxy, you can simply define the host header in the reverse proxy configuration (e.g. with NGINX). If you're using a CNAME record, see the how-to guide "Custom domain with CNAME" which explains two examples on how to change the host header.