Rclone upload very slow on Hetzner cloud storage

danImo-blg · December 19, 2025, 9:55am

What is the problem you are having with rclone?

Rclone upload seems to be exceptionally slow on Hetzner cloud storage. Other upload tools (like aws s3 cli) do not seem to have this issue.

Except for the upload speed, I do not see any obvious difference in the logs when uploading on Hetzner or any other cloud provider with the -vvv flag. Might have to checks the rclone source code to check what is happening under the hood.

Run the command 'rclone version' and share the full output of the command

rclone v1.72.0
- os/version: ubuntu 24.04 (64 bit)
- os/kernel: 6.8.0-90-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.25.4
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Hetzner, AWS, OVH

The command you were trying to run (eg `rclone copy /tmp remote:tmp`)

Using aws cli on Hetzner or any cloud providers, it takes around 30 seconds to upload a 1GB file:

aws s3 --debug cp --region nbg1 --endpoint-url https://nbg1.your-objectstorage.com/ /tmp/file1.txt s3://blg-backup-unittest/file1.txt

aws-debug-hetzner-upload.txt (1.8 MB)

→ time: 0:32.49

Using rclone on any other cloud provider (AWS, OVH), it also takes around 30 seconds to upload a 1GB file:

rclone copy /tmp/file1.txt --s3-no-check-bucket --s3-chunk-size 300M ":s3,provider=OVHcloud,env_auth=true,region=sbg,endpoint='https://s3.sbg.io.cloud.ovh.net/':blg-backup-unittest"

→ time: 0:25.30

But, using rclone on Hetzner, the upload speed drops and it takes a few minutes to upload a 1GB file:

rclone copy /tmp/file1.txt --s3-no-check-bucket --s3-chunk-size 300M ":s3,provider=Hetzner,env_auth=true,region=nbg1,endpoint='https://nbg1.your-objectstorage.com/':blg-backup-unittest"

→ time: 2:02.83

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

rclone config redacted
[cryptremote]
type = crypt
remote = s3remote:blg-backup-unittest

[s3remote]
type = s3
provider = Other
env_auth = true
region = sbg
endpoint = https://s3.sbg.io.cloud.ovh.net/
### Double check the config for sensitive info before posting publicly

A log from the command that you were trying to run with the `-vv` flag

On Hetzner:

2025/12/18 18:31:51 DEBUG : rclone: Version "v1.72.0" starting with parameters ["rclone" "copy" "-vv" "/tmp/file1.txt" "--s3-no-check-bucket" "--s3-chunk-size" "300M" ":s3,provider=Hetzner,env_auth=true,region=nbg1,endpoint='https://nbg1.your-objectstorage.com/':blg-backup-unittest"]
2025/12/18 18:31:51 DEBUG : Creating backend with remote "/tmp/file1.txt"
2025/12/18 18:31:51 DEBUG : Using config file from "/home/francois/.config/rclone/rclone.conf"
2025/12/18 18:31:51 DEBUG : fs cache: renaming child cache item "/tmp/file1.txt" to be canonical for parent "/tmp"
2025/12/18 18:31:51 DEBUG : Creating backend with remote ":s3,provider=Hetzner,env_auth=true,region=nbg1,endpoint='https://nbg1.your-objectstorage.com/':blg-backup-unittest"
2025/12/18 18:31:51 DEBUG : :s3: detected overridden config - adding "{BAmKG}" suffix to name
2025/12/18 18:31:51 DEBUG : fs cache: renaming cache item ":s3,provider=Hetzner,env_auth=true,region=nbg1,endpoint='https://nbg1.your-objectstorage.com/':blg-backup-unittest" to be canonical ":s3{BAmKG}:blg-backup-unittest"
2025/12/18 18:31:51 DEBUG : file1.txt: Need to transfer - File not found at Destination
2025/12/18 18:31:51 DEBUG : file1.txt: multi-thread copy: disabling buffering because source is local disk
2025/12/18 18:31:54 DEBUG : file1.txt: open chunk writer: started multipart upload: 2~ABqKgNg-mvq0G0mVsL_9-jMcZ4lPDrm
2025/12/18 18:31:54 DEBUG : file1.txt: multi-thread copy: using backend concurrency of 4 instead of --multi-thread-streams 4
2025/12/18 18:31:54 DEBUG : file1.txt: Starting multi-thread copy with 4 chunks of size 300Mi with 4 parallel streams
2025/12/18 18:31:54 DEBUG : file1.txt: multi-thread copy: chunk 4/4 (943718400-1000000000) size 53.674Mi starting
2025/12/18 18:31:54 DEBUG : file1.txt: multi-thread copy: chunk 2/4 (314572800-629145600) size 300Mi starting
2025/12/18 18:31:54 DEBUG : file1.txt: multi-thread copy: chunk 1/4 (0-314572800) size 300Mi starting
2025/12/18 18:31:54 DEBUG : file1.txt: multi-thread copy: chunk 3/4 (629145600-943718400) size 300Mi starting
2025/12/18 18:31:55 DEBUG : file1.txt: Seek from 56281600 to 0
2025/12/18 18:31:57 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/18 18:31:58 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/18 18:31:58 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/18 18:32:15 DEBUG : file1.txt: multipart upload wrote chunk 4 with 56281600 bytes and etag "264f266d5f4b19cc776dc440e0e917cf"
2025/12/18 18:32:15 DEBUG : file1.txt: multi-thread copy: chunk 4/4 (943718400-1000000000) size 53.674Mi finished
2025/12/18 18:32:51 INFO  : 
Transferred:   	  486.909 MiB / 953.674 MiB, 51%, 8.139 MiB/s, ETA 57s
Transferred:            0 / 1, 0%
Elapsed time:        59.9s
Transferring:
 *                                     file1.txt: 51% /953.674Mi, 8.238Mi/s, 56s

