Back to blog
NEW
DATA COLLECTION
PRICING INTELLIGENCE

How To Use a Proxy With HttpClient in C#: From Setup to Production

If your C# application sends many requests from the same IP, the target will block it – 403 errors, CAPTCHAs, or rate limits. This is common in web scraping, price monitoring, and data collection. A proxy server routes requests through a different IP, so the target doesn't see yours. This guide covers HttpClient proxy setup from basics to production: authentication, SSL handling, IP rotation, and IHttpClientFactory patterns on .NET 8+.

Lukas Mikelionis

Last updated: Mar 04, 2026

8 min read

TL;DR

  • Create a WebProxy with your proxy address, attach it to HttpClientHandler, and pass the handler to HttpClient
  • For authenticated proxies, set NetworkCredential on the WebProxy
  • In production, use IHttpClientFactory with SocketsHttpHandler to avoid socket exhaustion and recycle connections properly
  • For IP rotation, use a backconnect proxy (single endpoint, automatic IP assignment per connection) instead of managing proxy lists manually

How proxy routing works

A proxy server sits between your application and the target. Instead of connecting directly, the request flows like this:

Your C# app → proxy server → target website → proxy server → your C# app

The target site sees the proxy's IP address, not yours. The tradeoff is latency – every request takes an extra network hop through the proxy. In our tests, proxied requests averaged roughly 2–3x the response time of direct requests. Residential proxies are slower than datacenter proxies because traffic routes through real ISP connections, and the overhead varies with proxy location and target server. For most scraping and data collection, this is acceptable because the alternative is getting blocked entirely.

Setting this up in C# involves 3 core components:

  • WebProxy – holds the proxy server address, port, and optional credentials
  • HttpClientHandler – the handler that tells HttpClient how to send requests (including through which proxy)
  • HttpClient – the client itself, which receives the configured handler

If you're migrating from the older WebClient API, the concept is the same, but the implementation differs. WebClient is deprecated – HttpClient with WebProxy is the modern replacement.

Setting up your .NET project

You'll need the .NET 8 SDK installed. Check with:

dotnet --version

If the command isn't recognized or returns a version below 8.0, download the .NET 8 SDK from dotnet.microsoft.com. Run the installer, restart your terminal, and run dotnet --version again to confirm.

Create a new console project:

dotnet new console -o ProxyDemo
cd ProxyDemo

System.Net.Http is the namespace that contains HttpClient and its supporting types – it's the core library for making HTTP requests in .NET. It's included by default in .NET 8 projects, so no using statement is needed for it. You will need to add using System.Net; explicitly when working with WebProxy and NetworkCredential, but no NuGet packages are required yet.

The production section later uses the Microsoft.Extensions.Http.Polly package for retry policies, but it isn't needed until then.

Making a basic HTTP request without a proxy

Before adding a proxy, this is what a normal request looks like. It goes directly from your machine to the target. Add this to your Program.cs file

using System.Net.Http;


using var client = new HttpClient();
var response = await client.GetStringAsync("https://httpbin.org/ip");
Console.WriteLine(response);

Run it with dotnet run in your project folder.

Output:

{
  "origin": "203.0.113.42"
}

That origin value is your actual IP address. httpbin.org is a free HTTP testing service – its /ip endpoint returns the IP address it sees from the incoming request. You can also use ip.decodo.com/ip for the same purpose. The rest of this guide uses httpbin.org to verify that proxy routing works.

Configuring HttpClient to use a proxy

Now that you understand what a proxy does and the three components involved, here's how to wire them together. The minimal setup:

using System.Net;
using System.Net.Http;


var proxy = new WebProxy("http://proxy-host:8080");


var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};


using var client = new HttpClient(handler);
var response = await client.GetStringAsync("https://httpbin.org/ip");
Console.WriteLine(response);

The origin in the response should now show the proxy's IP, not yours – once you replace the placeholder with a working proxy address.

Proxy URL formats:

Format

Example

When to use

HTTP proxy

http://host:8080

Most common. Works for both HTTP and HTTPS target URLs

HTTPS proxy

https://host:8080

Encrypts the connection between your app and the proxy itself

SOCKS5 proxy

socks5://host:1080

Supported on .NET 6+ via SocketsHttpHandler (SOCKS5 vs HTTP proxy)

Common proxy ports are 8080, 3128, and 8888.

Skipping the proxy for local addresses

