Канал NuGet открывается, но загрузка пакета заблокирована

Проследите восстановление NuGet v3 от индекса службы до содержимого пакета, когда прокси разрешает метаданные, но блокирует хост пакета.

Открытие индекса NuGet v3 в браузере не проверяет доступ к загрузке пакетов. Индекс объявляет URL-адреса ресурсов через @type и @id; метаданные и содержимое пакета могут размещаться в другом месте.

  1. Прочитайте в выводе восстановления первый неудачный URL-адрес, идентификатор пакета и версию.
  2. Сравните этот хост с URL-адресами ресурсов в индексе канала. PackageBaseAddress/3.0.0 даёт основу для перечисления версий и получения файлов пакета.
  3. Учитывайте перенаправления, когда проверяете требуемый путь с сетевым администратором.

Для гипотетического индекса на feed.example, который объявляет содержимое на packages.example, список пакетов может загрузиться, а выбранный .nupkg останется заблокированным. Повторные попытки входа не делают эти запросы равнозначными. Успех пакета из кэша тоже мало говорит о другом удалённом URL-адресе содержимого.

Следуйте объявленному ресурсу, а не угадывайте имя хоста. NuGet обнаруживает его, потому что инфраструктура канала может меняться; правило разрешения только для хоста индекса может его не покрывать.

Классифицируйте фактический ответ: 407 требует аутентификации прокси, тогда как отказ по политике, неудачный CONNECT, недоступный хост или ошибка TLS требуют отдельного расследования. Похожие диалоги могут скрывать эти различия. Запрашивайте доступ к документированным хостам ресурсов канала, а не широкий список шаблонов постороннего продукта, затем разбирайте любую оставшуюся ошибку учётной записи.

Похожие статьи