Fix it fast
Most likely: The offline stage does not contain every index entry, crate archive, or git source required by the current lockfile and targets.
Confirm this is your error
Match the output and confirm you are troubleshooting the same failure.
error: attempting to make an HTTP request, but --offline was specified
error: attempting to make an HTTP request, but --frozen was specifiedCheck the cause
Run focused checks to identify what is failing in this environment.
cargo -Vv
grep -nE "offline[[:space:]]*=" .cargo/config.toml "${CARGO_HOME:-$HOME/.cargo}/config.toml" 2>/dev/null
git status --short -- Cargo.toml Cargo.lockApply the safe fix
Use the smallest safe change that addresses the confirmed cause.
# Run in an approved connected preparation stage.
cargo fetch --locked
# Then reuse the prepared Cargo home or vendor source in the offline stage.Verify it works
Repeat the relevant checks and confirm the original error is gone.
cargo check --locked --offlineAvoid unsafe shortcuts
Keep security and data protections in place while troubleshooting.
- Do not remove
--lockedjust to hide missing dependency preparation. - Do not grant network access to an air-gapped job without changing the documented security boundary.
Where the Request Failed
Cargo is telling you the request failed before it got a clean response back. Treat the connection path and the failing environment as the first suspects, not the package or image name.
Restore connectivity to the registry
Start by proving the failing machine can reach the right host cleanly. Until DNS, routing, proxy, and trust look sane in that exact environment, retrying the install or pull is mostly noise.
Connected pipeline:run cargo fetch --locked with the same lockfile and targets before entering the offline stage.
Vendored pipeline:regenerate vendor content from the reviewed lockfile and copy both vendor files and source-replacement config into the offline image.
Container cache loss:keep the fetched Cargo home or vendor directory in a stable earlier layer available to the final build user.
Unexpected strict flag:remove net.offline only when the workflow is allowed to use the network, while preserving --locked if reproducibility is still required.
Air-gapped environment:transfer the complete approved registry or vendor data instead of allowing an unreviewed network exception.
Find which dependency data is missing
Capture the first URL or package Cargo tried to access, not only the final offline wrapper line.
Confirm whether the command used --offline, --frozen, net.offline = true, or an environment override inherited by the runner.
Inspect the build stage that should run cargo fetch --locked and verify it uses the same Cargo.lock, target triples, Cargo home, and registry configuration.
If vendoring is intended, check that .cargo/config.toml redirects the source and that the required crate exists in the vendor directory.
Why Resolution Broke
The build entered offline mode before any connected stage fetched the dependency graph.
The lockfile or target set changed after the cache or vendor snapshot was created.
A container build discarded the Cargo home layer between fetch and offline build stages.
A git dependency, build target, or private registry package was not included in the prepared local source set.
Prove the Failing Environment Can Reach It
Disable network access and rerun the original strict command in the same image or runner. It should proceed without attempting any HTTP request.
Confirm the build still passes with --locked when deterministic dependency state is part of the requirement.
What offline and frozen modes require locally
This is the part worth understanding if the quick fix did not hold. It explains what Cargo is trying to do at the moment the error appears.
--offline restricts Cargo to locally available index and crate data. --frozen adds the same network restriction while also requiring the lockfile to remain unchanged.
A successful hermetic build therefore needs the exact lockfile, registry metadata, crate archives, git checkouts, target dependencies, and source replacement prepared before the strict stage begins.
Prevent Repeat Connectivity Failures
To prevent this, separate connected fetch and disconnected build stages explicitly in CI and container definitions, key dependency caches by lockfile, target set, Cargo version, and registry configuration, and test offline builds regularly so missing vendor or cache inputs are detected before an air-gapped release.
Docs and source code
cargo fetch
Official prefetch workflow for later offline or locked builds. - Source
Fetch dependencies of a package from the network.Cargo Dependency Resolution
Official explanation of version selection, lockfiles, yanked releases, features, and resolver conflicts. - Source
This process is called dependency resolution and is performed by the resolver.