If you're running services locally and don't want local traffic to go through the proxy:

var proxy = new WebProxy("http://proxy-host:8080")
{
    BypassProxyOnLocal = true
};

You can also define a custom bypass list for specific domains:

var proxy = new WebProxy("http://proxy-host:8080")
{
    BypassProxyOnLocal = true,
    BypassList = new[] { @"\.internal\.company\.com$" }
};

This is useful in corporate environments where internal services shouldn't go through the external proxy.

Adding proxy authentication with credentials

Most paid proxy services, including Decodo's residential proxies, require authentication. The standard approach is to use NetworkCredential:

using System.Net;
using System.Net.Http;


var proxy = new WebProxy("http://gate.decodo.com:7000")
{
    Credentials = new NetworkCredential("your-username", "your-password")
};


var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};


using var client = new HttpClient(handler);
var response = await client.GetStringAsync("https://httpbin.org/ip");
Console.WriteLine(response);

If the credentials are wrong, you'll get a 407 Proxy Authentication Required response. See common proxy error codes if you run into authentication issues.

Don't hardcode credentials

Never hardcode proxy credentials in source code. Use environment variables or a secrets manager:

var proxyUser = Environment.GetEnvironmentVariable("PROXY_USER")
    ?? throw new InvalidOperationException("PROXY_USER not set");
var proxyPass = Environment.GetEnvironmentVariable("PROXY_PASS")
    ?? throw new InvalidOperationException("PROXY_PASS not set");


var proxy = new WebProxy("http://gate.decodo.com:7000")
{
    Credentials = new NetworkCredential(proxyUser, proxyPass)
};

To set these environment variables before running your application:

On Windows (PowerShell):

$env:PROXY_USER = "your-username"
$env:PROXY_PASS = "your-password"
dotnet run

On Linux/macOS (terminal):

export PROXY_USER="your-username"
export PROXY_PASS="your-password"
dotnet run

These are session-scoped – they last until you close the terminal. For a more permanent setup in development, add them to your project's launchSettings.json under environmentVariables.

For production applications, consider Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault.

Alternative – IP whitelisting

Some proxy providers support IP whitelisting as an alternative to username/password authentication. You whitelist your server's IP in the provider's dashboard, and the proxy accepts connections from that IP without credentials. This simplifies the code (no NetworkCredential needed) but only works when your application runs from a fixed IP address.

Fetching a real webpage through the proxy

The examples so far have all used httpbin.org/ip to verify routing. A real-world request is different – you're fetching an actual webpage, not just checking your IP:

using System.Net;
using System.Net.Http;


var proxy = new WebProxy("http://gate.decodo.com:7000")
{
    Credentials = new NetworkCredential("your-username", "your-password")
};


var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};


using var client = new HttpClient(handler);
client.DefaultRequestHeaders.UserAgent.ParseAdd(
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36");


var html = await client.GetStringAsync("https://books.toscrape.com/");
Console.WriteLine($"Page length: {html.Length} characters");
Console.WriteLine($"Contains title: {html.Contains("<title>")}");

The main difference from the httpbin.org test is the User-Agent header. Most real websites expect a browser-like user agent, and some will block requests that send a generic or missing one.

Dealing with SSL certificate errors

SSL certificate errors are a common problem when first using proxies with HttpClient. You'll typically see something like this:

System.Net.Http.HttpRequestException: The SSL connection could not be established
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid

Why this happens

It depends on how the proxy handles HTTPS traffic:

  • CONNECT tunneling – the proxy opens a raw TCP tunnel to the target. Your app negotiates encryption (the TLS handshake) directly with the target server, end-to-end. SSL validation works normally. Most residential proxy providers use this method.
  • TLS-intercepting proxy – the proxy decrypts the traffic itself, inspects or modifies it, then re-encrypts it before forwarding to the target. The certificate your app sees belongs to the proxy, not the target domain. This is what triggers SSL errors.

How to handle it

For trusted proxy providers that use TLS interception, you can bypass certificate validation for the proxy connection:

var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://gate.decodo.com:7000"),
    UseProxy = true,
    ServerCertificateCustomValidationCallback = (message, cert, chain, errors) =>
    {
        if (errors == System.Net.Security.SslPolicyErrors.None)
            return true;


        // WARNING: This bypasses SSL validation for ALL connections through this handler.
        // Only use with a trusted proxy provider. Log for monitoring.
        Console.WriteLine($"SSL validation bypassed: {errors}");
        return true;
    }
};

