Cargo-registernedlastinger virker, men Git-avhengigheter mislykkes

Les URL-en til kilden som feilet før du endrer Cargos proxy. Registermetadata, et crate-arkiv og en Git-avhengighet kan bruke ulike hente- og autentiseringsbaner. En SSH Git-URL trenger også en annen transportordning enn HTTPS.

For Cargos relevante HTTP-forespørsler kan ruten settes slik:

[http]
proxy = "http://203.0.113.10:8080"

Bytt ut dokumentasjonens endepunkt med HTTP-proxyen din. For en offentlig registerbane som har lov til å bruke offentlige proxyer, finnes kandidater i HTTP-proxylisten. Dette viser ikke at en ekstern Git-kjørbar fil mottok samme konfigurasjon.

Hvis kilden som feiler er Git, kan Cargo velge Git CLI i stedet for den innebygde implementasjonen:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true velger den for én kommando. Ekstern Git trenger nå sin egen proxykonfigurasjon og legitimasjon. Sammenlign samme Git-URL i samme oppstartsmiljø; et urelatert repository som virker i en annen terminal er ikke testen.

Manglende revisjon, avvist tilgang til repository eller SSH host-key-feil er fortsatt det samme problemet etter bytte av implementasjon. Alternativet velger en støttet klient, ikke en generell reparasjon av avhengigheter.

Hold diagnosen på prosjekt- eller kommandonivå: globale Git- og Cargo-innstillinger for brukeren kan påvirke andre arbeidsområder. En register-URL velger pakkedata, ikke en mellommann. Når Git-banen virker, kjør hele den tiltenkte Cargo-operasjonen på nytt, fordi arkiver, omdirigeringer og nedlastinger under bygging kan introdusere andre baner.