NuGet 407 ou 401 : identifiants du proxy ou du flux privé ?
Distinguez les identifiants du flux NuGet de ceux du proxy sortant, et inspectez la configuration utilisée par l'outil qui effectue réellement la restauration.
Une restauration NuGet peut exiger à la fois un compte de proxy sortant et un compte de flux privé. Utilisez la réponse pour décider quelle configuration inspecter :
| Observation | Commencez ici |
|---|---|
| Le proxy renvoie 407 | La route et le compte utilisés pour joindre le proxy sortant |
| La source de paquets renvoie 401 | La configuration d'authentification du flux |
| La connexion ou TLS échoue avant une réponse | Les éléments sur le point de terminaison, le transport et le certificat |
Un jeton de flux ne peut pas répondre au 407 du proxy. De même, une défaillance de connexion ou TLS avant une réponse n'a pas établi quel mot de passe est incorrect.
Configurez le proxy séparément du flux
L'entrée de proxy de NuGet relève de config. Pour une route sans identifiants intégrés :
<configuration>
<config>
<add key="http_proxy" value="http://proxy.example:8080" />
</config>
</configuration>Fusionnez cet exemple dans la configuration existante appropriée. Pour un flux public où les intermédiaires publics sont autorisés, la liste de proxies HTTP propose un candidat pour cette route sans identifiants. Gardez les sources de paquets dans leur propre section ; remplacer l'URL du flux par une adresse de proxy générique demande les paquets à l'intermédiaire.
La valeur documentée http_proxy.password est chiffrée. Utilisez les outils de configuration pris en charge plutôt que d'écrire du texte en clair dans ce champ ou de copier depuis une autre machine une valeur qui semble encodée comme s'il s'agissait d'un format d'identifiants portable.
Inspectez la restauration qui échoue réellement
Nommez le client, l'utilisateur et l'environnement de lancement, puis localisez sa hiérarchie de configuration effective. Les paramètres utilisateur, machine et solution peuvent y contribuer. Un ancien correctif devenv.exe.config concerne un processus Visual Studio particulier ; il n'établit pas ce que lit une restauration en ligne de commande ou un service de build. Préservez les sources de paquets et les stratégies qui fonctionnent pendant que vous localisez une entrée de proxy obsolète.
Une fois l'authentification fonctionnelle, suivez toute URL qui échoue ensuite. Les métadonnées du flux et le contenu des paquets peuvent utiliser des points de terminaison différents, donc une requête acceptée n'établit pas la route de restauration complète. Préservez la validation normale des signatures de paquets et de TLS pendant que vous corrigez cela.