Cómo usar un proxy con HttpClient en C#: patrones y soluciones

La semana pasada perdí una cantidad vergonzosa de tiempo mirando una respuesta 407 Proxy Authentication Required, convencido de que mi proveedor de proxy estaba fallando. Al final resultó que había puesto las credenciales en la propiedad equivocada: una solución de dos líneas que me tomó dos horas descubrir. Si te suena familiar, esta guía es para ti.

Configurar un proxy con HttpClient en C# es uno de esos temas en los que el patrón básico es fácil de entender, pero los detalles que aparecen en producción —agotamiento de sockets, incompatibilidades con SOCKS5, líos con las credenciales— se comen muchísimo tiempo.

Llevo un tiempo trabajando con herramientas de web scraping y extracción de datos en Thunderbit, y he visto estos mismos errores una y otra vez, tanto en conversaciones de ingeniería como en las comunidades de desarrolladores que seguimos. Esta guía recorre el proceso completo: configuración, autenticación, rotación de proxies, elección de protocolo y una tabla de solución de problemas que de verdad habría querido tener el primer día.

Nivel de dificultad: De principiante a intermedio
Tiempo estimado: ~15 minutos para seguir el tutorial, más tiempo si quieres aplicar patrones de rotación en producción
Lo que necesitarás: SDK de .NET 6+ (para SOCKS5 y las funciones modernas del handler; .NET Framework 4.x sirve para ejemplos básicos de proxy HTTP), un editor de código y al menos un endpoint de proxy para hacer pruebas

¿Qué es HttpClient y por qué necesita un proxy?

HttpClient es la clase integrada de .NET en System.Net.Http para enviar solicitudes HTTP y recibir respuestas. Admite async/await, encabezados personalizados, tokens de cancelación y configuración basada en handlers. Microsoft la describe como una clase para enviar solicitudes HTTP y recibir respuestas HTTP de un recurso identificado por una URI.

Un servidor proxy funciona como intermediario entre tu aplicación y el sitio web destino. Cuando enrutas el tráfico a través de un proxy, el destino ve la IP del proxy en vez de la tuya.

HttpClient no tiene una propiedad Proxy propia. El enrutamiento del proxy se configura en el handler subyacente —ya sea HttpClientHandler o SocketsHttpHandler—, que acepta una instancia de WebProxy. El modelo mental es este:

