Kelayakan .NET yang manakah milik proksi?

Bezakan WebProxy.Credentials, kelayakan pelayan destinasi dan DefaultProxyCredentials semasa mengesahkan proksi HTTP.

Untuk WebProxy tersuai, tetapkan akaun proksi pada objek itu. Sifat kelayakan .NET lain melayani penerima berbeza:

SifatPenerima
WebProxy.CredentialsProksi yang diwakili objek itu.
HttpClientHandler.CredentialsPelayan destinasi.
DefaultProxyCredentialsProksi lalai sistem apabila Proxy null dan UseProxy true.

Contoh .NET 10 ini memberikan proksi eksplisit dan akaunnya sendiri:

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

Gantikan titik akhir dokumentasi dan gunakan akaun daripada pengendali. Entri senarai tanpa pengesahan tidak memerlukan log masuk rekaan. Oleh sebab Proxy pengendali ditetapkan secara jelas, DefaultProxyCredentials bukan pengganti WebProxy.Credentials.

UseDefaultCredentials juga mempunyai skop khusus objek: pengesahan pelayan pengendali dan pengesahan proksi WebProxy berbeza. Menghantar akaun pengguna proses bukan jawapan umum untuk 407.

Jika cabaran pengesahan berterusan, periksa skim sebenar, titik akhir dipilih dan tika klien/pengendali. Pengesahan proksi boleh mendahului TLS destinasi, jadi pengepala Authorization laman tidak boleh menjawabnya. Sokongan masih bergantung pada pengendali, platform, perkhidmatan dan dasar pelaksanaan; tidak perlu mengubah proksi Windows secara global.

Artikel berkaitan