Le flux NuGet s'ouvre, mais le téléchargement du paquet est bloqué

Suivez une restauration NuGet v3 de l'index de service jusqu'au contenu du paquet lorsque le proxy autorise les métadonnées mais bloque l'hôte du paquet.

Qu'un navigateur ouvre l'index NuGet v3 ne prouve pas l'accès au téléchargement des paquets. L'index annonce les URL de ressources via @type et @id ; les métadonnées et le contenu du paquet peuvent être hébergés ailleurs.

  1. Lisez dans la sortie de restauration la première URL en échec, l'ID du paquet et la version.
  2. Comparez cet hôte aux URL de ressources de l'index du flux. PackageBaseAddress/3.0.0 fournit la base pour l'énumération des versions et la récupération des fichiers de paquet.
  3. Incluez les redirections lorsque vous examinez le chemin requis avec l'administrateur réseau.

Pour un index hypothétique à feed.example annonçant du contenu à packages.example, une liste de paquets peut se charger alors que le .nupkg sélectionné est bloqué. Des tentatives de connexion répétées ne rendent pas ces requêtes équivalentes. Qu'un paquet en cache réussisse dit aussi peu sur une autre URL de contenu distante.

Suivez la ressource annoncée plutôt que de deviner un nom d'hôte. NuGet la découvre parce que l'infrastructure du flux peut changer ; une règle autorisant uniquement l'hôte de l'index peut ne pas la couvrir.

Classez la réponse réelle : 407 demande l'authentification du proxy, tandis qu'un refus de politique, un CONNECT échoué, un hôte injoignable ou une erreur TLS exigent leur propre enquête. Des boîtes de dialogue similaires peuvent masquer ces différences. Demandez l'accès aux hôtes de ressources documentés du flux plutôt qu'à une large liste de jokers d'un produit sans rapport, puis examinez toute défaillance de compte restante.

Articles similaires