[Tu app C#] → [HttpClient + Handler] → [Servidor proxy] → [Sitio web destino]

Por eso “cambiar el proxy en un HttpClient ya en uso” es un problema de diseño, no una simple asignación de propiedad. Volveremos a eso en la sección de rotación.

Prueba Thunderbit para extraer datos más fácilmente

Por qué usar un proxy con HttpClient en C#

Los desarrolladores enrutan el tráfico de HttpClient a través de proxies por varias razones muy repetidas, y el tipo de proxy correcto depende del caso.

Evitar bloqueos de IP y límites de velocidad: Es clave para web scraping, generación de leads o monitoreo de precios a gran escala. Una sola IP golpeando un sitio sin parar será bloqueada pronto.
Omitir restricciones geográficas: Accede a APIs o contenido restringidos por región usando proxies ubicados en países concretos.
Ocultar tu IP de origen: Añade una capa de privacidad para recopilación sensible de datos o investigación competitiva.
Requisitos corporativos o de cumplimiento: Muchas empresas exigen que el tráfico saliente pase por una puerta de enlace centralizada para registro y gobernanza.
Pruebas y QA: Simula solicitudes desde distintas ubicaciones o condiciones de red sin desplegar infraestructura físicamente en esas regiones.

Caso de uso	Proxy habitual	Por qué encaja
Web scraping a gran escala	Proxies residenciales rotativos	Más diversidad de IP, más difícil que los sistemas anti-bot los clasifiquen
Monitoreo de precios en e-commerce	Residencial o datacenter geolocalizado	Verificación de precios e inventario por región
Acceso a APIs mediante una puerta de enlace fija	Proxy de datacenter o proxy corporativo	Allowlisting predecible, menor coste
Cumplimiento empresarial	Proxy del sistema, proxy PAC, proxy corporativo autenticado	Registro centralizado y control del tráfico saliente
QA y pruebas de localización	Pool de proxies por país	Simula acceso real de usuarios desde regiones objetivo

El uso de proxies también suele escalar por etapas bastante previsibles. Empiezas con un proxy estático para confirmar el enrutamiento. Un scraper de producción pasa a un pool, asignando solicitudes a proxies según el dominio de destino, la geografía o la tasa de fallos. Los equipos más maduros suelen acabar en una puerta de enlace de proxy gestionada, donde la rotación, los reintentos y la afinidad de sesión quedan detrás de un único endpoint.

La rotación de proxies no es una solución mágica. Si un destino bloquea comportamientos sospechosos, cambiar de IP solo ayuda si también controlas con cuidado la cadencia de solicitudes, los encabezados, las cookies y el fingerprint TLS.

Qué versión de .NET soporta cada cosa: tabla rápida de compatibilidad

Copiar un fragmento de proxy de un artículo de blog en el framework equivocado es una fuente importante de fallos silenciosos. La gran división está entre .NET Framework 4.x y .NET moderno (.NET 6+). Esto es lo que funciona en cada caso:

.net-version-comparison.webp

Capacidad	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
`WebProxy` + `HttpClientHandler`	Sí	Sí	Sí	Sí
SOCKS5 mediante `WebProxy("socks5://...")`	No	Sí (añadido en .NET 6)	Sí	Sí
`SocketsHttpHandler` (handler predeterminado)	No	Sí	Sí	Sí
`HttpClient.DefaultProxy` estático	No	Sí	Sí	Sí
`PooledConnectionLifetime`	No	Sí	Sí	Sí

Si vas a apuntar a .NET Framework 4.x, quédate con proxies HTTP/HTTPS usando HttpClientHandler y WebProxy. SOCKS5 y los controles modernos de pooling requieren .NET 6 o posterior.

Un comportamiento sutil que conviene vigilar: HttpClient.DefaultProxy es una propiedad estática en .NET moderno. Si se define en código de arranque compartido o se hereda de variables de entorno como HTTPS_PROXY o HTTP_PROXY, cualquier instancia de HttpClient la usará salvo que sobrescribas explícitamente el handler. En despliegues en contenedores, esta es una fuente muy común de confusión: “¿por qué mi cliente está usando un proxy que yo nunca configuré?”.

Paso 1: Crear un nuevo proyecto de consola en C#

Abre una terminal y crea un proyecto nuevo:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Comprueba la versión del SDK con dotnet --version. Los ejemplos de esta guía están pensados para .NET 6+ para cubrir todas las funciones. Si necesitas el último SDK LTS, descárgalo desde la página de descargas de Microsoft.

Abre Program.cs en tu editor. Ahí es donde ocurre todo.

Paso 2: Hacer una solicitud HTTP base (sin proxy)

Antes de configurar un proxy, identifica tu IP de salida real. Así, cuando actives el proxy, podrás confirmar que la IP realmente cambió.

using System.Net.Http;

using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"IP directa: {ip}");

Ejecuta el código. Deberías ver tu IP pública actual, algo como esto:

IP directa: 203.0.113.10

Guarda ese valor en la memoria. Después del siguiente paso, debería ser diferente.

Paso 3: Configurar un WebProxy con HttpClientHandler

El patrón clásico usa tres objetos: un WebProxy, un handler y el cliente.

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 del proxy: {ip}");

Sustituye proxy.example.com:8080 por tu endpoint real. Si todo está bien configurado, la IP de salida debería coincidir ahora con la del proxy, no con la tuya.

Propiedades clave que debes entender:

Proxy — la instancia IWebProxy que usa el handler para enrutar.
UseProxy = true — indica al handler que use realmente el proxy configurado. (Parece obvio, pero olvidarlo consume muchísimo tiempo de depuración.)
BypassProxyOnLocal = false — evita que el handler se salte el proxy para destinos que parecen “locales”.
UseDefaultCredentials — controla si el handler envía credenciales predeterminadas de Windows. No es lo mismo que usuario/contraseña del proxy.

