Прочитайте URL джерела, яке не спрацювало, перш ніж змінювати проксі Cargo. Метадані реєстру, архів crate і залежність Git можуть використовувати різні шляхи отримання та автентифікації. Для SSH Git URL також потрібна інша транспортна схема, ніж для HTTPS.

Для відповідних HTTP-запитів Cargo маршрут можна задати так:

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

Замініть endpoint із документації своїм HTTP-проксі. Для публічного шляху реєстру, де дозволені публічні проксі, кандидати є у списку HTTP-проксі. Це не доводить, що зовнішній виконуваний файл Git отримав таку саму конфігурацію.

Якщо джерелом помилки є Git, Cargo може вибрати Git CLI замість вбудованої реалізації:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true вибирає його для однієї команди. Тепер зовнішньому Git потрібні власна конфігурація проксі та облікові дані. Порівняйте той самий Git URL у тому самому середовищі запуску; незалежний репозиторій, що працює в іншому терміналі, не є тестом.

Відсутня ревізія, відмова в дозволі репозиторію або помилка SSH host-key залишаються тією самою проблемою після зміни реалізації. Опція вибирає підтримуваний клієнт, а не виправляє залежності загалом.

Тримайте діагностику в межах проєкту або команди: глобальні налаштування Git і користувацькі налаштування Cargo можуть впливати на інші робочі простори. URL реєстру вибирає дані пакета, а не посередника. Коли Git-шлях запрацює, повторно запустіть усю заплановану операцію Cargo, бо архіви, перенаправлення й завантаження під час збірки можуть додати інші маршрути.

Схожі статті