Important:

  • Only disable SSL validation for proxy providers you trust. Never do this with free or unknown proxies – you're allowing man-in-the-middle attacks.
  • If your proxy uses CONNECT tunneling (most reputable providers do), you shouldn't need to disable validation at all. The TLS connection goes end-to-end between your app and the target.
  • In production, log every bypassed validation so you can keep track of what's being skipped.

For details, see the SSL proxy guide.

Rotating proxies to avoid detection and blocks

Using a single proxy IP for all your requests makes you easy to detect. Anti-bot systems will eventually identify and block that IP.

There are 3 rotation strategies. Which one to use depends on your scale and budget.

1. Manual rotation from a proxy list

Maintain a pool of proxy addresses and cycle through them:

using System.Net;
using System.Net.Http;


var proxyUrls = new[]
{
    "http://proxy1:8080",
    "http://proxy2:8080",
    "http://proxy3:8080"
};


var random = new Random();


HttpClient CreateProxiedClient()
{
    var url = proxyUrls[random.Next(proxyUrls.Length)];
    var handler = new HttpClientHandler
    {
        Proxy = new WebProxy(url),
        UseProxy = true
    };
    return new HttpClient(handler);
}


// Use a fresh client per request (or per small batch)
for (int i = 0; i < 10; i++)
{
    using var client = CreateProxiedClient();
    try
    {
        var response = await client.GetStringAsync("https://httpbin.org/ip");
        Console.WriteLine($"Request {i}: {response.Trim()}");
    }
    catch (HttpRequestException ex)
    {
        Console.WriteLine($"Request {i} failed: {ex.Message}");
    }
}

This works for small-scale use, but you're managing the proxy list, health checking, and rotation logic yourself. It also creates a new HttpClient per request, which at scale causes socket exhaustion (your machine runs out of available network ports).

2. Provider-managed rotation (backconnect proxies)

This is the recommended approach for most use cases. You connect to a single gateway endpoint, and the provider assigns a different IP from their pool on each new connection. Decodo's rotating proxy network, for example, has 115M+ residential IPs across 195+ locations, which is large enough to avoid IP repetition in most scenarios.

There's an important detail here: backconnect proxies assign a new IP when a new TCP connection reaches the gateway. Since HttpClient keeps connections open and reuses them across requests, multiple requests through the same connection will share the same IP. To force new connections (and new IPs), use SocketsHttpHandler with a short PooledConnectionLifetime:

using System.Net;
using System.Net.Http;


// SocketsHttpHandler with short connection lifetime forces new connections (= new IPs)
var handler = new SocketsHttpHandler
{
    Proxy = new WebProxy("http://gate.decodo.com:7000")
    {
        Credentials = new NetworkCredential("user", "password")
    },
    UseProxy = true,
    PooledConnectionLifetime = TimeSpan.FromSeconds(1),
    PooledConnectionIdleTimeout = TimeSpan.FromSeconds(1)
};


using var client = new HttpClient(handler);


for (int i = 0; i < 5; i++)
{
    var response = await client.GetStringAsync("https://httpbin.org/ip");
    Console.WriteLine($"Request {i}: {response.Trim()}");
    await Task.Delay(1500); // Wait for connection to expire and recycle
}

In testing, this produced 5 unique IPs across 5 sequential requests – each connection recycled and the gateway assigned a fresh address. Each request gets a new connection (and therefore a new IP) because the pooled connection lifetime expires before the next request. Note: this works for sequential requests with a delay between them. For concurrent requests, multiple requests may share a connection – use separate HttpClient instances or the session-based approach below if you need distinct IPs in parallel. The proxy provider handles IP assignment, health checking, and switching to backup IPs when one goes down – all behind the scenes.

3. Session-based (sticky) rotation

Sometimes you need the same IP across multiple requests, for example, when a login flow spans several calls. Most providers support sticky sessions through a session parameter in the username:

// Same session ID = same IP for the session duration
var proxy = new WebProxy("http://gate.decodo.com:7000")
{
    Credentials = new NetworkCredential(
        "user-YOUR_USERNAME-session-mySession1-sessionduration-10",
        "your-password")
};


var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};


using var client = new HttpClient(handler);


