cargo: Cargo build failed with spurious network error

Possible solution for git bash users

Had the same issue, while trying to add rand = "0.8.3" as the rust-book instructs. I was getting the following error: failed to get `rand` as a dependency of package" `guessing_game v0.1.0`

Found a workaround online. Turns out i had to create the config file under ~/.cargo (wasn’t created automatically) and add a network configuration.

1. Add required configuration

#  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true 

1. Test if it works.

---

OS: Windows 10

cargo: 1.53.0 (4369396ce 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

@alexcrichton I am trying different projects in Windows Ubuntu 18.04 WSL - i.e. actix/examples. So cloned down the repo, go to the “hello-world” example and do cargo run. Get spurious network error. Firewall is turned off, no antivirus running, etc.

$ cargo build
    Updating crates.io index
warning: spurious network error (2 tries remaining): [7] Couldn't connect to server; class=Net (12)
warning: spurious network error (1 tries remaining): [7] Couldn't connect to server; class=Net (12)
error: failed to load source for a dependency on `actix`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  [7] Couldn't connect to server; class=Net (12)

Posting here in case this helps anyone else.

I seem to have “solved” this problem in my situation by using CARGO_HTTP_MULTIPLEXING=false cargo build. The issue was occurring mainly on when running cargo build as part of building a Docker image on Docker Hub and the same issue occurred when we tried using GitHub Actions build machines instead. Disabling HTTP/2 multiplexing forcing fallback to HTTP/1.1 seems to have “solved” the problem, repeated builds of two different affected Docker images have succeeded every time since the change.

The kind of issues I was seeing were of the form:

#12 52.13 Downloading crates ...
#12 202.3 warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `aho-corasick v0.7.18` failed to transfer more than 10 bytes in 30s)
#12 202.3 warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `adler32 v1.2.0` within 30s)
#12 292.3 warning: spurious network error (2 tries remaining): [92] Stream error in the HTTP/2 framing layer (HTTP/2 stream 53 was not closed cleanly before end of the underlying stream)

After lots of delays and retries the build would eventually fail with something like:

#12 1013.2 error: failed to download from `https://crates.io/api/v1/crates/tinyvec/1.4.0/download`
#12 1013.2
#12 1013.2 Caused by:
#12 1013.2 [92] Stream error in the HTTP/2 framing layer (HTTP/2 stream 59 was not closed cleanly before end of the underlying stream)
#12 ERROR: executor failed running [/bin/sh -c cargo build --target x86_64-alpine-linux-musl --release --locked]: exit code: 101

For context the base image was Alpine Linux 3.13.x with cargo installed using RUN apk add rust cargo which installed packages with version (1.47.0-r2). The docs for the Cargo setting are at https://doc.rust-lang.org/cargo/reference/config.html#httpmultiplexing.

My situation is because my git proxy is configured, and I temporarily turned off the git proxy to fix it.

git config --global --unset http.proxy  
git config --global --unset https.proxy

My situation is because my git proxy is configured, and I temporarily turned off the git proxy to fix it.

git config --global --unset http.proxy  
git config --global --unset https.proxy

It’s save my life. 😘

Possible solution for git bash users

Had the same issue, while trying to add rand = "0.8.3" as the rust-book instructs. I was getting the following error: failed to get `rand` as a dependency of package" `guessing_game v0.1.0`

Found a workaround online. Turns out i had to create the config file under ~/.cargo (wasn’t created automatically) and add a network configuration.

1. Add required configuration

#  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true 

1. Test if it works.

OS: Windows 10 cargo: 1.53.0 (4369396 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

This was the fix for me! Thank you very much. I experienced the problems when building with Docker (Alpine Base). It was a cross ARCH build. Interestingly when I was build native there was not an issue. If anyone points that into a direction that helps.

I have had the same problem today but I could fix it.

The way is: Open a file, ~/.gitconfig Found [url “github:”] section? Comment out or delete all of the section like this:

#[url "github:"]
#       InsteadOf = https://github.com/
#       InsteadOf = git@github.com

Have fun!

Reference: https://github.com/rust-lang/cargo/issues/2605 Reference (Japanese): https://kokeshing.com/unable-to-update-registry-error-cargo/

seeing loads of failing github actions in the last day or so due to these network issues

The source blocked in China. And i fix it by:

• ~/.cargo/config

[source.crates-io]
registry = "https://github.com/rust-lang/crates.io-index"
replace-with = 'ustc'
[source.ustc]
registry = "git://mirrors.ustc.edu.cn/crates.io-index"

I got the same issue on Windows 7 and it looks like the reason behind that is cargo cannot find its way through our corporate NTLM proxy.

I was troubleshooting this with plain curl. When I try to run

curl https://github.com/rust-lang/crates.io-index

I get the response

curl: (56) Received HTTP code 407 from proxy after CONNECT

which implies that I need to authenticate in the proxy. By using curl with -vv option I can see that it tries to authenticate using NTLM:

...
Proxy-Authenticate: Negotiate
Proxy-Authenticate: NTLM

* Ignore NNNN bytes of response-body
* Received HTTP code 407 from proxy after CONNECT
* Closing connection 0
curl: (56) Received HTTP code 407 from proxy after CONNECT

Then what I did I added the following environment variables via Control Panel (the addresses are distorted on purpose):

HTTP_PROXY=http://ntlm-proxy.org.com:8080
HTTPS_PROXY=http://ntlm-proxy.org.com:8080
PROXY_USER=NT_DOMAIN\username
PROXY_PASS=the_password  <-- I know, not ideal, but see below

After that I was able to receive the crates index using the following command:

curl -vv --proxy-any -U : https://github.com/rust-lang/crates.io-index

It worked, it also worked with --proxy-ntlm instead of --proxy-any, but if I don’t specify this parameter, I get the 407 error again. Instead of adding environment vars for user and password, I also was able to specify --proxy-user NT_DOMAIN\username and provide the password interactively - and it also worked.

So it looks like at the moment rust’s cargo lacks support for NTLM proxy specifics, including authentication. Given that curl does support this, I think it is just a matter of adding this support in future versions.

Ideally, it would be nice to be able to to specify in ~/.cargo/config:

[http]
proxy = "host:port" # HTTP proxy to use for HTTP requests (defaults to none)
proxy-auth = "ntlm" # negotiate, basic, digest, etc... 
proxy-user = "username"
proxy-password = "password"
...          

Hm is this perhaps a network-level issue where github.com or github.com/rust-lang is blocked? Otherwise I’m not sure how we’d fix this as it seems Cargo can’t connect 😦

now i fixed it. in china, we need to set a china source for the crates: cd $HOME/.cargo nano config cat config

it shows:

[net] retry = 2 # network retries git-fetch-with-cli = true

[source.crates-io] registry = “https://github.com/rust-lang/crates.io-index” replace-with = ‘ustc’

[source.ustc] registry = “git://mirrors.ustc.edu.cn/crates.io-index”

cd /path/to/some-rust-project/ cargo build --release

then u are set.

The project comes from a tutorial. The following is Cargo.toml.

[package]
name = "guessing_game"
version = "0.1.0"
authors = ["account"]

[dependencies]
rand = "0.3.14"

During my investigations on this issue I have found a workaround, which at least works in my network topology with NTLM corporate proxy.

First of all, there are two channels, through which cargo is communicating with crates index. One is libcurl (when accessing crates index file) and the other is libgit2 (when actually doing the subsequent search and fetch from the index). While for the first part your http_proxy / HTTP_PROXY settings at environment level might work, the reason it breaks is actually lying underneath - it breaks when libgit2 code is trying to actually fetch the index repo from GitHub via git protocol.

Some enterprises strictly prohibit access to https://github.com, but reasonable ones enable and control the access via corporate directories, e.g. Active Directory groups, and the user can be authorised when requests are going through NTLM proxy with authentication - authenticated users can be checked against the ACL in Active Directory and allowed access. So the question is how to invoke this authorisation each time a request is made.

If the above is true, one can usually fetch GitHub repos from behind the proxy with a command-line git via configuring proxy in git config (see below).

So while https://github.com/rust-lang/cargo/issues/7330 is still in the works, here’s my workaround.

• I have made sure my command-line git finally works by adding configs for the NTLM proxy and my company’s CA bundle which contains the certificate chain and root CA certificate which signs certificates for company’s internal services (should be provided by your company):

  git config --global http.https://github.com/.proxy https://:@ntlm-proxy.your-company.com:8080
  git config --global http.https://github.com/.sslcainfo C:\<path-to-ca-bundle.crt>
  

  You may also try the line below if getting SSL certificate-related errors:

  git config --global http.sslverify false
  

• I modified my Cargo config file: in ~/.cargo/config: I have switched to command-line git instead of using libgit2 code:

  [net]
  git-fetch-with-cli = true
  

• One last step that did the trick. Define your environment variables (http_proxy / HTTP_PROXY depending on your platform) with your username/password provided, e.g. on Windows define your environment variable HTTP_PROXY this way:

  http://domain%5Cusername:password@ntlm-proxy.your-company.com:8080
  

  Note the domain which should be the Windows domain of your account; then make sure your username and password are correctly URL-quoted (you may use online service such as https://www.urlencoder.org to check encoding for the special symbols, do not paste your entire password to those online services). Note that %5C above stands for the backslash delimiting domain from username.

Then that should be it. It worked for me - cargo was finally able to fetch the dependencies. Let me know if it helped in any way.

The only workaround that worked for me on my Dockerfile was

ENV CARGO_NET_GIT_FETCH_WITH_CLI=true

I tried all other workarounds but they did not work Commit : https://github.com/sudo-bot/docker-rustpython/commit/283fdda7f5f01aa111683d541f77bc965f1b10e2

It happened to me also, I’m using simple docker build -t myapp . command. here is my Dockerfile.

FROM rust:1.40-alpine

WORKDIR /usr/src/myapp

COPY . .

RUN cargo install --path .

CMD ["myapp"]

#  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true 

1. Test if it works.

OS: Windows 10 cargo: 1.53.0 (4369396 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

This was the fix for me! Thank you very much. I experienced the problems when building with Docker (Alpine Base). It was a cross ARCH build. Interestingly when I was build native there was not an issue. If anyone points that into a direction that helps.

That solution helped me get through the initial download issue (listed by OP). But now it fails with “Peer certificate cannot be authenticated with given CA certificates (SSL certificate problem: certificate has expired)” on https://crates.io/api/v1/adler/1.0.2/download

MacOS 10.14.5 Cargo 1.70.0-nightly Firewall is off.

I have 0 issues with this on Windows or Linux, but for some reason MacOS can’t build.

UPDATE: Calling cargo run multiple times resolves the new ssl issue. https://github.com/rust-lang/cargo/issues/11670 Still strange, and would be nice if that wasn’t required.

It’s amazing this is still open in 2023! My fix was to allow the crate.exe through Windows Defender Firewall.

In my case I am setting up a new rust-up cargo install on a Windows 10 machine with latest git cli installed. I used the 64-bit Windows installer from the downloads page because the chocolatey installer appeared out of date with 1.25.1 instead of 1.25.2 and flagged with some scan warnings.

https://community.chocolatey.org/packages/rustup.install

Was testing the setup using the examples crate.

cargo install mdbook --vv

The --vv command didn’t show any additional details.

Windows Firewall was not blocking the git client and was able to run both the inbuilt cargo git and use git cli git fetch options.

This worked fine both inside and outside of cargo, turning on and off the git fetch with cli option. Note the newer gh cli might be a good option to add to the list.

git fetch --force --update-head-ok https://github.com/rust-lang/crates.io-index +HEAD:refs/remotes/origin/HEAD -v

It was not the git step which was failing, it was the accessing of crates.io URL via a dynamic 6xxxx port.

Tested with curl and got following error

curl -vvv https://crates.io/api/v1/crates/mdbook/0.4.26/download

curl: (7) Failed to connect to crates.io port 443: Bad access

Allow an app through Windows Firewall might work, though I went the port route. https://support.microsoft.com/en-us/windows/risks-of-allowing-apps-through-windows-defender-firewall-654559af-3f54-3dcf-349f-71ccd90bcc5c

I am using Malwarebytes Windows Firewall which added this pretty broad rule: %USERPROFILE%.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\crate.exe Allow Out Local ports: Any Remote addresses: Any Remote Ports: Any Protocol: Any

Adding add rule to Windows Defender Firewall to the Windows installer or finding alternative approach might solve this particular issue.

@weiby3 你好。 我也遇到这个问题，你解决该问题没有？ 我至今未能解决。能否给点提示？ 非常感谢你的回复

@briteming 后面没事了，我也不知道怎么解决的

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

I have the same issue with WSL. It seems to be related with filesystem.

With a folder mapped to my Windows filesystem:

yale@MATEBOOK-YALE:~/Work/myweb$ /home/yale/.cache/.wrangler/cargo-generate-fc3c677afe428cb1/cargo-generate generate --verbose --git https://github.com/cloudflare/worker-sites-init --name workers-site

 Creating project called `workers-site`...
warning: spurious network error (2 tries remaining): failed to mmap. Could not write data: Permission denied; class=Os (2)
warning: spurious network error (1 tries remaining): failed to mmap. Could not write data: Permission denied; class=Os (2)
Error:  Git Error: failed to clone into: /c/Users/Yale/Work/myweb/workers-sitelxBp3L

With /tmp:

yale@MATEBOOK-YALE:/tmp/myweb$ /home/yale/.cache/.wrangler/cargo-generate-fc3c677afe428cb1/cargo-generate generate --verbose --git https://github.com/cloudflare/worker-sites-init --name workers-site
 Creating project called `workers-site`...
Ignoring: /tmp/myweb/workers-site/.genignore
Ignoring: /tmp/myweb/workers-site/LICENSE_APACHE
Ignoring: /tmp/myweb/workers-site/LICENSE_MIT
 Done! New project created /tmp/myweb/workers-site

There are quite some bugs about mmap in WSL:

• https://github.com/microsoft/WSL/issues?q=is%3Aissue+is%3Aopen+mmap

I found that it was indeed a network problem and solved it. If you do not have alternative choice to fetch what you want, you can try using SS or SSR, just go Option Settings (选项设置)->Local Proxy (本地代理), tick “Allow connections from LAN” (允许来自局域网的连接) and set Local Port (本地端口) = 1080. Then append the following to your .zshrc or .bashrc file:

alias proxy="git config --global http.proxy http://127.0.0.1:1080"
alias unproxy="git config --global --unset http.proxy"

Then cargo starts fetching successfully.

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

Thannks. It works.

I use a similar solution with an additional “git@github.com” (for accessing private repo on github). It seems like the daemon service of git protocol doesn’t work well with my proxy.

$ cat ~/.cargo/config.toml
[net]
git-fetch-with-cli = true

$ cat ~/.gitconfig
[url "ssh://git@github.com"]
	insteadOf = git://github.com

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

Thannks. It works.

I had the same issue redently. Thank for@sikinmettugi 's inspiration. I had solved it by close my VPN proxy service. A word of warning: If you’re using a VPN proxy software in mainland China, it may cause the same spurious network error. All you need to do is turn off the system proxy.

Yesterday i had the same issue which lead me to digg into the problem . I just wanted to point out @weiby3 @alexcrichton the possibility that this may happens when cargo try to write into cache folder and because:

1. you are working on docker container
2. you are working in a remote development ide (which use docker mostly)
3. the user you are using does not belong to sudo group
4. you had a different/weird installation which lead to a improper permissions on cache folder

and the user you work with won’t have the required permissions under the cache folder i.e /usr/local/cargo/registry/cache (this would depends on you cargo installation). so. giving the right permission with i.e

1. sudo chown -R $(whoami) /usr/local/cargo/registry/cache
2. also you could use mode to give writing permission to the user
3. add the working user to a sudo group.

Possibly should we consider a relation with this issue too https://github.com/rust-lang/cargo/issues/6757

If anyone on gentoo comes across this error, its apparently by design with portage. I dont even have a .cargo folder in my home directory so gentoo and librsvg-9999 git master cant be a thing on gentoo as of this post.

https://forums.gentoo.org/viewtopic-t-1134891-highlight-.html

EDIT: You can use “FEATURES=”-network-sandbox" in your make.conf file to bypass the emerge network sandbox and avoid this error.

@JohnCoconut This hadn’t broken anything else for me, but I don’t have any other packages that depend on http-parser, other than libgit2, and rust is the only thing that depends on libgit2 for me. I had just updated http-parser earlier that day. I don’t remember exactly what led me to it, but I tracked it into libgit2 through some of the error messages, looked through my recent updates, and found this arch linux bug that mentioned something of the sort, and then a quick rebuild of libgit2 sorted me out. I didn’t find anything in searches related to Gentoo, but I figured I’d put a PSA in here. Maybe somebody should open something in the Gentoo bug tracker. I’ll see if I can do that now. edit: Gentoo ticket opened now. Thanks for reminding me that the Gentoo community deserves a heads up.

PSA for people coming to this without any proxies in the mix (especially those who are on Gentoo like I am). This kind of issue can be caused by updating between the library http-parser versions 2.9.2, 2.9.3, and 2.9.4, as they apparently broke ABI compatibility. For me, rebuilding and reinstalling libgit2 fixed the issue.

Write permissions seems like a cause as well. I got this error using docker centost:8 mounting my app to /root. Even though I try to cargo build as root I get those Could not write data: Permission denied;... errors. I fixed it by simply mounting to another location.

Solution that worked for me was updating my /etc/hosts file with new IP addresses for GitHub.

+1 for this error even though git connectivity is available. Suggest this may be an SSL error.

For the recent reports, particularly for people using cargo provided via your Linux package manager, you may want to check which version of libcurl your package manager is using. 7.69.0 had a critical flaw in its HTTP2 handling that causes timeouts. I think 7.69.1 should fix it (or 7.68). See #7974 for more detail.

If you use the pre-built binaries distributed by rustup, they shouldn’t have this problem, since they statically link a version of libcurl that does not have that problem.

I found the source of the problem in our environment. Obviously the ZScaler proxy modifies the header of some HTTPS responses, specifically the Transfer-Encoding: chunked entry. It replaces it with _ransfer-Encoding: chunked. GnuTLS chokes on this, making the transfer fail. The solution was to rebuild everything with OpenSSL as backend. You can read more about that on https://github.com/curl/curl/pull/3148

Similar problem here. I’m behind corporate proxy. Cloning the crates.io index from Github works fine but cargo fails with

warning: spurious network error (2 tries remaining): [56] Failure when receiving data from the peer; class=Net (12)
warning: spurious network error (1 tries remaining): [56] Failure when receiving data from the peer; class=Net (12)
error: failed to load source for a dependency on `libc`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  [56] Failure when receiving data from the peer; class=Net (12)

There’s also a RST in the wireshark log somewhere during the transfer.

I try git clone and curl https://github.com/rust-lang and they works fine. On my computer github.com can be accessed successfully, I have search the firewall and there aren’t any block rule related to it. Maybe these are some useful information. I use HUORONG SECURITY as my anti-virus software, and if there is a program trying to connect to Internet, it will popup a windows and ask for permission. Strangely when I run cargo run --verbose there is no popup window, but if I run curl https://github.com/rust-lang there is a popup window, so it seems Cargo can’t connect. Is it possible to get more error information?