NuGet-flödet öppnas, men paketnedladdningen är blockerad

Att en webbläsare öppnar NuGet v3-indexet testar inte åtkomsten till paketnedladdning. Indexet annonserar resurs-URL:er via @type och @id; metadata och paketinnehåll kan vara värdade någon annanstans.

1. Läs i återställningsutdata den första misslyckade URL:en, paket-ID:t och versionen.
2. Jämför den värden med resurs-URL:erna i flödesindexet. PackageBaseAddress/3.0.0 ger basen för versionsuppräkning och hämtning av paketfiler.
3. Ta med omdirigeringar när du går igenom den nödvändiga sökvägen med nätverksadministratören.

För ett hypotetiskt index på feed.example som annonserar innehåll på packages.example kan en paketlista läsas in medan det valda .nupkg är blockerat. Upprepade inloggningsförsök gör inte dessa förfrågningar likvärdiga. Att ett cachelagrat paket lyckas säger också lite om en annan fjärrinnehålls-URL.

Följ den annonserade resursen i stället för att gissa ett värdnamn. NuGet upptäcker den eftersom flödesinfrastrukturen kan ändras; en tillåtelseregel bara för indexvärden täcker den kanske inte.

Klassificera det faktiska svaret: 407 begär proxyautentisering, medan en policyavvisning, misslyckad CONNECT, oåtkomlig värd eller TLS-fel kräver sin egen utredning. Liknande dialogrutor kan dölja dessa skillnader. Begär åtkomst till flödets dokumenterade resursvärdar i stället för en bred jokerteckenlista från en orelaterad produkt och undersök sedan eventuella kvarvarande kontofel.