// All 3 requests will use the same IP
for (int i = 0; i < 3; i++)
{
    var response = await client.GetStringAsync("https://httpbin.org/ip");
    Console.WriteLine($"Request {i}: {response.Trim()}");
}

The format depends on your provider. With Decodo, the session username format is user-USERNAME-session-SESSIONID-sessionduration-MINUTES. The sessionduration parameter controls how long the IP stays assigned (1–1440 minutes).

Comparing the 3 strategies

This is how the 3 approaches compare on the factors that matter most in practice:

Manual rotation

Backconnect (provider-managed)

Session-based (sticky)

Setup effort

High – maintain proxy list, health checks, rotation logic

Low – single endpoint, no rotation code

Low – session ID in username

IP diversity

Limited by your pool size

Millions of IPs (115M+ with Decodo)

One IP per session

Best for

Small-scale, specific proxy requirements

Most use cases, large-scale scraping

Login flows, multi-step interactions

Socket safety

Risk of exhaustion (new client per request)

Safe with SocketsHttpHandler

Safe (single client reuse)

Get residential proxies

Claim your 3-day free trial of residential proxies and explore full features with unrestricted access.

HttpClient proxy patterns for production

If you're building a quick script, the patterns above are sufficient. The rest of this section is for production applications that need to handle thousands of requests without leaking resources or failing silently.

Don't create a new HttpClient per request

This is the most common mistake with HttpClient in .NET, and it has caused outages in production services running behind proxies. Every new HttpClient(handler) creates a new handler and connection pool. When you dispose clients rapidly, the underlying sockets linger in a TIME_WAIT state (120 seconds on Windows, 60 seconds on Linux), which means your machine runs out of available ports. That is socket exhaustion, and you'll start seeing SocketException errors.

// DON'T do this in a loop
for (int i = 0; i < 1000; i++)
{
    using var client = new HttpClient(handler); // socket leak
    await client.GetStringAsync("https://example.com");
}

Use IHttpClientFactory

IHttpClientFactory manages HttpClient lifetimes, recycles handlers, and picks up DNS changes automatically. Here's a full production setup with proxy configuration:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using System.Net;


var builder = Host.CreateApplicationBuilder(args);


builder.Services.AddHttpClient("proxied", client =>
{
    client.Timeout = TimeSpan.FromSeconds(30);
})
.ConfigurePrimaryHttpMessageHandler(() =>
{
    var proxyUser = Environment.GetEnvironmentVariable("PROXY_USER") ?? "";
    var proxyPass = Environment.GetEnvironmentVariable("PROXY_PASS") ?? "";


    return new SocketsHttpHandler
    {
        Proxy = new WebProxy("http://gate.decodo.com:7000")
        {
            Credentials = new NetworkCredential(proxyUser, proxyPass)
        },
        UseProxy = true,
        PooledConnectionLifetime = TimeSpan.FromMinutes(2),
        PooledConnectionIdleTimeout = TimeSpan.FromMinutes(1),
        MaxConnectionsPerServer = 20
    };
});


var app = builder.Build();


// Resolve and use
var factory = app.Services.GetRequiredService<IHttpClientFactory>();
var client = factory.CreateClient("proxied");


var response = await client.GetStringAsync("https://httpbin.org/ip");
Console.WriteLine(response);

The reason for using SocketsHttpHandler is that it gives direct control over how connections are reused and recycled (PooledConnectionLifetime, PooledConnectionIdleTimeout) and how many can run at the same time. On .NET 6+, it's the default handler internally anyway.

PooledConnectionLifetime forces connections to be recycled periodically, which picks up DNS changes. Without it, if the proxy provider changes their DNS records, your app will not notice until it restarts.

Making concurrent requests through a proxy

When you need to fetch multiple URLs in parallel, which is common in price monitoring and data collection, use Task.WhenAll with a shared proxy-configured client:

var urls = new[]
{
    "https://httpbin.org/ip",
    "https://httpbin.org/headers",
    "https://httpbin.org/user-agent"
};


var tasks = urls.Select(async url =>
{
    var response = await client.GetStringAsync(url);
    return $"{url}: {response.Length} chars";
});


var results = await Task.WhenAll(tasks);
foreach (var result in results)
{
    Console.WriteLine(result);
}

This works well with IHttpClientFactory. The MaxConnectionsPerServer setting on SocketsHttpHandler controls how many simultaneous connections go to the proxy endpoint.

Add retry logic with Polly

