Rustup Pull-Through Cache

Problem you are trying to solve

The Internet seems to be decomposing and Open Source project download channels are collapsing in the process. Rustup is not immune unfortunately and we're seeing a significant increase in CI failures and hearing from devs across various client environments which rely on rustup mostly due to:

error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz", source: TimedOut })
info: retrying download for 'https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz'
error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz", source: TimedOut })
info: retrying download for 'https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz'
error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz", source: TimedOut })
info: retrying download for 'https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz'
error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-unknown-linux-gnu.tar.xz", source: TimedOut }

Not sure if upstream has rate limiting or if intermediate providers are unhappy with the IO patterns and blocking folks (we're seeing this at various sites in the US and EU).

Solution you'd like

Proposing a rustup proxy serve command which would allow an instance of the binary to serve as a caching proxy for other instances and use of an env var or cli flag to direct instances of rustup performing the installation to get service from the proxy forcing a pull-through on new content and pull-back for cached content.

Should help reduce the load on public servers considerably if CIs were to leverage an innate function for the binary for this instead of having to wire up their own solutions (or just not bother and maul public servers with bandwidth consuming requests).

Notes

For some context: we're a security outfit (predating Rust's existence), manage risk for organizations far larger than the original parent co.

Consolidation of infrastructure carries risk profiles to the ecosystem to include

1. being blocked by regimes and providers
2. targeted for "lawful takeover" by hostile entities to use your resource platform against their adversaries
3. scaled down by intermediate parties (QoS) and MiTMd
4. provide centralized points for denial of service attacks
5. the fun stuff we're seeing over at RubyGems which smells a bit like the fall of freenode but likely bad for the Ruby community in any case.

Enabling users of the ecosystem to be the ecosystem diffuses the risk profile and decentralizes some of cost borne by the organization hosting all of these downloads. Natively supported cache tiering and third-party mirroring, P2P distribution, and the attestation + validation mechanisms which are required to ensure safety of such approaches would cost less than the bandwidth and DoS protection budget today and far less than the PR nightmare of cleaning up any of the concerns listed above (unless the entity is owned by NK through a proxy shell co at that point) will cost when they hit the fan.

The issue names no files or tests; start by reviewing the rustup CLI entry point for a proposed proxy serve command and the installation download path. Completion would require a pull-through cache plus an environment variable or CLI flag that directs installers to it, covering both cached and new content.