Heads-up: libtorch downloads now redirect to download-r2.pytorch.org by default — use curl -L

release/packaging
1

Starting next week (week of June 9, 2026), libtorch archive downloads from download.pytorch.org will be served from our R2-backed host, download-r2.pytorch.org, for faster and more reliable downloads.

:warning: Important: If you script libtorch downloads in CI or build systems, please add -L (or confirm your tool follows redirects) ahead of next week.

Your existing URLs do not change — download.pytorch.org/libtorch/… keeps working. Under the hood, a request for a libtorch .zip now issues a 301 redirect to the equivalent path on download-r2.pytorch.org.

What you need to do: make sure your downloader follows redirects. With curl, that means adding the -L flag:

# Follow the redirect to R2
curl -L -O https://download.pytorch.org/libtorch/cpu/libtorch-shared-with-deps-latest.zip

# Example with a pinned version
curl -L https://download.pytorch.org/libtorch/cu130/libtorch-shared-with-deps-2.12.0%2Bcu130.zip -o libtorch.zip

If you omit -L, curl will just print the 301 response instead of downloading the file. wget follows redirects by default, and CMake FetchContent / file(DOWNLOAD …) and most build tools handle this automatically.

Notes:

  • Only the actual .zip download artifacts redirect. The /libtorch/ index and folder listing pages are unchanged.
  • pip / whl installs of PyTorch are unaffected — this only concerns the libtorch C++ archives.

If you script libtorch downloads in CI or build systems, please add -L (or confirm your tool follows redirects) ahead of next week.

2

Connections to https://download-r2.pytorch.org fail at the TLS handshake stage with a handshake_failure alert (TLS alert 40), before any Server Hello, certificate, or ALPN negotiation occurs. This happens on both TLS 1.2 and TLS 1.3, and reproduces from multiple unrelated networks — including GitHub-hosted Actions runners — ruling out a local network/client misconfiguration.

Environment

  • Client: curl 8.5.0 / OpenSSL 3.0.13 (also reproduced with openssl s_client directly)
  • Resolved IPs: 104.18.8.52, 104.18.9.52 (Cloudflare)
  • Reproduces from: local Linux workstation, and independently from GitHub Actions runners

Reproduction

bash

$ openssl s_client -connect download-r2.pytorch.org:443 -servername download-r2.pytorch.org -tls1_3
CONNECTED(00000003)
...:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:918:SSL alert number 40
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 7 bytes and written 1492 bytes
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
No ALPN negotiated

Same result forcing TLS 1.2:

bash

$ curl -vv --tlsv1.2 --tls-max 1.2 https://download-r2.pytorch.org
...
* TLSv1.2 (IN), TLS alert, handshake failure (552):
* TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure
curl: (35) TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure

What’s been ruled out

  • TLS version negotiation bug — fails identically on 1.2 and 1.3, so it’s not a version-specific cipher/group mismatch.
  • Local network interference (corporate firewall, VPN, DPI) — reproduces independently on GitHub-hosted Actions runners, which are on a completely different network path.
  • General Cloudflare platform outage — Cloudflare’s status page shows R2 and CDN/Cache as fully Operational, with no open incidents matching this symptom.

Suspected cause

Given the above, and that download-r2.pytorch.org is a very recently migrated R2-backed host (per the June 4, 2026 dev-discuss announcement), this looks like a zone-level Cloudflare configuration issue — likely TLS fingerprint-based bot mitigation (Bot Fight Mode / WAF managed rules) rejecting non-browser TLS client fingerprints (curl, OpenSSL, and by extension pip/requests, which share the same TLS stack) at the handshake layer before any HTTP request is even made.

This would affect any CI pipeline, Docker build, or scripted install using pip install torch / curl/wget against this host, without affecting browser-based access — which would explain why it might not have been caught yet.

Request

Could someone from the PyTorch infra team check the Cloudflare zone settings (Bot Fight Mode, Super Bot Fight Mode, or WAF managed rules with TLS fingerprinting) for download-r2.pytorch.org and confirm whether non-browser clients are being intentionally blocked, or if this is unintended?

1 Like
3

Seem to be better now!

4

Hi @choatej-pickle Thank you for reaching out, the issue you mentioned caused a SEV yesterday https://download-r2.pytorch.org/ down · Issue #189056 · pytorch/pytorch · GitHub . This is resolved now.