Proxy connections fail – networks are unreliable, and proxy servers go down. Polly is a .NET resilience library that handles retries, timeouts, and circuit breakers. Install the package:

dotnet add package Microsoft.Extensions.Http.Polly

Then configure retries:

using Polly;
using Polly.Extensions.Http;


builder.Services.AddHttpClient("proxied", client =>
{
    client.Timeout = TimeSpan.FromSeconds(30);
})
.ConfigurePrimaryHttpMessageHandler(() =>
{
    return new SocketsHttpHandler
    {
        Proxy = new WebProxy("http://gate.decodo.com:7000")
        {
            Credentials = new NetworkCredential(
                Environment.GetEnvironmentVariable("PROXY_USER") ?? "",
                Environment.GetEnvironmentVariable("PROXY_PASS") ?? "")
        },
        UseProxy = true,
        PooledConnectionLifetime = TimeSpan.FromMinutes(2)
    };
})
.AddPolicyHandler(
    HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.ProxyAuthenticationRequired)
        .WaitAndRetryAsync(3, retryAttempt =>
            TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
        )
);

This retries failed requests up to 3 times with exponential backoff – each retry waits longer than the previous one (2s, 4s, 8s) to give the proxy or target time to recover. It handles transient HTTP errors (5xx, 408) and also retries on 407 Proxy Authentication Required, which can occur when a proxy gateway is under load.

Handle proxy-specific errors

To handle errors properly, catch specific exceptions instead of generic ones:

try
{
    var response = await client.GetAsync("https://target-site.com");
    response.EnsureSuccessStatusCode();
}
catch (HttpRequestException ex) when (ex.StatusCode == System.Net.HttpStatusCode.ProxyAuthenticationRequired)
{
    Console.WriteLine("Proxy auth failed - check credentials");
}
catch (HttpRequestException ex) when (ex.StatusCode == System.Net.HttpStatusCode.ServiceUnavailable)
{
    Console.WriteLine("Proxy or target unavailable - retry or switch proxy");
}
catch (TaskCanceledException)
{
    Console.WriteLine("Request timed out - proxy might be slow or unreachable");
}
catch (HttpRequestException ex)
{
    Console.WriteLine($"Request failed: {ex.Message}");
}

Use environment variables for proxy configuration

You can also configure proxy settings through environment variables instead of code. On .NET 6+, HttpClient reads HTTP_PROXY, HTTPS_PROXY, and NO_PROXY on all platforms – Windows, Linux, and macOS. Credentials go directly in the proxy URL:

// .NET 6+ reads these environment variables on all platforms (Windows, Linux, macOS)
// Format: http://username:password@host:port
Environment.SetEnvironmentVariable("HTTP_PROXY", "http://user:[email protected]:7000");
Environment.SetEnvironmentVariable("HTTPS_PROXY", "http://user:[email protected]:7000");
Environment.SetEnvironmentVariable("NO_PROXY", "localhost,127.0.0.1,.internal.corp");


// HttpClient created without explicit proxy config will use these
using var client = new HttpClient();
var response = await client.GetStringAsync("https://httpbin.org/ip");
Console.WriteLine(response);

This works well for Docker and Kubernetes setups where you set environment variables in Docker Compose or Kubernetes manifests without changing any code. In a Dockerfile or Kubernetes secret, set HTTP_PROXY and HTTPS_PROXY to your proxy URL – your C# code doesn't need any proxy-specific logic.

You can also set a global default for all HttpClient instances in code using the static HttpClient.DefaultProxy property. Environment variables are usually the better choice because they don't require code changes across environments.

Choosing the right C# HttpClient proxy approach

Setting up a C# HttpClient proxy starts with 3 components: a WebProxy, a handler, and the client. Moving to production means getting the details right: credential management, SSL handling, rotation strategies, and proper connection management with IHttpClientFactory.

To summarize the recommended approach for each scenario:

  • Quick scripts and prototyping – WebProxy + HttpClientHandler is sufficient.
  • Production applications – use IHttpClientFactory with SocketsHttpHandler. Add Polly for retries. Store credentials in environment variables or a secrets manager.
  • IP rotation – use a backconnect proxy service like Decodo instead of building your own rotation logic. The provider handles IP rotation, dead proxy replacement, and session management automatically.
  • Browser automation – if you're using Selenium alongside HttpClient, the Decodo Selenium repository has ready-made C# examples with proxy configuration.

