NuGet 복원에는 포워드 프록시 계정과 프라이빗 피드 계정이 모두 필요할 수 있습니다. 응답을 보고 어떤 구성을 점검할지 결정하세요:

관찰여기서 시작
프록시가 407을 반환포워드 프록시에 도달하는 데 사용되는 경로와 계정
패키지 원본이 401을 반환피드의 인증 구성
응답 전에 연결 또는 TLS 실패엔드포인트, 전송, 인증서에 관한 근거

피드 토큰은 프록시의 407에 답할 수 없습니다. 마찬가지로 응답 전의 연결 또는 TLS 실패는 어느 암호가 잘못되었는지 입증하지 못합니다.

프록시를 피드와 별도로 구성

NuGet의 프록시 항목은 config 아래에 둡니다. 자격 증명이 포함되지 않은 경로의 경우:

<configuration>
  <config>
    <add key="http_proxy" value="http://proxy.example:8080" />
  </config>
</configuration>

이 예시를 적절한 기존 구성에 병합하세요. 공용 중개자가 허용되는 공용 피드의 경우 HTTP 프록시 목록이 이 자격 증명 없는 경로의 후보를 제공합니다. 패키지 원본은 별도 섹션에 유지하세요. 피드 URL을 일반 프록시 주소로 바꾸면 중개자에게 패키지를 요청하는 셈입니다.

문서화된 http_proxy.password 값은 암호화되어 있습니다. 해당 필드에 평문을 쓰거나 다른 머신에서 암호화된 것처럼 보이는 값을 이식 가능한 자격 증명 형식인 양 복사하지 말고, 지원되는 구성 도구를 사용하세요.

실제로 실패하는 복원을 점검

클라이언트, 사용자, 시작 환경을 특정한 뒤 유효한 구성 계층을 찾으세요. 사용자, 머신, 솔루션 설정이 영향을 줄 수 있습니다. 오래된 devenv.exe.config 수정은 특정 Visual Studio 프로세스에 관한 것이며, 명령줄 복원이나 빌드 서비스가 무엇을 읽는지 입증하지 않습니다. 사용되지 않는 프록시 항목을 찾는 동안 동작하는 패키지 원본과 정책은 유지하세요.

인증이 동작하면 이후에 실패하는 모든 URL을 따라가세요. 피드 메타데이터와 패키지 콘텐츠는 서로 다른 엔드포인트를 사용할 수 있으므로 요청 하나가 승인되었다고 해서 전체 복원 경로가 입증되지는 않습니다. 이를 수정하는 동안에도 일반적인 패키지 서명 및 TLS 검증은 유지하세요.

관련 글