Which .NET Credentials Belong to the Proxy?

Distinguish WebProxy.Credentials, destination-server credentials, and DefaultProxyCredentials when authenticating an HTTP proxy.

For a custom WebProxy, put the proxy account on that object. Several other .NET credential properties serve different recipients:

PropertyRecipient
WebProxy.CredentialsThe proxy represented by that object.
HttpClientHandler.CredentialsThe destination server.
DefaultProxyCredentialsThe system default proxy when Proxy is null and UseProxy is true.

This .NET 10 example supplies an explicit proxy and its own account:

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);

Replace the documentation endpoint and use an operator-supplied account. An unauthenticated list entry needs no invented login. Because the handler's Proxy is explicitly assigned, DefaultProxyCredentials is not a replacement for WebProxy.Credentials.

UseDefaultCredentials also has an object-specific scope: a handler's server authentication and a WebProxy's proxy authentication are different. Sending the process user's account is not a generic response to 407.

If the challenge persists, check the actual scheme, selected endpoint and client/handler instance. Proxy authentication can precede destination TLS, so a website Authorization header cannot answer it. Supported authentication still depends on handler, platform, service and deployment policy; the setup requires no global Windows proxy change.

འབྲེལ་བའི་རྩོམ་ཡིག