Na semana passada, perdi um tempão, e ainda por cima com aquela sensação de vergonha, encarando uma resposta 407 Proxy Authentication Required, certo de que o problema era no meu provedor de proxy. No fim das contas, eu tinha colocado as credenciais na propriedade errada — uma correção de duas linhas que me custou duas horas para achar. Se isso te soa familiar, este guia é para você.
Configurar proxy com HttpClient em C# é um daqueles temas em que o básico parece simples, mas os detalhes de produção — exaustão de sockets, incompatibilidade de versão do SOCKS5, confusão entre credenciais — acabam consumindo tempo de verdade.
Tenho trabalhado há algum tempo com ferramentas de web scraping e extração de dados na Thunderbit, e vi esses mesmos erros aparecerem várias e várias vezes, tanto nas nossas conversas internas de engenharia quanto nas comunidades de desenvolvedores que acompanhamos. Este passo a passo cobre o caminho inteiro: configuração, autenticação, rotação de proxy, escolha de protocolo e uma tabela de troubleshooting que eu realmente queria ter tido no dia em que comecei.
Dificuldade: Iniciante a intermediário
Tempo necessário: ~15 minutos para acompanhar, mais tempo para padrões de rotação em produção
O que você vai precisar: SDK .NET 6+ (para SOCKS5 e recursos modernos de handler; .NET Framework 4.x funciona para exemplos básicos de proxy HTTP), um editor de código e ao menos um endpoint de proxy para testar
O que é o HttpClient e por que ele precisa de proxy?
HttpClient é a classe nativa do .NET em System.Net.Http para enviar requisições HTTP e receber respostas. Ela oferece suporte a async/await, cabeçalhos personalizados, tokens de cancelamento e configuração baseada em handler. A Microsoft o descreve como uma classe para enviar requisições HTTP e receber respostas HTTP de um recurso identificado por uma URI.
Um servidor proxy funciona como intermediário entre sua aplicação e o site de destino. Quando você roteia o tráfego por um proxy, o destino enxerga o IP do proxy, e não o seu.
O HttpClient em si não tem uma propriedade Proxy. O roteamento via proxy é configurado no handler subjacente — seja HttpClientHandler ou SocketsHttpHandler — que aceita uma instância de WebProxy. O modelo mental é este:
[Sua aplicação C#] → [HttpClient + Handler] → [Servidor Proxy] → [Site de Destino]
Por isso, “trocar o proxy em um HttpClient já em uso” é mais uma questão de arquitetura do que uma simples atribuição de propriedade. Voltamos a esse ponto na seção de rotação.
Experimente a Thunderbit para uma extração de dados mais fácil
Por que usar um proxy com HttpClient em C#
Desenvolvedores roteiam o tráfego do HttpClient por proxies por alguns motivos bem comuns, e o tipo certo de proxy depende da tarefa.
- Evitar bloqueios de IP e limites de requisições: essencial para web scraping, geração de leads ou monitoramento de preços em escala. Um único IP martelando um site será bloqueado rapidamente.
- Contornar restrições geográficas: acessar APIs ou conteúdos bloqueados por região usando proxies em países específicos.
- Ocultar seu IP de origem: adicionar uma camada de privacidade para coleta de dados sensíveis ou pesquisa competitiva.
- Exigências corporativas ou de conformidade: muitas empresas exigem que o tráfego de saída passe por um gateway central para registro e governança.
- Testes e QA: simular requisições de diferentes locais ou condições de rede sem precisar implantar infraestrutura fisicamente nessas regiões.
| Caso de uso | Tipo de proxy típico | Por que faz sentido |
|---|---|---|
| Web scraping em escala | Proxies residenciais rotativos | Mais variedade de IPs, mais difícil para sistemas anti-bot classificarem |
| Monitoramento de preços em e-commerce | Residencial ou datacenter com alvo geográfico | Verificação de preços e estoque por região |
| Acesso a API via gateway fixo | Proxy de datacenter ou proxy corporativo | Allowlist de IP previsível, menor custo |
| Conformidade empresarial | Proxy do sistema, proxy PAC, proxy corporativo autenticado | Registro centralizado e controle de saída |
| QA e testes de localização | Pool de proxies por país | Simula acesso real de usuários de regiões-alvo |
O uso de proxy também costuma evoluir em etapas previsíveis. Você começa com um único proxy estático para validar o roteamento. Um scraper em produção passa a usar um pool, associando requisições a proxies por domínio-alvo, geografia ou taxa de falha. Times mais maduros normalmente migram para um gateway de proxy gerenciado, em que rotação, retries e afinidade de sessão ficam sob um único endpoint.
Rotação de proxy não é uma solução mágica. Se o destino bloqueia comportamento suspeito, trocar IPs só ajuda de verdade quando a cadência das requisições, os cabeçalhos, os cookies e o fingerprint TLS também são tratados com cuidado.
Qual versão do .NET suporta o quê: uma matriz rápida de compatibilidade
Copiar um trecho de proxy de um post de blog para o target framework errado é uma das maiores causas de falhas silenciosas. A grande divisão está entre .NET Framework 4.x e o .NET moderno (.NET 6+). Veja o que funciona em cada caso:
| Recurso | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | Sim | Sim | Sim | Sim |
SOCKS5 via WebProxy("socks5://...") | Não | Sim (adicionado no .NET 6) | Sim | Sim |
SocketsHttpHandler (handler padrão) | Não | Sim | Sim | Sim |
HttpClient.DefaultProxy estático | Não | Sim | Sim | Sim |
PooledConnectionLifetime | Não | Sim | Sim | Sim |
Se você estiver mirando o .NET Framework 4.x, fique com proxies HTTP/HTTPS usando HttpClientHandler e WebProxy. SOCKS5 e os controles modernos de pooling exigem .NET 6 ou superior.
Um comportamento sutil que vale observar: HttpClient.DefaultProxy é uma propriedade estática no .NET moderno. Se ela for definida em código de inicialização compartilhado ou herdada de variáveis de ambiente como HTTPS_PROXY ou HTTP_PROXY, toda instância de HttpClient vai usá-la, a menos que você sobrescreva explicitamente o handler. Em ambientes conteinerizados, isso costuma gerar a dúvida: “por que meu client está usando um proxy que eu nunca configurei?”
Passo 1: Crie um novo projeto Console em C#
Abra o terminal e crie um novo projeto:
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
Confira a versão do SDK com dotnet --version. Os exemplos deste guia usam .NET 6+ para cobrir todos os recursos. Se você precisar do SDK LTS mais recente, baixe na página de downloads da Microsoft.
Abra Program.cs no seu editor. É ali que tudo acontece.
Passo 2: Faça uma requisição HTTP base (sem proxy)
Antes de configurar um proxy, descubra qual é seu IP real de saída. Assim, quando o proxy estiver ativo, você consegue confirmar que o IP realmente mudou.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"IP direto: {ip}");
Execute o código. Você deve ver seu IP público atual, algo como:
IP direto: 203.0.113.10
Guarde esse valor na memória. Depois do próximo passo, ele deve ser diferente.
Passo 3: Configure um WebProxy com HttpClientHandler
O padrão clássico envolve três objetos: um WebProxy, um handler e o client.
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($"IP via proxy: {ip}");
Substitua proxy.example.com:8080 pelo endpoint real do seu proxy. Se tudo estiver certo, o IP exibido agora deve corresponder ao IP de saída do proxy — não ao seu IP real.
Propriedades importantes para entender:
Proxy— a instânciaIWebProxyusada pelo handler para roteamento.UseProxy = true— diz ao handler para realmente usar o proxy configurado. (Parece óbvio, mas esquecer isso faz você perder um bom tempo depurando.)BypassProxyOnLocal = false— impede que o handler ignore o proxy para destinos que pareçam “locais”.UseDefaultCredentials— controla se o handler envia credenciais padrão do Windows. Isso não é a mesma coisa que usuário e senha do proxy.
Passo 4: Adicione autenticação de proxy com NetworkCredential
A maioria dos provedores pagos de proxy exige credenciais. O padrão correto é defini-las no próprio objeto 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($"IP do proxy autenticado: {ip}");
Muitos provedores fornecem uma URL no formato http://username:password@host:port. Para código .NET, prefira NetworkCredential em vez de embutir credenciais na string da URI. Isso evita problemas de escaping com caracteres especiais na senha e deixa clara a separação entre URI e credenciais.
Vou cobrir o erro de autenticação mais comum — e por que ele gera erros 407 — em uma seção dedicada logo abaixo.
Passo 5: Exporte ou use os dados da resposta
Para qualquer coisa além de uma checagem rápida de IP, trate a resposta da forma certa:
using var response = await client.GetAsync("https://example.com/api/products");
if (!response.IsSuccessStatusCode)
{
Console.WriteLine($"Falha na requisição: {(int)response.StatusCode} {response.ReasonPhrase}");
return;
}
var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);
Em fluxos de scraping, a requisição via proxy é só a camada de transporte. Ainda é preciso fazer parsing, normalização, deduplicação, retries e exportação para Excel, Google Sheets, bancos de dados ou outros destinos. Ferramentas como a Thunderbit podem automatizar as etapas de extração e exportação — a extensão do Chrome cuida da extração estruturada e de exportações gratuitas para Google Sheets, Excel, Airtable ou Notion sem exigir que você escreva código de parsing.
Exporte dados extraídos para Excel, Sheets, Airtable ou Notion Get Started Free
Credenciais do proxy vs. credenciais do servidor: o erro que causa 407
Já vi esse erro em discussões no Stack Overflow, posts no Microsoft Q&A e — sendo bem sincero — no meu próprio código.
A distinção é simples, mas fácil de confundir:
- Credenciais do proxy autenticam você no próprio servidor proxy.
- Credenciais do servidor autenticam você no servidor de destino.
Em HttpClientHandler, isso fica em propriedades diferentes. Definir credenciais no lugar errado é a principal causa dos erros 407 Proxy Authentication Required.
// ❌ ERRADO — define credenciais para o servidor de destino, não para o proxy
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ CORRETO — define as credenciais no próprio objeto proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials aponta para o destino. WebProxy.Credentials aponta para o proxy. Se o proxy devolver 407, suas credenciais precisam estar no proxy.
Mais uma armadilha: HttpClientHandler.PreAuthenticate controla o comportamento de pré-autenticação para autenticação no servidor de destino. Ele não controla o cabeçalho Proxy-Authorization. Não use isso como solução para 407.
Como rotacionar proxies com HttpClient em C#
Desenvolvedores perguntam isso o tempo todo em fóruns. A resposta inicial costuma decepcionar: não dá para trocar o proxy de uma instância HttpClient já em execução. O proxy fica no handler. O handler é definido no momento da construção. O HttpClient não expõe uma propriedade mutável Proxy.
A gambiarra mais óbvia — new HttpClient(new HttpClientHandler { Proxy = ... }) para cada requisição — cria outro problema. A Microsoft alerta explicitamente que criar e descartar clients por requisição pode esgotar as portas TCP disponíveis, porque as portas não são liberadas imediatamente depois do fechamento da conexão.
Então aqui estão três padrões de nível de produção que realmente funcionam.
Opção 1: Clients nomeados via IHttpClientFactory
Se seu conjunto de proxies já é conhecido na inicialização, clients nomeados são a opção de menor complexidade. Cada client nomeado recebe sua própria configuração de handler, e o código da aplicação resolve pelo nome em tempo de execução.
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
});
// No momento da requisição:
var client = httpClientFactory.CreateClient("proxy-us");
A factory gerencia o tempo de vida dos handlers e evita o antipadrão de criar um client por requisição.
Opção 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
Para um client de longa duração atrás de um gateway de proxy que rotaciona o IP de saída em novas conexões, PooledConnectionLifetime força a recriação das conexões depois de um período configurado.
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);
Isso não muda magicamente o objeto Proxy a cada requisição. Funciona melhor com gateways de proxy que entregam um IP de saída diferente a cada nova conexão TCP, ou com pools de proxy baseados em DNS em que o hostname resolve para endpoints diferentes ao longo do tempo.
Opção 3: DelegatingHandler customizado para seleção avançada de proxy
Quando a escolha do proxy depende da URL da requisição, do payload ou do contexto em tempo real, um handler de roteamento customizado pode inspecionar cada requisição e encaminhá-la para a cadeia interna correta de handlers.
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);
}
}
Esse é um desenho avançado. Thread safety, disposal, reuso de handlers, comportamento de retry e logging passam a ser sua responsabilidade. Eu recomendaria essa abordagem só quando as duas primeiras realmente não derem conta.
Comparando as três abordagens
| Abordagem | Complexidade | Versão .NET | Thread safety | Overhead |
|---|---|---|---|---|
| Clients nomeados (IHttpClientFactory) | Baixa | .NET Core 2.1+ | Alta (configuração imutável) | Baixo |
| SocketsHttpHandler + PooledConnectionLifetime | Média | .NET 6+ | Alta | Baixo |
| DelegatingHandler customizado | Alta | Qualquer | Depende da implementação | Médio |
Para a maioria dos times, clients nomeados são o melhor ponto de partida. Migre para PooledConnectionLifetime em gateways rotativos estáveis e use roteamento customizado só quando a escolha do proxy depender de metadados da requisição.
Escolhendo o protocolo de proxy certo: HTTP, HTTPS e SOCKS5
Nem todo proxy fala a mesma língua, e usar o esquema de protocolo errado gera erros confusos.
Proxy HTTP: entende requisições HTTP. Para destinos HTTP simples, encaminha as requisições direto. Para destinos HTTPS, o cliente envia uma requisição CONNECT para criar um túnel, e então o TLS é negociado através desse túnel com o destino. Esse é o modelo mais comum.
Proxy com terminação HTTPS: o proxy apresenta seu próprio certificado TLS e recriptografa o tráfego upstream. É comum em sistemas corporativos de inspeção e em algumas APIs gerenciadas de scraping. Pode gerar erros de validação de certificado se o cliente não confiar na cadeia de certificados do proxy.
Proxy SOCKS5: um túnel TCP na camada de transporte que funciona para qualquer tráfego TCP, não apenas HTTP. É bastante usado por provedores de proxies residenciais. Suportado nativamente no .NET 6+.
Exemplo de 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);
Observação sobre validação de certificado SSL
Ao usar proxies com terminação HTTPS, você pode ver erros como RemoteCertificateNameMismatch. O ServerCertificateCustomValidationCallback permite personalizar a validação:
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
Use isso apenas em desenvolvimento local ou com um proxy TLS interceptador confiável e aprovado. Retornar true sem critério desativa uma verificação de segurança crítica e abre espaço para ataques man-in-the-middle. Em produção com proxies padrão CONNECT ou SOCKS, mantenha a validação SSL ativada.
Como solucionar erros comuns de proxy no HttpClient em C#
Esta tabela liga o sintoma visível à causa provável e ao primeiro ajuste que vale tentar. Eu recomendaria salvar esta seção nos favoritos — ela cobre os erros que mais aparecem em threads do Stack Overflow e em fóruns de desenvolvedores.
| Erro / Sintoma | Causa comum | Correção |
|---|---|---|
| 407 Proxy Authentication Required | Credenciais definidas em handler.Credentials em vez de handler.Proxy.Credentials; formato incorreto de usuário; caracteres especiais na senha embutidos na URL | Use WebProxy.Credentials = new NetworkCredential(...); evite embutir credenciais na URI; verifique o formato de usuário exigido pelo provedor |
| TaskCanceledException / Timeout | Endpoint do proxy lento, fora do ar, sobrecarregado ou bloqueado por firewall; timeout padrão de 100s insuficiente | Teste o proxy com curl; aumente HttpClient.Timeout só depois de confirmar que o endpoint funciona; adicione retries e verificações de saúde do proxy |
| SocketException / Exaustão de sockets | Criação e descarte de HttpClient ou handlers por requisição | Use IHttpClientFactory, clients singleton ou SocketsHttpHandler com controles de pooling |
| SSL RemoteCertificateNameMismatch | Interceptação HTTPS por proxy corporativo ou gerenciado | Instale/confie na CA do proxy quando apropriado; use validação customizada apenas em dev controlado ou cenários MITM aprovados |
| Loop de redirecionamento 302 | Página cativa do proxy/VPN corporativo ou bloqueio de allowlist redirecionando sem parar | Teste a conexão direta; inspecione cabeçalhos Location; verifique allowlist e portal de autenticação do proxy |
| HttpRequestException / Sem conexão com URL SOCKS | Código SOCKS executado em .NET Framework ou .NET antigo; esquema ou porta incorretos | Use .NET 6+ para suporte nativo a SOCKS; verifique socks5://host:port; teste com a documentação do provedor |
| Parece que o proxy está sendo ignorado | UseProxy = false; destino tratado como local; variável de ambiente NO_PROXY; handler configurado de forma diferente do esperado | Defina UseProxy = true; inspecione HttpClient.DefaultProxy; limpe ou sobrescreva variáveis de ambiente; defina BypassProxyOnLocal = false |
Fluxo rápido de debugging
- A requisição funcionou? → Sim: compare a saída de
api.ipify.orgcom o IP esperado do proxy. - Não, há um código de status HTTP? → 407: corrija as credenciais do proxy. 403/429: o destino bloqueou ou limitou o proxy. Loop 3xx: o proxy/gateway corporativo pode estar redirecionando.
- Não há código de status, só exceção? → Timeout: teste a conectividade do proxy. Exceção de socket/certificado: verifique pooling, protocolo, TLS e versão do .NET.
Comandos úteis para validar o proxy fora do .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/
Se o curl funcionar, mas seu código C# não, a diferença normalmente está no esquema de autenticação, no trust store de TLS, nas variáveis de ambiente ou no escaping das credenciais. Compare exatamente a URL do proxy, o esquema e a autenticação do curl e só depois mova as credenciais para NetworkCredential.
Quando ignorar o gerenciamento de proxy: a alternativa no-code
Uma parte considerável dos desenvolvedores que pesquisam “HttpClient proxy C#” não está tentando aprender teoria de proxies — está tentando manter um scraper funcionando. Vale a pena ser direto sobre quando o código C# com proxy é a ferramenta certa e quando não é.
Crie um scraper C# customizado com rotação de proxy quando:
- Você precisa de controle total sobre lógica de requisição, cookies, cabeçalhos, retries e parsing
- O scraper vai se integrar a uma base .NET existente ou a um serviço interno
- Requisitos de conformidade ou segurança exigem que você seja dono da infraestrutura de ponta a ponta
Use uma ferramenta no-code como a Thunderbit quando:
- O objetivo é extração estruturada de dados de sites, não infraestrutura HTTP
- Você prefere não manter pools de proxy, lidar com CAPTCHAs ou debugar exaustão de sockets
- O time precisa dos dados em Excel, Google Sheets, Airtable ou Notion sem escrever código de parsing
A extensão do Chrome da Thunderbit lida automaticamente com rotação de proxy e medidas anti-bot por meio da opção de scraping na nuvem. Sua API permite que desenvolvedores definam um esquema JSON e recebam dados estruturados de volta sem precisar gerenciar HttpClient ou WebProxy. Para times que fazem web scraping para comparação de preços ou extração de leads, a diferença de tempo de configuração é enorme.
| Cenário | C# customizado + proxy | Thunderbit |
|---|---|---|
| Controle total sobre a lógica de requisição | Sim | Não (controle em nível de API) |
| Gerenciamento de proxy necessário | Sim | Não (tratado automaticamente) |
| Tratamento de anti-bot / CAPTCHA | Manual ou de terceiros | Integrado |
| Tempo de configuração | De horas a dias | Minutos |
| Melhor para | Bases .NET existentes, pipelines customizados | Extração rápida de dados, equipes não técnicas, exportação para planilhas |
Isso não é um argumento para “nunca usar HttpClient”. Se você está construindo um serviço .NET de produção, precisa entender configuração de proxy. Mas se você está gastando horas depurando erros 407 para uma tarefa pontual de coleta de dados, existem opções mais simples — e não tem problema nenhum em usá-las. Você pode explorar os preços da Thunderbit ou conferir o canal no YouTube para tutoriais.
Principais conclusões
O padrão central continua o mesmo: WebProxy → handler → HttpClient. O resto é evitar os erros operacionais que aparecem em produção.
- As credenciais vão no proxy, não no handler. O trecho lado a lado na seção 407 é a coisa mais importante para lembrar.
- Não crie um novo
HttpClientpor requisição ou por proxy. UseIHttpClientFactorypara clients nomeados,SocketsHttpHandlercomPooledConnectionLifetimepara gateways rotativos, ou um handler de roteamento customizado para cenários avançados. - Confira sua versão do .NET antes de copiar código de SOCKS5 ou
SocketsHttpHandler. A matriz de compatibilidade acima evita falhas silenciosas. - Teste o proxy fora do .NET primeiro. Um comando rápido com
curlelimina uma grande categoria de debugging. - Para extração estruturada de dados sem dor de cabeça com proxy, ferramentas como a Thunderbit cuidam da camada de transporte para que você foque nos dados em si.
Na próxima vez que topar com um 407 ou um TaskCanceledException, comece pela tabela de troubleshooting acima.
Perguntas frequentes
Posso trocar o proxy de uma instância HttpClient já existente?
Não. O proxy fica preso ao handler, e o handler é definido no momento da construção. O HttpClient não expõe uma propriedade Proxy mutável. Para usar proxies diferentes, crie handlers e clients separados e gerencie-os com clients nomeados do IHttpClientFactory ou com um pool de clients pré-configurados.
O HttpClient usa o proxy do sistema por padrão?
Sim. No .NET moderno, se você não definir explicitamente um handler, o HttpClient herda as configurações padrão de proxy do sistema — incluindo variáveis de ambiente como HTTPS_PROXY e HTTP_PROXY via HttpClient.DefaultProxy. Para desativar isso, defina explicitamente UseProxy = false no handler.
Como usar um proxy SOCKS5 com HttpClient em C#?
Use new WebProxy("socks5://host:port") com SocketsHttpHandler. O suporte nativo a proxy SOCKS exige .NET 6 ou superior. No .NET Framework 4.x, SOCKS5 não é suportado nativamente — você precisaria de uma biblioteca de terceiros.
Por que continuo recebendo 407 Proxy Authentication Required?
Na maioria das vezes, você está definindo credenciais em handler.Credentials (que aponta para o servidor de destino) em vez de handler.Proxy.Credentials (que aponta para o proxy). Veja a seção “Credenciais do proxy vs. credenciais do servidor” acima para o padrão correto.
É seguro desativar a validação de certificado SSL ao usar um proxy?
Somente em desenvolvimento local ou quando você confia totalmente no provedor do proxy (por exemplo, uma API gerenciada de scraping em modo proxy HTTPS). Em produção com proxies padrão CONNECT ou SOCKS, mantenha a validação SSL ativada para evitar ataques man-in-the-middle.
Experimente a Thunderbit para web scraping sem esforço Get Started Free
Saiba mais
