Leia a URL da fonte que falhou antes de alterar o proxy do Cargo. Metadados do registro, um arquivo crate e uma dependência Git podem usar caminhos diferentes de obtenção e autenticação. Uma URL Git por SSH também precisa de uma configuração de transporte diferente da HTTPS.

Para as solicitações HTTP relevantes do Cargo, a rota pode ser definida assim:

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

Substitua o endpoint da documentação pelo seu proxy HTTP. Para uma rota de registro público autorizada a usar proxies públicos, há candidatos na lista de proxies HTTP. Isso não prova que um executável Git externo recebeu a mesma configuração.

Se a fonte que falhou for Git, o Cargo pode selecionar o Git CLI em vez da implementação integrada:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true o seleciona para um comando. O Git externo agora precisa da própria configuração de proxy e das credenciais. Compare a mesma URL Git no mesmo ambiente de inicialização; um repositório não relacionado que funciona em outro terminal não é o teste.

Uma revisão ausente, uma permissão de repositório negada ou um erro de chave de host SSH continuam sendo o mesmo problema depois da troca de implementação. A opção escolhe um cliente compatível, não corrige dependências de forma geral.

Mantenha o diagnóstico no escopo do projeto ou do comando: configurações globais do Git e configurações do Cargo do usuário podem afetar outros workspaces. Uma URL de registro seleciona dados de pacote, não um intermediário. Depois que o caminho Git funcionar, execute novamente toda a operação pretendida do Cargo, pois arquivos, redirecionamentos e downloads durante a compilação podem introduzir outras rotas.

Artigos relacionados