# Heads-up: libtorch downloads now redirect to download-r2.pytorch.org by default — use curl -L **URL:** \ **Category:** release/packaging\ **Created:** [June 4, 2026, 6:54pm UTC](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395 "2026-06-04T18:54:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![atalman](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/atalman/32/1857_2.png) [@atalman](https://dev-discuss.pytorch.org/u/atalman)\ **Post date:** [June 4, 2026, 6:54pm UTC](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395/1 "2026-06-04T18:54:55Z")
Starting next week (week of June 9, 2026), libtorch archive downloads from [download.pytorch.org](http://download.pytorch.org) will be served from our R2-backed host, [download-r2.pytorch.org](http://download-r2.pytorch.org), for faster and more reliable downloads. ⚠ 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/](http://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](http://download-r2.pytorch.org). What you need to do: make sure your downloader follows redirects. With curl, that means adding the -L flag: ```auto # 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. ---
**Author:** ![choatej-pickle](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/choatej-pickle/32/3293_2.png) [@choatej-pickle](https://dev-discuss.pytorch.org/u/choatej-pickle)\ **Post date:** [July 6, 2026, 6:45pm UTC](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395/2 "2026-07-06T18:45:47Z")
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 ```auto $ 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: --- 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 ```auto $ 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](https://www.cloudflarestatus.com/) 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](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395)), 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? ---
**Author:** ![choatej-pickle](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/choatej-pickle/32/3293_2.png) [@choatej-pickle](https://dev-discuss.pytorch.org/u/choatej-pickle)\ **Post date:** [July 6, 2026, 7:38pm UTC](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395/3 "2026-07-06T19:38:18Z")
Seem to be better now! ---
**Author:** ![atalman](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/atalman/32/1857_2.png) [@atalman](https://dev-discuss.pytorch.org/u/atalman)\ **Post date:** [July 7, 2026, 5:05pm UTC](https://dev-discuss.pytorch.org/t/heads-up-libtorch-downloads-now-redirect-to-download-r2-pytorch-org-by-default-use-curl-l/3395/4 "2026-07-07T17:05:03Z")
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](https://github.com/pytorch/pytorch/issues/189056) . This is resolved now.