For a broader look at C# web scraping beyond proxy configuration – HTML parsing, JavaScript-rendered pages, and scaling – see the C# web scraping guide.

If you don't have a proxy provider yet, Decodo offers a free trial. Follow the residential proxy quickstart to get your credentials from the dashboard, then paste them into any code example in this guide. Decodo also has setup guides for 50+ tools if you need proxy configuration beyond HttpClient.

C# HttpClient proxy quick reference

This table summarizes every pattern covered in this guide:

Task

Pattern

Basic proxy

new WebProxy("http://host:port") → HttpClientHandler → HttpClient

Authentication

WebProxy.Credentials = new NetworkCredential(user, pass)

Bypass local

WebProxy.BypassProxyOnLocal = true

Rotate IPs (backconnect)

SocketsHttpHandler + PooledConnectionLifetime = TimeSpan.FromSeconds(1)

Sticky session

Username format: user-NAME-session-ID-sessionduration-MIN

Production setup

IHttpClientFactory + ConfigurePrimaryHttpMessageHandler

Retry on failure

HttpPolicyExtensions.HandleTransientHttpError().WaitAndRetryAsync(3, ...)

Env var proxy

Set HTTP_PROXY / HTTPS_PROXY = http://user:pass@host:port

Conclusion 

Proxies handle the IP side of the problem. But targets also check request timing and user agents – if every request hits at the same interval with the same headers, the proxy IP doesn't help much. Add random delays between requests, rotate user agents, and make sure failed requests get retried instead of dropped. The patterns in this guide cover the proxy setup. The rest depends on what you're scraping and at what scale.

About the author

Lukas Mikelionis

Senior Account Manager

Lukas is a seasoned enterprise sales professional with extensive experience in the SaaS industry. Throughout his career, he has built strong relationships with Fortune 500 technology companies, developing a deep understanding of complex enterprise needs and strategic account management.


Connect with Lukas via LinkedIn.

All information on Decodo Blog is provided on an as is basis and for informational purposes only. We make no representation and disclaim all liability with respect to your use of any information contained on Decodo Blog or any third-party websites that may belinked therein.

Frequently asked questions

How do I test that my proxy is actually working?

Send a request to https://httpbin.org/ip or https://api.ipify.org through your proxy-configured HttpClient. The response will show the IP address the target server sees. If it shows the proxy's IP instead of your machine's IP, the proxy is working correctly. For a more thorough verification process, see the guide on how to test proxies.

Why do SSL certificate errors occur with C# HttpClient proxies, and how can I fix them?

SSL errors happen when a proxy decrypts and re-encrypts traffic using its own certificate. Your HttpClient sees a certificate that doesn't match the target domain and rejects it. If you're using a trusted proxy provider, you can set ServerCertificateCustomValidationCallback on the handler to bypass validation. If your proxy uses CONNECT tunneling (most residential proxy providers do), TLS goes end-to-end and SSL errors shouldn't occur.

Is it better to create a new HttpClient for each request or reuse one instance?

Reuse whenever possible. Creating a new HttpClient per request causes socket exhaustion – your app runs out of available network ports and starts throwing SocketException. The recommended approach is IHttpClientFactory, which pools and recycles handlers automatically. The one exception is manual proxy rotation, where you may need different handler configurations per request. Even then, IHttpClientFactory with named clients is the cleaner solution.

Does C# HttpClient support automatic proxy rotation out of the box?

No. HttpClient doesn't have built-in proxy rotation. You have 2 options: manually create multiple proxy-configured clients and rotate between them, or use a backconnect proxy service that rotates IPs behind a single gateway endpoint. The second approach is simpler because your code doesn't need rotation logic – you point to one endpoint and the provider handles the rest.

What's the difference between HTTP, HTTPS, and SOCKS5 proxies in C# HttpClient?

An HTTP proxy relays HTTP traffic and uses the CONNECT method for HTTPS targets. An HTTPS proxy adds encryption between your app and the proxy itself. A SOCKS5 proxy operates at a lower level – it forwards TCP traffic without understanding HTTP, which makes it more versatile but also means it can't modify headers. In .NET 6+, SOCKS5 is supported through SocketsHttpHandler. For most web scraping and data collection use cases, HTTP proxies are sufficient.

© 2018-2026 decodo.com (formerly smartproxy.com). All Rights Reserved