Paso 4: Añadir autenticación de proxy con NetworkCredential

La mayoría de los proveedores de proxy de pago requieren credenciales. El patrón correcto es configurarlas en el propio 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 del proxy autenticado: {ip}");

Muchos proveedores ofrecen un formato de URL como http://username:password@host:port. En código .NET, conviene usar NetworkCredential en lugar de incrustar credenciales en la URI. Así evitas problemas de escape con caracteres especiales en la contraseña y mantienes clara la separación entre la URI y las credenciales.

Más abajo cubro el error de autenticación más común —y por qué provoca respuestas 407— en una sección dedicada.

Paso 5: Exportar o usar los datos de la respuesta

Para cualquier cosa que vaya más allá de una comprobación rápida de IP, maneja la respuesta correctamente:

using var response = await client.GetAsync("https://example.com/api/products");

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"La solicitud falló: {(int)response.StatusCode} {response.ReasonPhrase}");
    return;
}

var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);

En flujos de scraping, la solicitud a través del proxy es solo la capa de transporte. Aun así necesitas análisis, normalización, deduplicación, reintentos y exportación a Excel, Google Sheets, bases de datos u otros destinos. Herramientas como Thunderbit pueden automatizar la extracción y la exportación: su extensión de Chrome gestiona la extracción de datos estructurados y exportaciones gratis a Google Sheets, Excel, Airtable o Notion sin que tengas que escribir código de parsing.

Exporta datos extraídos a Excel, Sheets, Airtable o Notion Get Started Free

Credenciales del proxy vs. credenciales del servidor: el error que provoca 407

He visto este error en hilos de Stack Overflow, publicaciones de Microsoft Q&A y, siendo sincero, también en mi propio código.

La diferencia es sencilla, pero muy fácil de confundir:

Las credenciales del proxy te autentican ante el propio servidor proxy.
Las credenciales del servidor te autentican ante el servidor de destino.

En HttpClientHandler, viven en propiedades distintas. Poner las credenciales en la propiedad equivocada es la causa número uno de los errores 407 Proxy Authentication Required.

// ❌ INCORRECTO — establece credenciales para el servidor destino, no para el proxy
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ CORRECTO — establece credenciales en el propio objeto proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials apunta al destino. WebProxy.Credentials apunta al proxy. Si el proxy devuelve 407, tus credenciales pertenecen al proxy.

Otra trampa: HttpClientHandler.PreAuthenticate controla el comportamiento de preautenticación para la autenticación del servidor destino. No controla el encabezado Proxy-Authorization. No lo uses como solución para un 407.

Cómo rotar proxies con HttpClient en C#

Los desarrolladores preguntan esto constantemente en foros. La respuesta, al principio, decepciona: no puedes cambiar el proxy en una instancia viva de HttpClient. El proxy vive en el handler. El handler se define al construirlo. HttpClient no expone una propiedad Proxy modificable.

El atajo ingenuo —new HttpClient(new HttpClientHandler { Proxy = ... }) para cada solicitud— crea otro problema. Microsoft advierte explícitamente que crear y destruir clientes por cada solicitud puede agotar los puertos TCP disponibles porque los puertos no se liberan inmediatamente después de cerrar la conexión.

Así que aquí tienes tres patrones de nivel producción que sí funcionan.

Opción 1: clientes con nombre mediante IHttpClientFactory

Si tu conjunto de proxies se conoce al iniciar, los clientes con nombre son la opción menos compleja. Cada cliente con nombre recibe su propia configuración de handler y el código de la aplicación resuelve por nombre en tiempo de ejecución.

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

// En tiempo de solicitud:
var client = httpClientFactory.CreateClient("proxy-us");

La fábrica gestiona la vida útil de los handlers y evita el antipatrón de crear un cliente por cada solicitud.

Opción 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)