2025/12/18 18:33:48 DEBUG : file1.txt: multipart upload wrote chunk 3 with 314572800 bytes and etag "d1029ef8e75cc126bee56151d803f64f"
2025/12/18 18:33:48 DEBUG : file1.txt: multi-thread copy: chunk 3/4 (629145600-943718400) size 300Mi finished
2025/12/18 18:33:49 DEBUG : file1.txt: multipart upload wrote chunk 1 with 314572800 bytes and etag "cc52338c454b64d21efd14554839e292"
2025/12/18 18:33:49 DEBUG : file1.txt: multi-thread copy: chunk 1/4 (0-314572800) size 300Mi finished
2025/12/18 18:33:49 DEBUG : file1.txt: multipart upload wrote chunk 2 with 314572800 bytes and etag "6d446590f6c52c865d874e895f844f34"
2025/12/18 18:33:49 DEBUG : file1.txt: multi-thread copy: chunk 2/4 (314572800-629145600) size 300Mi finished
2025/12/18 18:33:49 DEBUG : file1.txt: multipart upload "2~ABqKgNg-mvq0G0mVsL_9-jMcZ4lPDrm" finished
2025/12/18 18:33:49 DEBUG : file1.txt: Finished multi-thread copy with 4 parts of size 300Mi
2025/12/18 18:33:49 DEBUG : file1.txt: size = 1000000000 OK
2025/12/18 18:33:49 DEBUG : file1.txt: md5 = 8bc5f047fb96e30435237160edba5cdf OK
2025/12/18 18:33:49 INFO  : file1.txt: Multi-thread Copied (new)
2025/12/18 18:33:49 INFO  : 
Transferred:   	  953.674 MiB / 953.674 MiB, 100%, 7.689 MiB/s, ETA 0s
Transferred:            1 / 1, 100%
Elapsed time:      1m58.3s

2025/12/18 18:33:49 DEBUG : 5 go routines active

On OVHcloud:

2025/12/19 10:07:43 DEBUG : rclone: Version "v1.72.0" starting with parameters ["rclone" "copy" "-vv" "/tmp/file1.txt" "--s3-no-check-bucket" "--s3-chunk-size" "300M" ":s3,provider=OVHcloud,env_auth=true,region=sbg,endpoint='https://s3.sbg.io.cloud.ovh.net/':blg-backup-unittest"]
2025/12/19 10:07:43 DEBUG : Creating backend with remote "/tmp/file1.txt"
2025/12/19 10:07:43 DEBUG : Using config file from "/home/francois/.config/rclone/rclone.conf"
2025/12/19 10:07:43 DEBUG : fs cache: renaming child cache item "/tmp/file1.txt" to be canonical for parent "/tmp"
2025/12/19 10:07:43 DEBUG : Creating backend with remote ":s3,provider=OVHcloud,env_auth=true,region=sbg,endpoint='https://s3.sbg.io.cloud.ovh.net/':blg-backup-unittest"
2025/12/19 10:07:43 DEBUG : :s3: detected overridden config - adding "{LXLuE}" suffix to name
2025/12/19 10:07:43 DEBUG : fs cache: renaming cache item ":s3,provider=OVHcloud,env_auth=true,region=sbg,endpoint='https://s3.sbg.io.cloud.ovh.net/':blg-backup-unittest" to be canonical ":s3{LXLuE}:blg-backup-unittest"
2025/12/19 10:07:43 DEBUG : file1.txt: Need to transfer - File not found at Destination
2025/12/19 10:07:43 DEBUG : file1.txt: multi-thread copy: disabling buffering because source is local disk
2025/12/19 10:07:45 DEBUG : file1.txt: open chunk writer: started multipart upload: ZWY4Y2RmNDUtZjMzMC00NzYyLTg3MDYtNzk2MDEwOGI2NDNm
2025/12/19 10:07:45 DEBUG : file1.txt: multi-thread copy: using backend concurrency of 4 instead of --multi-thread-streams 4
2025/12/19 10:07:45 DEBUG : file1.txt: Starting multi-thread copy with 4 chunks of size 300Mi with 4 parallel streams
2025/12/19 10:07:45 DEBUG : file1.txt: multi-thread copy: chunk 4/4 (943718400-1000000000) size 53.674Mi starting
2025/12/19 10:07:45 DEBUG : file1.txt: multi-thread copy: chunk 1/4 (0-314572800) size 300Mi starting
2025/12/19 10:07:45 DEBUG : file1.txt: multi-thread copy: chunk 2/4 (314572800-629145600) size 300Mi starting
2025/12/19 10:07:45 DEBUG : file1.txt: multi-thread copy: chunk 3/4 (629145600-943718400) size 300Mi starting
2025/12/19 10:07:46 DEBUG : file1.txt: Seek from 56281600 to 0
2025/12/19 10:07:48 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/19 10:07:49 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/19 10:07:49 DEBUG : file1.txt: Seek from 314572800 to 0
2025/12/19 10:07:51 DEBUG : file1.txt: multipart upload wrote chunk 4 with 56281600 bytes and etag "264f266d5f4b19cc776dc440e0e917cf"
2025/12/19 10:07:51 DEBUG : file1.txt: multi-thread copy: chunk 4/4 (943718400-1000000000) size 53.674Mi finished
2025/12/19 10:07:57 DEBUG : file1.txt: multipart upload wrote chunk 2 with 314572800 bytes and etag "6d446590f6c52c865d874e895f844f34"
2025/12/19 10:07:57 DEBUG : file1.txt: multi-thread copy: chunk 2/4 (314572800-629145600) size 300Mi finished
2025/12/19 10:08:05 DEBUG : file1.txt: multipart upload wrote chunk 3 with 314572800 bytes and etag "d1029ef8e75cc126bee56151d803f64f"
2025/12/19 10:08:05 DEBUG : file1.txt: multi-thread copy: chunk 3/4 (629145600-943718400) size 300Mi finished
2025/12/19 10:08:10 DEBUG : file1.txt: multipart upload wrote chunk 1 with 314572800 bytes and etag "cc52338c454b64d21efd14554839e292"
2025/12/19 10:08:10 DEBUG : file1.txt: multi-thread copy: chunk 1/4 (0-314572800) size 300Mi finished
2025/12/19 10:08:10 DEBUG : file1.txt: multipart upload "ZWY4Y2RmNDUtZjMzMC00NzYyLTg3MDYtNzk2MDEwOGI2NDNm" finished
2025/12/19 10:08:10 DEBUG : file1.txt: Finished multi-thread copy with 4 parts of size 300Mi
2025/12/19 10:08:10 DEBUG : file1.txt: size = 1000000000 OK
2025/12/19 10:08:10 DEBUG : file1.txt: md5 = 8bc5f047fb96e30435237160edba5cdf OK
2025/12/19 10:08:10 INFO  : file1.txt: Multi-thread Copied (new)
2025/12/19 10:08:10 INFO  : 
Transferred:   	  953.674 MiB / 953.674 MiB, 100%, 32.293 MiB/s, ETA 0s
Transferred:            1 / 1, 100%
Elapsed time:        27.3s

