На прошлой неделе я потратил неприлично много времени, глядя на ответ 407 Proxy Authentication Required, и был уверен, что мой провайдер прокси сломался. Оказалось, я указал учетные данные не в том свойстве — исправление заняло две строки, но я искал его два часа. Если вам это знакомо, этот материал для вас.
Настройка прокси в HttpClient на C# — одна из тех тем, где базовый шаблон выглядит просто, но продакшен-нюансы — исчерпание сокетов, несовпадение версий SOCKS5, путаница с учетными данными — отнимают массу времени.
Я уже некоторое время работаю с инструментами для веб-скрапинга и извлечения данных в Thunderbit, и вижу одни и те же ошибки снова и снова — как в наших внутренних инженерных обсуждениях, так и в сообществах разработчиков, за которыми мы следим. В этом руководстве я разберу весь путь: настройку, аутентификацию, ротацию прокси, выбор протокола и таблицу устранения неполадок, которой мне очень не хватало в первый день.
Сложность: от начального до среднего уровня
Время: около 15 минут на практику, дольше — если речь о продакшен-ротации
Что понадобится: .NET 6+ SDK (для SOCKS5 и современных возможностей handler’ов; .NET Framework 4.x подойдет для базовых примеров HTTP-прокси), редактор кода и хотя бы одна точка входа прокси для теста
Что такое HttpClient и зачем ему прокси?
HttpClient — это встроенный в .NET класс из System.Net.Http для отправки HTTP-запросов и получения ответов. Он поддерживает async/await, пользовательские заголовки, токены отмены и настройку через handler’ы. Microsoft описывает его как класс для отправки HTTP-запросов и получения HTTP-ответов от ресурса, идентифицируемого URI.
Прокси-сервер — это посредник между вашим приложением и целевым сайтом. Когда трафик идет через прокси, сайт видит IP-адрес прокси, а не ваш.
У самого HttpClient нет свойства Proxy. Маршрутизация через прокси настраивается на уровне базового handler’а — либо HttpClientHandler, либо SocketsHttpHandler — и тот, и другой принимает экземпляр WebProxy. Ментальная модель выглядит так:
[Ваше C#-приложение] → [HttpClient + Handler] → [Прокси-сервер] → [Целевой сайт]
Именно поэтому «сменить прокси у уже работающего HttpClient» — это архитектурная задача, а не простое присваивание свойства. Об этом подробнее в разделе про ротацию.
Попробуйте Thunderbit для более простой работы с данными
Зачем использовать прокси с HttpClient в C#
Разработчики направляют трафик HttpClient через прокси по нескольким типичным причинам, и правильный тип прокси зависит от задачи.
- Избежать банов IP и лимитов запросов: критично для веб-скрапинга, лидогенерации и мониторинга цен в больших объемах. Один IP, который слишком активно «стучится» на сайт, быстро заблокируют.
- Обойти географические ограничения: получить доступ к API или контенту, доступным только в определенных регионах, можно через прокси в нужной стране.
- Скрыть исходный IP: дополнительный уровень приватности при сборе чувствительных данных или конкурентной разведке.
- Корпоративные или регуляторные требования: во многих компаниях исходящий трафик обязан проходить через централизованный шлюз для логирования и контроля.
- Тестирование и QA: можно имитировать запросы из разных локаций и сетевых условий без физического развертывания инфраструктуры в этих регионах.
| Сценарий | Типичный выбор прокси | Почему подходит |
|---|---|---|
| Массовый веб-скрапинг | Ротационные residential-прокси | Больше разнообразия IP, антибот-системам сложнее классифицировать трафик |
| Мониторинг цен в e-commerce | Residential или геотаргетированный datacenter-прокси | Проверка цен и наличия с учетом региона |
| Доступ к API через фиксированный шлюз | Datacenter-прокси или корпоративный прокси | Предсказуемый allowlist IP, ниже стоимость |
| Корпоративный комплаенс | Системный прокси, PAC-прокси, авторизованный корпоративный прокси | Централизованное логирование и контроль исходящего трафика |
| QA и локализационное тестирование | Пул прокси по странам | Имитирует реальный доступ пользователей из целевых регионов |
Прокси обычно вводят поэтапно. Сначала берут один статический прокси, чтобы убедиться, что маршрут работает. Промышленный скрапер переходит к пулу, распределяя запросы по прокси в зависимости от домена, географии или частоты ошибок. Зрелые команды часто уходят на управляемый прокси-шлюз, где ротация, ретраи и привязка сессий уже скрыты за одним endpoint’ом.
Ротация прокси — не серебряная пуля. Если сайт блокирует подозрительное поведение, смена IP помогает только тогда, когда правильно выстроены частота запросов, заголовки, cookies и TLS-отпечаток.
Какие версии .NET что поддерживают: краткая таблица совместимости
Скопировать пример прокси из статьи в неподходящий target framework — один из главных источников тихих сбоев. Ключевая граница здесь — .NET Framework 4.x против современного .NET (.NET 6+). Вот что где работает:
| Возможность | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | Да | Да | Да | Да |
SOCKS5 через WebProxy("socks5://...") | Нет | Да (добавлено в .NET 6) | Да | Да |
SocketsHttpHandler (handler по умолчанию) | Нет | Да | Да | Да |
Статический HttpClient.DefaultProxy | Нет | Да | Да | Да |
PooledConnectionLifetime | Нет | Да | Да | Да |
Если вы целитесь в .NET Framework 4.x, используйте HTTP/HTTPS-прокси с HttpClientHandler и WebProxy. Для SOCKS5 и современных механизмов пуллинга нужен .NET 6 или новее.
Есть еще один тонкий момент: HttpClient.DefaultProxy в современном .NET — статическое свойство. Если его задали в общем startup-коде или оно унаследовано из переменных окружения вроде HTTPS_PROXY или HTTP_PROXY, его подхватит каждый экземпляр HttpClient, если вы явно не переопределите handler. В контейнерных средах это частая причина вопроса: «Почему клиент использует прокси, который я вообще не настраивал?»
Шаг 1: Создайте новый консольный проект C#
Откройте терминал и создайте новый проект:
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
Проверьте версию SDK командой dotnet --version. Примеры в этом руководстве рассчитаны на .NET 6+ и покрывают все нужные возможности. Если нужен свежий LTS SDK, скачайте его со страницы загрузок Microsoft.
Откройте Program.cs в своем редакторе — вся магия будет происходить там.
Шаг 2: Сделайте базовый HTTP-запрос без прокси
Прежде чем настраивать прокси, зафиксируйте свой реальный исходящий IP. Тогда после включения прокси вы сможете убедиться, что адрес действительно изменился.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");
Запустите код. Вы должны увидеть свой текущий публичный IP, например:
Direct IP: 203.0.113.10
Запомните это значение. После следующего шага оно должно измениться.
Шаг 3: Настройте WebProxy через HttpClientHandler
Классическая схема состоит из трех объектов: WebProxy, handler и клиент.
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
BypassProxyOnLocal = false
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true,
UseDefaultCredentials = false
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Proxy IP: {ip}");
Замените proxy.example.com:8080 на свой реальный адрес прокси. Если все подключено правильно, IP в выводе должен теперь совпадать с выходным IP прокси, а не с вашим настоящим.
Ключевые свойства, которые нужно понимать:
Proxy— экземплярIWebProxy, который handler использует для маршрутизации.UseProxy = true— сообщает handler’у, что нужно реально использовать настроенный прокси. Звучит очевидно, но забыть об этом — частая причина потери времени на отладку.BypassProxyOnLocal = false— не позволяет handler’у обходить прокси для адресов, которые выглядят «локальными».UseDefaultCredentials— определяет, отправляет ли handler стандартные учетные данные Windows. Это не то же самое, что имя пользователя и пароль прокси.
Шаг 4: Добавьте аутентификацию прокси через NetworkCredential
Большинство платных провайдеров прокси требуют учетные данные. Правильный вариант — задавать их прямо в объекте WebProxy:
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Authenticated proxy IP: {ip}");
Многие провайдеры дают формат URL вида http://username:password@host:port. Но в .NET лучше использовать NetworkCredential, а не встраивать учетные данные в строку URI. Так вы избежите проблем с экранированием специальных символов в пароле и явно разделите сам URI и данные авторизации.
Ниже я отдельно разберу самую частую ошибку аутентификации — и объясню, почему она вызывает 407.
Шаг 5: Выведите или используйте данные ответа
Для чего-то большего, чем быстрая проверка IP, обрабатывайте ответ нормально:
using var response = await client.GetAsync("https://example.com/api/products");
if (!response.IsSuccessStatusCode)
{
Console.WriteLine($"Request failed: {(int)response.StatusCode} {response.ReasonPhrase}");
return;
}
var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);
В рабочих сценариях скрапинга проксируемый запрос — это лишь транспортный слой. Вам все равно нужны парсинг, нормализация, дедупликация, ретраи и экспорт в Excel, Google Sheets, базы данных или другие системы. Инструменты вроде Thunderbit могут автоматизировать извлечение и экспорт — его расширение для Chrome умеет структурированно извлекать данные и бесплатно выгружать их в Google Sheets, Excel, Airtable или Notion без написания кода парсинга.
Экспортируйте собранные данные в Excel, Sheets, Airtable или Notion Get Started Free
Учетные данные прокси и учетные данные сервера: ошибка, из-за которой возникает 407
Я видел эту ошибку в ветках Stack Overflow, в Microsoft Q&A и — признаюсь — в своем собственном коде.
Разница простая, но легко путается:
- Учетные данные прокси аутентифицируют вас на самом прокси-сервере.
- Учетные данные сервера аутентифицируют вас на целевом сервере.
В HttpClientHandler они находятся в разных свойствах. Если задать их не там, это главная причина ошибок 407 Proxy Authentication Required.
// ❌ НЕПРАВИЛЬНО — задает учетные данные для целевого сервера, а не для прокси
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ ПРАВИЛЬНО — задает учетные данные прямо на объекте прокси
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials относится к целевому серверу. WebProxy.Credentials относится к прокси. Если прокси возвращает 407, учетные данные нужно указывать именно на прокси.
Еще одна ловушка: HttpClientHandler.PreAuthenticate управляет предварительной аутентификацией для целевого сервера. Он не управляет заголовком Proxy-Authorization. Не используйте его как способ исправить 407.
Как ротировать прокси с HttpClient в C#
Разработчики постоянно спрашивают об этом на форумах. Первоначальный ответ разочаровывает: нельзя поменять прокси у уже созданного экземпляра HttpClient. Прокси живет на уровне handler’а. Handler задается при создании. У HttpClient нет изменяемого свойства Proxy.
Наивный обходной путь — new HttpClient(new HttpClientHandler { Proxy = ... }) на каждый запрос — создает другую проблему. Microsoft прямо предупреждает, что создание и уничтожение клиентов на каждый запрос может исчерпать доступные TCP-порты, потому что порты не освобождаются сразу после закрытия соединения.
Вот три действительно рабочих production-подхода.
Вариант 1: Именованные клиенты через IHttpClientFactory
Если набор прокси известен при старте приложения, именованные клиенты — самый простой вариант. У каждого именованного клиента своя конфигурация handler’а, а код приложения выбирает нужный клиент по имени во время выполнения.
builder.Services.AddHttpClient("proxy-us")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://us-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
builder.Services.AddHttpClient("proxy-eu")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://eu-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
// Во время запроса:
var client = httpClientFactory.CreateClient("proxy-us");
Фабрика управляет временем жизни handler’ов и избавляет от антипаттерна «новый клиент на каждый запрос».
Вариант 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
Для долгоживущего клиента за прокси-шлюзом, который меняет выходные IP на новых соединениях, PooledConnectionLifetime заставляет соединения пересоздаваться после заданного интервала.
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("http://rotating-gateway.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true,
PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};
using var client = new HttpClient(handler);
Это не «магически» меняет объект Proxy для каждого запроса. Подход лучше всего работает с прокси-шлюзами, которые выдают новый выходной IP при каждом новом TCP-соединении, либо с пулами прокси на основе DNS, где hostname со временем разрешается в разные endpoint’ы.
Вариант 3: Собственный DelegatingHandler для продвинутого выбора прокси
Когда выбор прокси зависит от URL запроса, полезной нагрузки или контекста выполнения, собственный routing-handler может анализировать каждый запрос и направлять его в нужную цепочку внутренних handler’ов.
public sealed class ProxyRoutingHandler : DelegatingHandler
{
private readonly IReadOnlyDictionary<string, HttpMessageInvoker> _clients;
protected override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
var key = SelectProxyKey(request);
return _clients[key].SendAsync(request, cancellationToken);
}
}
Это уже продвинутая архитектура. Потокобезопасность, освобождение ресурсов, повторное использование handler’ов, поведение retry и логирование — все это становится вашей зоной ответственности. Я бы рекомендовал такой подход только тогда, когда первые два действительно не подходят.
Сравнение трех подходов
| Подход | Сложность | Версия .NET | Потокобезопасность | Накладные расходы |
|---|---|---|---|---|
| Именованные клиенты (IHttpClientFactory) | Низкая | .NET Core 2.1+ | Высокая (неизменяемая конфигурация) | Низкие |
| SocketsHttpHandler + PooledConnectionLifetime | Средняя | .NET 6+ | Высокая | Низкие |
| Собственный DelegatingHandler | Высокая | Любая | Зависит от реализации | Средние |
Для большинства команд лучший старт — именованные клиенты. Переходите к PooledConnectionLifetime для стабильных ротационных шлюзов, а к собственной маршрутизации — только если выбор прокси зависит от метаданных на уровне запроса.
Как выбрать правильный прокси-протокол: HTTP, HTTPS и SOCKS5
Не все прокси разговаривают на одном языке, и неправильная схема протокола приводит к запутанным ошибкам.
HTTP-прокси: понимает HTTP-запросы. Для обычных HTTP-целей может передавать запросы напрямую. Для HTTPS-целей клиент сначала отправляет CONNECT, чтобы создать туннель, а затем TLS устанавливается через этот туннель с конечным сервером. Это самый распространенный вариант.
HTTPS-terminating proxy: прокси предъявляет собственный TLS-сертификат и повторно шифрует трафик вверх по цепочке. Такое часто встречается в корпоративных системах инспекции и у некоторых managed scraping API. Если клиент не доверяет цепочке сертификатов прокси, могут появиться ошибки проверки сертификата.
SOCKS5-прокси: TCP-туннель на транспортном уровне, который работает для любого TCP-трафика, а не только для HTTP. Широко используется провайдерами residential-прокси. Нативно поддерживается в .NET 6+.
Пример SOCKS5:
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("socks5://proxy.example.com:1080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
},
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine(ip);
Замечание о проверке SSL-сертификатов
При использовании HTTPS-terminating прокси можно увидеть ошибку RemoteCertificateNameMismatch. Для настройки проверки можно использовать ServerCertificateCustomValidationCallback:
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
Используйте это только в локальной разработке или с доверенным, одобренным TLS-интерцептирующим прокси. Безусловный возврат true отключает критически важную проверку безопасности и открывает путь к атакам man-in-the-middle. В production при обычных CONNECT или SOCKS-прокси SSL-проверку лучше оставлять включенной.
Устранение типичных ошибок прокси в C# HttpClient
Эта таблица связывает видимый симптом с вероятной причиной и первым шагом исправления. Советую сохранить этот раздел — здесь собраны ошибки, которые чаще всего встречаются в ветках Stack Overflow и на форумах разработчиков.
| Ошибка / симптом | Частая причина | Исправление |
|---|---|---|
| 407 Proxy Authentication Required | Учетные данные заданы в handler.Credentials вместо handler.Proxy.Credentials; неверный формат username; специальные символы в пароле, встроенном в URL | Используйте WebProxy.Credentials = new NetworkCredential(...); не встраивайте учетные данные в URI; проверьте формат username у провайдера |
| TaskCanceledException / Timeout | Endpoint прокси медленный, недоступный, перегружен или блокируется фаерволом; стандартный таймаут 100 секунд слишком мал | Проверьте прокси через curl; увеличивайте HttpClient.Timeout только после подтверждения, что endpoint работает; добавьте ретраи и health-check’и прокси |
| SocketException / исчерпание сокетов | Создание и уничтожение HttpClient или handler’ов на каждый запрос | Используйте IHttpClientFactory, singleton-клиенты или SocketsHttpHandler с настройками пуллинга |
| SSL RemoteCertificateNameMismatch | HTTPS-интерцепция со стороны корпоративного или управляемого прокси | Установите/доверьте CA прокси, если это уместно; используйте custom validation только в контролируемой dev-среде или одобренных MITM-сценариях |
| Цикл редиректов 302 | Корпоративный прокси/VPN/captive portal или allowlist-блокировка, которая постоянно редиректит | Проверьте прямое подключение; изучите заголовки Location; проверьте allowlist и страницу авторизации прокси |
| HttpRequestException / нет соединения с SOCKS URL | SOCKS-код запускается на .NET Framework или старом .NET; неверная схема или порт | Используйте .NET 6+ для нативной поддержки SOCKS; проверьте socks5://host:port; протестируйте по документации провайдера |
| Кажется, что прокси игнорируется | UseProxy = false; цель обходит прокси как локальная; переменная окружения NO_PROXY; handler настроен не так, как ожидалось | Установите UseProxy = true; проверьте HttpClient.DefaultProxy; очистите или переопределите переменные окружения; задайте BypassProxyOnLocal = false |
Быстрый сценарий диагностики
- Запрос завершился успешно? → Да: сравните вывод
api.ipify.orgс ожидаемым IP прокси. - Нет, но есть HTTP-код? → 407: исправьте учетные данные прокси. 403/429: целевой сайт заблокировал или ограничил прокси. 3xx-цикл: возможно, редиректит прокси или корпоративный шлюз.
- Нет кода, только исключение? → Timeout: проверьте доступность прокси. Socket/certificate exception: проверьте пуллинг, протокол, TLS и версию .NET.
Полезные первые команды для проверки самого прокси вне .NET:
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org/
curl --socks5 user:pass@proxy.example.com:1080 https://api.ipify.org/
Если curl работает, а C# — нет, различие обычно в схеме авторизации, trust store TLS, переменных окружения или экранировании учетных данных. Сначала точно повторите в C# URL прокси, схему и способ авторизации из curl, а уже потом переносите данные в NetworkCredential.
Когда лучше не управлять прокси вручную: no-code альтернатива
Значительная часть разработчиков, ищущих «HttpClient proxy C#», на самом деле не изучает теорию прокси — они хотят, чтобы скрапер просто продолжал работать. И полезно честно признать, когда собственный C#-код с прокси — правильный инструмент, а когда — нет.
Пишите собственный C#-скрапер с ротацией прокси, когда:
- вам нужен полный контроль над логикой запросов, cookies, заголовками, ретраями и парсингом;
- скрапер должен встроиться в существующий .NET-код или внутренний сервис;
- требования комплаенса или безопасности требуют, чтобы вы полностью контролировали инфраструктуру.
Используйте no-code инструмент вроде Thunderbit, когда:
- цель — структурированное извлечение данных с сайтов, а не работа с HTTP-инфраструктурой;
- вы не хотите поддерживать пулы прокси, разбираться с CAPTCHA или отлаживать исчерпание сокетов;
- команде нужны данные в Excel, Google Sheets, Airtable или Notion без написания кода парсинга.
Расширение Chrome от Thunderbit автоматически обрабатывает ротацию прокси и антибот-защиту через облачный режим скрапинга. Его API позволяет разработчикам задать JSON-схему и получить структурированные данные обратно, вообще не управляя HttpClient или WebProxy. Для команд, которые делают скрапинг для сравнения цен или извлечение лидов, разница во времени настройки очень заметна.
| Сценарий | Собственный C# + прокси | Thunderbit |
|---|---|---|
| Полный контроль над логикой запросов | Да | Нет (только управление на уровне API) |
| Нужна ли ручная настройка прокси | Да | Нет (все делается автоматически) |
| Обработка антибота / CAPTCHA | Вручную или через сторонние инструменты | Встроено |
| Время на настройку | От часов до дней | Минуты |
| Лучше всего подходит для | Существующих .NET-кодов, кастомных пайплайнов | Быстрого извлечения данных, нетехнических команд, экспорта в таблицы |
Это не аргумент «никогда не используйте HttpClient». Если вы строите production-сервис на .NET, вы обязаны понимать настройку прокси. Но если вы часами отлаживаете 407 ради разовой задачи по сбору данных, есть более простые варианты — и это нормально. Можно посмотреть цены Thunderbit или заглянуть на YouTube-канал с разбором сценариев.
Ключевые выводы
Базовый шаблон остается прежним: WebProxy → handler → HttpClient. Все остальное — это устранение операционных ошибок, которые всплывают в production.
- Учетные данные задаются на прокси, а не на handler. Бок о бок пример в разделе про 407 — самое важное, что нужно запомнить.
- Не создавайте новый
HttpClientна каждый запрос или на каждый прокси. ИспользуйтеIHttpClientFactoryдля именованных клиентов,SocketsHttpHandlerсPooledConnectionLifetimeдля ротационных шлюзов или собственный routing-handler для сложных сценариев. - Проверяйте версию .NET перед копированием кода с SOCKS5 или
SocketsHttpHandler. Таблица совместимости выше сэкономит вам много времени на тихих сбоях. - Сначала тестируйте прокси вне .NET. Простой
curlубирает целую категорию проблем из отладки. - Если нужна структурированная выгрузка данных без головной боли с прокси, инструменты вроде Thunderbit берут на себя транспортный слой, а вы сосредотачиваетесь на самих данных.
В следующий раз, когда увидите 407 или TaskCanceledException, начните с таблицы устранения неполадок выше.
FAQ
Можно ли сменить прокси у уже существующего экземпляра HttpClient?
Нет. Прокси привязан к handler’у, а handler задается при создании. HttpClient не предоставляет изменяемого свойства Proxy. Для разных прокси создавайте отдельные handler’ы и клиенты, а затем управляйте ими через именованные клиенты IHttpClientFactory или пул заранее настроенных клиентов.
Использует ли HttpClient системный прокси по умолчанию?
Да. В современном .NET, если явно не задать handler, HttpClient наследует системные настройки прокси, включая переменные окружения вроде HTTPS_PROXY и HTTP_PROXY через HttpClient.DefaultProxy. Чтобы отключить это поведение, явно установите UseProxy = false на handler.
Как использовать SOCKS5-прокси с HttpClient в C#?
Используйте new WebProxy("socks5://host:port") вместе с SocketsHttpHandler. Нативная поддержка SOCKS-прокси требует .NET 6 или новее. В .NET Framework 4.x нативной поддержки SOCKS5 нет — понадобится сторонняя библиотека.
Почему я постоянно получаю 407 Proxy Authentication Required?
Скорее всего, вы задаете учетные данные в handler.Credentials (это для целевого сервера), а не в handler.Proxy.Credentials (это для прокси). Смотрите раздел «Учетные данные прокси и учетные данные сервера» выше — там показан правильный шаблон.
Безопасно ли отключать проверку SSL-сертификата при использовании прокси?
Только в локальной разработке или если вы полностью доверяете провайдеру прокси, например в managed scraping API в режиме HTTPS-прокси. В production при стандартных CONNECT или SOCKS-прокси лучше оставлять SSL-проверку включенной, чтобы защититься от атак man-in-the-middle.
Попробуйте Thunderbit для простого веб-скрапинга Get Started Free
Узнайте больше