Para un cliente de larga vida detrás de una puerta de enlace proxy que rota IPs de salida en conexiones nuevas, PooledConnectionLifetime fuerza que las conexiones se recreen tras una duración configurada.

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

Esto no cambia mágicamente el objeto Proxy por solicitud. Funciona mejor con puertas de enlace proxy que asignan una IP de salida distinta en cada nueva conexión TCP, o con pools de proxies basados en DNS donde el host resuelve a distintos endpoints con el tiempo.

Opción 3: DelegatingHandler personalizado para selección avanzada de proxy

Cuando la selección de proxy depende de la URL de la solicitud, del payload o del contexto en tiempo de ejecución, un handler de enrutamiento personalizado puede inspeccionar cada solicitud y enviarla al pipeline interno correcto.

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

Este es un diseño avanzado. La seguridad de hilos, la liberación de recursos, la reutilización de handlers, el comportamiento de reintentos y el logging pasan a ser tu responsabilidad. Yo solo lo recomendaría cuando las dos primeras opciones realmente no encajen.

Comparación de los tres enfoques

Enfoque	Complejidad	Versión de .NET	Seguridad de hilos	Sobrecarga
Clientes con nombre (IHttpClientFactory)	Baja	.NET Core 2.1+	Alta (configuración inmutable)	Baja
SocketsHttpHandler + PooledConnectionLifetime	Media	.NET 6+	Alta	Baja
DelegatingHandler personalizado	Alta	Cualquiera	Depende de la implementación	Media

Para la mayoría de los equipos, los clientes con nombre son el mejor punto de partida. Pasa a PooledConnectionLifetime para puertas de enlace rotativas estables, y usa enrutamiento personalizado solo cuando la elección del proxy dependa de metadatos por solicitud.

Cómo elegir el protocolo de proxy correcto: HTTP, HTTPS y SOCKS5

No todos los proxies hablan el mismo idioma, y usar un esquema de protocolo incorrecto generará errores confusos.

Proxy HTTP: entiende solicitudes HTTP. Para destinos HTTP normales, puede reenviar las solicitudes directamente. Para destinos HTTPS, el cliente envía una solicitud CONNECT para crear un túnel, y luego se negocia TLS a través de ese túnel con el destino. Este es el modelo más común.

Proxy que termina HTTPS: el proxy presenta su propio certificado TLS y vuelve a cifrar el tráfico hacia el origen. Es habitual en sistemas corporativos de inspección y en algunas APIs gestionadas de scraping. Puede provocar errores de validación de certificados si el cliente no confía en la cadena del certificado del proxy.

Proxy SOCKS5: un túnel TCP a nivel de transporte que sirve para cualquier tráfico TCP, no solo HTTP. Muy usado por proveedores de proxies residenciales. Tiene soporte nativo en .NET 6+.

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

Nota sobre la validación de certificados SSL

Cuando uses proxies que terminan HTTPS, puedes ver errores RemoteCertificateNameMismatch. El ServerCertificateCustomValidationCallback permite personalizar la validación:

var handler = new HttpClientHandler
{
    ServerCertificateCustomValidationCallback =
        HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};

Úsalo solo en desarrollo local o con un proxy TLS interceptado de confianza y aprobado. Devolver true sin comprobar nada desactiva una verificación de seguridad crítica y te expone a ataques de intermediario. En producción, con proxies CONNECT o SOCKS estándar, mantén la validación SSL activada.

Solución de problemas comunes de proxy en C# HttpClient

Esta tabla relaciona el síntoma visible con la causa raíz probable y la primera solución que deberías probar. Te recomiendo guardar esta sección: cubre los errores que aparecen con más frecuencia en hilos de Stack Overflow y foros de desarrolladores.

