cargo: error: failed to download: [28] Timeout was reached" downloading from the registry after cargo update

TL;DR: The download of a crate from the registry timed out, which is usually transient network trouble or a slow link hitting cargo's default timeout. Retry the build first; timeouts often clear on their own. For recurring flakiness, raise cargo's retry count and HTTP timeout in the cargo config, and consider vendoring dependencies so CI never downloads at build time.

cargo: error: failed to download: [28] Timeout was reached

1. Retry the build once before changing anything. Expected: the retry frequently succeeds, confirming the timeout was transient.

2. Make cargo more patient via its config file: raise net.retry and set http.timeout to a higher value such as 60. Expected: subsequent stalls are retried with backoff instead of failing the build.

3. Check the registry is actually reachable: curl -sI https://static.crates.io/. Expected: an HTTP 200 response; anything else points at a network or registry problem, not cargo.

4. If the machine sits behind a proxy, make sure cargo's http.proxy setting is configured. Expected: downloads flow through the proxy without stalling.

5. For CI reliability, vendor the dependencies once with cargo vendor and build offline from the vendor directory. Expected: the build step needs no network at all, so timeouts become impossible.

Use this when

• Cargo fails with the exact "[28] Timeout was reached" message.
• The failure follows a cargo update that newly downloads many crates.
• CI runners on slow or congested networks hit it intermittently.

Not for this skill when

• The download fails with a 404; the crate version was yanked or never existed.
• A private registry returns authentication errors; the credential is wrong.
• DNS resolution fails; the network path itself is broken.

Variant phrasings

• "cargo failed to download timeout reached crates.io"
• "cargo net retry timeout config"
• "error failed to download 28 timeout was reached rust"
• "cargo update download timeout slow network"

Why it happens

[28] is libcurl's operation-timed-out code. Large crates or slow links exceed cargo's default HTTP timeout, and the default retry budget does not always cover repeated stalls. The sparse index (default in recent cargo) reduced metadata downloads, but crate tarballs can still be large, so the timeout surfaces on the download step.

Edge cases

• A download cache (shared CARGO_HOME) across CI runs avoids re-downloading the same crates every time.
• Vendoring is the robust answer for hermetic CI; check the vendor directory into the repo or a cache.
• Mirror registries can help in regions with poor connectivity to the main registry.
• Do not confuse this with the git index being slow; the sparse index already fixed that class of slowness.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JrEB-jjgWHjXU98TVM05BQ