ارسال درخواستهای .NET HttpClient از طریق پروکسی
WebProxy را روی HttpClientHandler تنظیم کنید و نگذارید مسیریابی پروکسی خاموش بماند یا به کلاینت اشتباه وصل شود.
درخواست باید از HttpClient ساختهشده با handler پروکسی شما استفاده کند. ساخت یک شیء WebProxy نامرتبط، مسیر کلاینت دیگری را تغییر نمیدهد.
using System;
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://203.0.113.10:8080")
{
BypassProxyOnLocal = false
};
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);
Console.WriteLine(await response.Content.ReadAsStringAsync());نشانی مستنداتی را با یک پروکسی HTTP واقعی از سرویس خود یا فهرست پروکسی HTTP جایگزین کنید. این نحو سطح بالا برای پروژه کنسولی C# جدید مناسب است؛ پروژههای قدیمی میتوانند دستورها را در Main ناهمگام قرار دهند.
هر دو ویژگی handler را بررسی کنید: Proxy نقطه پایانی را انتخاب و UseProxy=true استفاده از آن را فعال میکند. اگر نقطه جداگانه کار میکند اما در برنامه نه، مطمئن شوید کدی UseProxy را غیرفعال نمیکند و فراخوانی از همین نمونه استفاده میکند. handler اختصاصی وابستگی به کشف پروکسی در فرایند یا سیستمعامل را حذف میکند.
وقتی گرداننده پروکسی حسابی ارائه میکند، یک NetworkCredential را به ویژگی WebProxy.Credentials اختصاص دهید. Authorization وبسایت برای گامی متفاوت است و ورودی IP:port عمومی اطلاعات ورود پیشفرض نمیدهد. شنونده http:// میتواند HTTPS را با تونل حمل کند؛ تأیید عادی مقصد را حفظ کنید.
این برنامه کوتاه هنگام خروج اشیا را آزاد میکند. برای فراخوانیهای مکرر سرویس، راهنمای .NET درباره عمر کلاینت را دنبال کنید و کلاینت/handler را برای بار کاری نگه دارید، نه اینکه استخر اتصال را برای هر درخواست دوباره بسازید. وضعیت برگشتی را بررسی کنید: مسیر پروکسی سالم هم میتواند پاسخ رد وبسایت را منتقل کند.