2025/12/19 10:08:10 DEBUG : 12 go routines active

darthShadow · December 19, 2025, 12:12pm

Try disabling HTTP2 with --disable-http2: Documentation

danImo-blg · December 19, 2025, 12:51pm

Yep, that was it !
Seems like Hetzner has some issues with http2

Thank you !

darthShadow · December 19, 2025, 1:14pm

It’s Go with issues with http2 and consequently rclone because of that.

Relevant Links:

github.com/golang/go

net/http: http/2 throughput is very slow compared to http/1.1

opened 01:54PM - 20 Aug 21 UTC

kgersen

NeedsInvestigation

### What version of Go are you using (`go version`)? 1.7 <pre> $ go version …go version go1.17 linux/amd64 </pre> ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? Linux, Windows, etc <details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/user/.cache/go-build" GOENV="/home/user/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/user/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/user/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.17" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/user/dev/http2issue/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build38525640=/tmp/go-build -gno-record-gcc-switches" </pre></details> ### What did you do? test http/2 vs http1.1 transfert speed with client and server from standard lib see a complete POC here: https://github.com/nspeed-app/http2issue The issue is general, loopback (localhost) or over the wire. ### What did you expect to see? same speed order than http1.1 ### What did you see instead? http/2 is at least x5 slower or worst

github.com/rclone/rclone

Slow download speeds with HTTP/2

opened 05:39PM - 12 Feb 25 UTC

lyc8503

bug

#### What is your current rclone version (output from `rclone version`)? ``` rc…lone v1.68.2 - os/version: centos 7.9.2009 (64 bit) - os/kernel: 3.10.0-1160.105.1.el7.x86_64 (x86_64) - os/type: linux - os/arch: amd64 - go/version: go1.23.3 - go/linking: static - go/tags: none ``` The problem also exists in latest rclone. #### What problem are you are trying to solve? Rclone has some options related to multi-thread downloads. By default, rclone will use 4 threads to download a file if the file is larger than 256MB. Users can also set thread count by their own. However, by default rclone reuses HTTP connection, so multiple (e.g. 4) HTTPs connections will be in the same TCP connection. There'll still be only one TCP connection to the server. In theory this won't help too much with download speed, especially in congested network. In my test: ``` # Runs at 500KB/s rclone copy -v -P onedrive: onedrive/ --multi-thread-streams 32 --multi-thread-write-buffer-size 1Mi # Runs at 33MB/s, 66x faster (My ISP only gives me 300Mbps, so that's near to full speed) rclone copy -v -P onedrive: onedrive/ --multi-thread-streams 32 --multi-thread-write-buffer-size 1Mi --disable-http-keep-alives ``` So I think we should disable HTTP connection reuse by default, if we already decide to multi-thread download a file. #### How do you think rclone should be changed to solve that? As described above, we should add some logic to disable HTTP keep-alive when multi-thread downloading, so that users don't have to disable keep-alive manually for all connections. I'm willing to open a pull request if current maintainers consider this change reasonable. #### How to use GitHub * Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are affected by the same issue. * Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue. * Subscribe to receive notifications on status change and new comments.

danImo-blg · December 19, 2025, 1:22pm

I see.

I was too focused on Hetzner (since it worked fine with other providers), I did not look into other known issues that could cause rclone upload to be slow, my bad.

Thanks for the links, i will have a look

random404 · December 20, 2025, 12:04pm

now I’m curious if I should disable http/2 for my rclone mount to improve performance. how one would check about this?

system · December 23, 2025, 12:04pm

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.