Error / síntoma	Causa habitual	Solución
407 Proxy Authentication Required	Credenciales puestas en `handler.Credentials` en lugar de `handler.Proxy.Credentials`; formato de usuario incorrecto; caracteres especiales en la contraseña incrustada en la URL	Usa `WebProxy.Credentials = new NetworkCredential(...)`; evita incrustar credenciales en la URI; verifica el formato de usuario del proveedor
TaskCanceledException / Timeout	Endpoint del proxy lento, inaccesible, saturado o bloqueado por firewall; el timeout predeterminado de 100s es demasiado corto	Prueba el proxy con `curl`; aumenta `HttpClient.Timeout` solo después de comprobar que el endpoint funciona; añade reintentos y comprobaciones de salud del proxy
SocketException / agotamiento de sockets	Crear y desechar `HttpClient` o handlers por cada solicitud	Usa `IHttpClientFactory`, clientes singleton o `SocketsHttpHandler` con controles de pooling
SSL RemoteCertificateNameMismatch	Intercepción HTTPS por un proxy corporativo o gestionado	Instala/confía en la CA del proxy cuando corresponda; usa validación personalizada solo en desarrollo controlado o escenarios MITM aprobados
Bucle de redirección 302	Página cautiva del proxy/VPN corporativo o bloqueo por allowlist que redirige repetidamente	Prueba la conexión directa; inspecciona los encabezados `Location`; revisa la allowlist del proxy y el portal de autenticación
HttpRequestException / sin conexión con URL SOCKS	Código SOCKS ejecutándose en .NET Framework u otra versión antigua; esquema o puerto incorrectos	Usa .NET 6+ para soporte nativo de SOCKS; verifica `socks5://host:port`; prueba con la documentación del proveedor
El proxy parece ignorarse	`UseProxy = false`; destino omitido por ser local; variable de entorno `NO_PROXY`; handler configurado de forma distinta a la esperada	Establece `UseProxy = true`; revisa `HttpClient.DefaultProxy`; limpia o sobrescribe variables de entorno; fija `BypassProxyOnLocal = false`

Flujo rápido de depuración

¿La solicitud se completó? → Sí: compara la salida de api.ipify.org con la IP esperada del proxy.
No, ¿hay un código HTTP? → 407: corrige las credenciales del proxy. 403/429: el destino bloqueó el proxy o lo limitó por rate limit. Bucle 3xx: el proxy o la puerta de enlace corporativa puede estar redirigiendo.
No hay código, solo una excepción? → Timeout: prueba la conectividad del proxy. Socket/certificate exception: revisa pooling, protocolo, TLS y la versión de .NET.

Comandos útiles para validar el proxy fuera de .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/

Si curl funciona pero tu código en C# no, la diferencia suele estar en el esquema de autenticación, el almacén de confianza TLS, las variables de entorno o el escape de credenciales. Haz que la URL del proxy, el esquema y la autenticación coincidan exactamente con curl, y luego mueve las credenciales a NetworkCredential.

Cuándo omitir la gestión de proxies: la alternativa sin código

Una parte importante de quienes buscan “HttpClient proxy C#” no está intentando aprender teoría de proxies: solo quiere que un scraper siga funcionando. Vale la pena ser honestos sobre cuándo el código C# personalizado es la herramienta adecuada y cuándo no.

Construye un scraper C# personalizado con rotación de proxies cuando:

Necesitas control total sobre la lógica de solicitudes, cookies, encabezados, reintentos y parsing
El scraper se integra en una base de código .NET o en un servicio interno ya existente
Los requisitos de cumplimiento o seguridad exigen que controles la infraestructura de extremo a extremo

Usa una herramienta sin código como Thunderbit cuando:

El objetivo es extraer datos estructurados de sitios web, no gestionar infraestructura HTTP
Prefieres no mantener pools de proxies, lidiar con CAPTCHAs o depurar agotamiento de sockets
El equipo necesita los datos en Excel, Google Sheets, Airtable o Notion sin escribir código de parsing

La extensión de Chrome de Thunderbit gestiona automáticamente la rotación de proxies y las medidas anti-bot mediante su opción de scraping en la nube. Su API permite a los desarrolladores definir un esquema JSON y recibir datos estructurados sin gestionar HttpClient ni WebProxy. Para equipos que hacen web scraping para comparar precios o extracción de leads, la diferencia de tiempo de configuración es enorme.

