Cargo registry downloads काम करते हैं, लेकिन Git dependencies विफल होती हैं

Cargo का proxy बदलने से पहले विफल source URL पढ़ें। Registry metadata, crate archive और Git dependency अलग fetching और authentication paths का उपयोग कर सकते हैं। SSH Git URL को HTTPS से अलग transport arrangement भी चाहिए।

Cargo के संबंधित HTTP requests के लिए route इस तरह सेट किया जा सकता है:

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

Documentation endpoint को अपने HTTP proxy से बदलें। Public proxies वाले अनुमत public registry path के लिए candidates HTTP proxy list में हैं। इससे यह साबित नहीं होता कि किसी external Git executable को वही configuration मिली।

यदि विफल source Git है, तो Cargo अपनी built-in implementation के बजाय Git CLI चुन सकता है:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true इसे एक command के लिए चुनता है। External Git को अब अपना proxy configuration और credentials चाहिए। उसी launch environment में उसी Git URL की तुलना करें; किसी दूसरे terminal का काम करता हुआ असंबंधित repository परीक्षण नहीं है।

Missing revision, repository permission denial या SSH host-key error implementation बदलने के बाद भी वही समस्या रहती है। यह विकल्प supported client चुनने का तरीका है, सामान्य dependency repair नहीं।

Diagnosis को project या command scope पर रखें: global Git और user Cargo settings असंबंधित workspaces को प्रभावित कर सकती हैं। Registry URL package data चुनता है, intermediary नहीं। Git path काम करने के बाद पूरी intended Cargo operation फिर चलाएँ, क्योंकि archives, redirects और build-time downloads अन्य routes ला सकते हैं।