어떤 .NET 자격 증명이 프록시용인가요?

HTTP 프록시 인증에서 WebProxy.Credentials, 목적지 서버 자격 증명, DefaultProxyCredentials를 구분하세요.

사용자 정의 WebProxy에는 해당 객체에 프록시 계정을 설정하세요. 다른 .NET 자격 증명 속성들은 받는 대상이 다릅니다.

속성대상
WebProxy.Credentials해당 객체가 나타내는 프록시.
HttpClientHandler.Credentials목적지 서버.
DefaultProxyCredentialsProxy가 null이고 UseProxy가 true일 때 시스템 기본 프록시.

이 .NET 10 예제는 명시적인 프록시와 그 전용 계정을 제공합니다.

using System;
using System.Net;
using System.Net.Http;

string password = Environment.GetEnvironmentVariable("PROXY_PASSWORD")
    ?? throw new InvalidOperationException("Set PROXY_PASSWORD");

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential("proxy-user", password)
};

using var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};
using var client = new HttpClient(handler)
{
    Timeout = TimeSpan.FromSeconds(15)
};

using var response = await client.GetAsync("https://example.com/");
Console.WriteLine((int)response.StatusCode);

문서용 엔드포인트를 바꾸고 운영자가 제공한 계정을 사용하세요. 인증 없는 목록 항목에 임의의 로그인을 만들 필요는 없습니다. 핸들러의 Proxy를 명시적으로 지정했으므로 DefaultProxyCredentials는 WebProxy.Credentials를 대신하지 못합니다.

UseDefaultCredentials도 객체에 따라 범위가 다릅니다. 핸들러의 서버 인증과 WebProxy의 프록시 인증은 별개입니다. 프로세스 사용자의 계정을 보내는 것은 407에 대한 일반 해법이 아닙니다.

인증 요구가 계속되면 실제 방식, 선택한 엔드포인트, 클라이언트/핸들러 인스턴스를 확인하세요. 프록시 인증은 목적지 TLS보다 먼저 진행될 수 있으므로 웹사이트 Authorization 헤더로 응답할 수 없습니다. 지원되는 인증은 핸들러, 플랫폼, 서비스, 배포 정책에 따라 달라집니다. 전역 Windows 프록시를 바꿀 필요는 없습니다.

관련 글