Escenario	C# personalizado + proxy	Thunderbit
Control total sobre la lógica de solicitudes	Sí	No (control a nivel API)
Gestión de proxies requerida	Sí	No (gestionado automáticamente)
Manejo anti-bot / CAPTCHA	Manual o de terceros	Integrado
Tiempo de configuración	Horas a días	Minutos
Mejor para	Bases de código .NET existentes, pipelines personalizados	Extracción rápida de datos, equipos no técnicos, exportación a hojas de cálculo

Esto no significa “nunca uses HttpClient”. Si estás construyendo un servicio .NET de producción, deberías entender la configuración de proxies. Pero si te estás pasando horas depurando errores 407 para un trabajo puntual de recogida de datos, existen opciones más sencillas, y no pasa nada por usarlas. Puedes explorar los precios de Thunderbit o ver el canal de YouTube para tutoriales.

Conclusiones clave

El patrón central sigue siendo el mismo: WebProxy → handler → HttpClient. Todo lo demás consiste en evitar los errores operativos que aparecen en producción.

Las credenciales van en el proxy, no en el handler. El ejemplo lado a lado de la sección 407 es lo más importante que debes recordar.
No crees un nuevo HttpClient por cada solicitud ni por cada proxy. Usa IHttpClientFactory para clientes con nombre, SocketsHttpHandler con PooledConnectionLifetime para puertas de enlace rotativas, o un handler de enrutamiento personalizado para escenarios avanzados.
Comprueba tu versión de .NET antes de copiar código de SOCKS5 o SocketsHttpHandler. La tabla de compatibilidad anterior te ahorra fallos silenciosos.
Prueba el proxy fuera de .NET primero. Un comando rápido con curl elimina una buena cantidad de problemas.
Para extraer datos estructurados sin dolores de cabeza con los proxies, herramientas como Thunderbit gestionan la capa de transporte para que puedas centrarte en los datos.

La próxima vez que te encuentres con un 407 o un TaskCanceledException, empieza por la tabla de solución de problemas anterior.

Preguntas frecuentes

¿Puedo cambiar el proxy en una instancia existente de HttpClient?

No. El proxy queda asociado al handler, y el handler se fija al construirlo. HttpClient no expone una propiedad Proxy modificable. Para usar proxies distintos, crea handlers y clientes separados, y adminístralos con clientes con nombre de IHttpClientFactory o con un pool de clientes preconfigurados.

¿HttpClient usa el proxy del sistema por defecto?

Sí. En .NET moderno, si no defines explícitamente un handler, HttpClient hereda la configuración de proxy predeterminada del sistema, incluidas variables de entorno como HTTPS_PROXY y HTTP_PROXY a través de HttpClient.DefaultProxy. Para desactivarlo, establece explícitamente UseProxy = false en el handler.

¿Cómo uso un proxy SOCKS5 con HttpClient en C#?

Usa new WebProxy("socks5://host:port") con SocketsHttpHandler. El soporte nativo para proxies SOCKS requiere .NET 6 o posterior. En .NET Framework 4.x, SOCKS5 no tiene soporte nativo; necesitarías una librería de terceros.

¿Por qué sigo recibiendo 407 Proxy Authentication Required?

Lo más probable es que estés poniendo las credenciales en handler.Credentials —que apunta al servidor destino— en lugar de handler.Proxy.Credentials —que apunta al proxy—. Consulta la sección “Credenciales del proxy vs. credenciales del servidor” más arriba para ver el patrón correcto.

¿Es seguro desactivar la validación del certificado SSL cuando uso un proxy?

Solo en desarrollo local o cuando confías por completo en el proveedor del proxy (por ejemplo, una API de scraping gestionada en modo proxy HTTPS). En producción, con proxies CONNECT o SOCKS estándar, mantén la validación SSL activa para evitar ataques de intermediario.

Prueba Thunderbit para hacer web scraping sin esfuerzo Get Started Free

Más información