BestFREE.nl

Proxy with httpclient

•

BestFREE.nl

Updated on

To solve the problem of routing your HTTP requests through a proxy with HttpClient in C#, here are the detailed steps:

👉 Skip the hassle and get the ready to use 100% working script (Link in the comments section of the YouTube Video) (Latest test 31/05/2025)

First, you’ll need to define your proxy settings.

This typically involves specifying the proxy server address and port.

For a basic scenario, you might use a WebProxy object or configure the HttpClientHandler directly.

If your proxy requires authentication, you’ll also need to provide credentials.

Finally, assign this configured handler to your HttpClient instance before making any requests.

Remember, HttpClient is designed for reuse, so configure it once and use it for multiple requests for optimal performance.

Table of Contents

Understanding HTTP Proxies and Their Role

HTTP proxies serve as intermediaries between a client and a target server, relaying requests and responses.

They play a crucial role in various network architectures, offering benefits ranging from enhanced security and performance to anonymity and access control.

Think of them as a gatekeeper, inspecting and directing traffic based on predefined rules.

A common use case is within corporate networks, where all outgoing traffic must pass through a proxy for security auditing and content filtering.

For example, a 2023 report by Zscaler indicated that over 70% of enterprise web traffic is now encrypted, highlighting the importance of proxies in decrypting and inspecting this traffic for threats. Structured vs unstructured data

Why Use a Proxy with HttpClient?

The primary reasons for integrating a proxy with HttpClient revolve around network policy, security, and data accessibility.

  • Accessing Geo-Restricted Content: You might need to route requests through a proxy located in a specific country to access services or data that are geographically restricted. For instance, a researcher might need to access public datasets available only to IP addresses within a certain region.
  • Bypassing Firewalls or Network Restrictions: In some environments, direct outbound connections are blocked, and all traffic must flow through an approved proxy. This is common in enterprise settings to maintain network security and compliance.
  • Anonymity and Privacy: While not its sole purpose, proxies can obscure your client’s IP address, providing a layer of anonymity. However, for robust anonymity, a chain of proxies or dedicated anonymity services is often required.
  • Caching and Performance Improvement: Some proxies cache frequently accessed content, reducing the load on target servers and improving response times for subsequent requests. Akamai, a leading CDN provider, reported that their caching mechanisms can reduce origin requests by up to 95%, significantly improving user experience.
  • Security and Content Filtering: Proxies can be configured to block malicious websites, filter undesirable content, or enforce security policies, acting as the first line of defense against web-based threats.

Types of Proxies

Proxies come in various flavors, each suited for different use cases.

Understanding these types helps in choosing the right one for your HttpClient implementation.

  • HTTP Proxy: This is the most common type, handling HTTP and HTTPS traffic. They operate at the application layer and are often used for web browsing.
  • SOCKS Proxy SOCKS4, SOCKS5: More versatile than HTTP proxies, SOCKS proxies can handle any type of network traffic, not just HTTP. SOCKS5, the latest version, supports authentication and UDP traffic, making it suitable for a wider range of applications, including gaming and peer-to-peer connections.
  • Transparent Proxy: Users are typically unaware they are using a transparent proxy, as it doesn’t require any client-side configuration. These are often deployed at the network gateway level to enforce policies or perform caching.
  • Anonymous Proxy: These proxies attempt to hide your real IP address, making it difficult for the target server to identify your origin.
  • Distorting Proxy: These proxies provide a false IP address, making it appear as though you’re coming from a different location, but still revealing that you are using a proxy.
  • Elite Proxy: The highest level of anonymity, an elite proxy completely hides your IP address and doesn’t reveal that a proxy is being used.

Configuring HttpClient for Basic HTTP/HTTPS Proxy

Setting up HttpClient to work with a basic HTTP or HTTPS proxy is straightforward, primarily involving the HttpClientHandler class.

This handler allows you to define various network-related settings for your HTTP requests, including proxy information. Best dataset websites

Setting Up a Simple WebProxy

The most common way to configure a proxy for HttpClient is by using the WebProxy class and assigning it to the Proxy property of an HttpClientHandler.

using System.
using System.Net.
using System.Net.Http.
using System.Threading.Tasks.

public class ProxyExample
{
    public static async Task Mainstring args
    {
        // Define the proxy address


       string proxyAddress = "http://your.proxy.server:8080". // Replace with your proxy address and port

        // Create a WebProxy instance


       var webProxy = new WebProxyproxyAddress, bypassOnLocal: false.



       // Create an HttpClientHandler and assign the proxy
        var handler = new HttpClientHandler
        {
            Proxy = webProxy,


           UseProxy = true // Explicitly enable proxy usage
        }.



       // Create an HttpClient instance with the configured handler


       using var client = new HttpClienthandler
            try
            {


               Console.WriteLine$"Making request through proxy: {proxyAddress}".


               var response = await client.GetStringAsync"http://example.com". // Target URL


               Console.WriteLine"Request successful! Response partial:".


               Console.WriteLineresponse.Substring0, Math.Minresponse.Length, 500. // Print first 500 chars
            }
            catch HttpRequestException ex


               Console.WriteLine$"Request failed: {ex.Message}".
                if ex.InnerException != null
                {


                   Console.WriteLine$"Inner exception: {ex.InnerException.Message}".
                }
            catch Exception ex


               Console.WriteLine$"An unexpected error occurred: {ex.Message}".
        }
    }
}
  • WebProxystring address, bool bypassOnLocal: This constructor takes the proxy URI. bypassOnLocal set to false means the proxy will be used even for local intranet addresses.
  • handler.UseProxy = true.: This is crucial. Even if you set the Proxy property, you must explicitly enable UseProxy for HttpClient to respect the proxy settings.
  • HttpClienthandler: Always pass the configured HttpClientHandler to the HttpClient constructor. Once HttpClient is instantiated, its handler cannot be changed.

Handling Proxy Authentication

Many corporate or paid proxies require authentication.

HttpClient supports this seamlessly using NetworkCredential and CredentialCache.

public class AuthenticatedProxyExample
// Define proxy address and credentials

    string proxyAddress = "http://your.auth.proxy.server:8080". // Replace with your authenticated proxy


    string username = "proxy_username". // Replace with your proxy username


    string password = "proxy_password". // Replace with your proxy password

     // Create a NetworkCredential instance


    var credentials = new NetworkCredentialusername, password.



    // Create a WebProxy instance and set credentials


    var webProxy = new WebProxyproxyAddress, bypassOnLocal: false


        Credentials = credentials // Assign credentials to the proxy



    // Create an HttpClientHandler and assign the authenticated proxy
         UseProxy = true // Enable proxy usage

     // Create an HttpClient instance




            Console.WriteLine$"Making request through authenticated proxy: {proxyAddress}".






            Console.WriteLineresponse.Substring0, Math.Minresponse.Length, 500.
  • NetworkCredentialusername, password: This object holds the username and password for proxy authentication.
  • webProxy.Credentials = credentials.: The Credentials property of WebProxy is used to provide authentication details.

System-Wide Proxy Settings

In many Windows environments, proxy settings are configured at the operating system level e.g., through Internet Options. HttpClientHandler can be configured to use these system-wide settings by default. Best price trackers

public class SystemProxyExample

    // Create an HttpClientHandler that uses the system proxy settings


        UseProxy = true, // Ensure proxy usage is enabled


        Proxy = WebRequest.DefaultWebProxy // Use the system's default web proxy





            Console.WriteLine"Making request using system proxy settings...".
  • WebRequest.DefaultWebProxy: This static property retrieves the proxy settings configured for the current user in the operating system. This is especially useful for applications that need to respect existing network configurations.

Advanced Proxy Scenarios with HttpClient

Beyond basic HTTP/HTTPS proxy configurations, HttpClient and its underlying HttpClientHandler offer capabilities for more complex proxy requirements, such as SOCKS proxies and custom proxy logic.

Configuring SOCKS Proxy SOCKS5

While WebProxy primarily supports HTTP/HTTPS proxies, .NET 5+ introduced better support for SOCKS proxies via the SocketsHttpHandler. This handler provides more granular control over the underlying socket connections.

using System.Net.Http.SocketsHttpHandler.

// This is not a real namespace, illustrating the concept Using selenium for web scraping

// NOTE: Direct SOCKS proxy support with HttpClientHandler/WebProxy is limited.

// For robust SOCKS5, you often need to use a custom proxy class or a library.

// However, .NET 5+ introduced SocketsHttpHandler which has better direct support.

// The following example conceptualizes how you might approach it if direct support existed,
// or if you were using a custom SOCKS handler.

public class SOCKSProxyExample
// This is a conceptual example. For actual SOCKS5, Bypass captchas with playwright

    // you might use a library like SocksSharp or implement a custom HttpMessageHandler.



    // A simple WebProxy might work for some SOCKS setups if they expose an HTTP interface,


    // but generally, SOCKS needs different handling.


    string socksProxyAddress = "socks5://your.socks.proxy.server:1080". // Example SOCKS5 address



    // For .NET 5+, you could use SocketsHttpHandler's ConnectCallback for SOCKS:


    // This requires implementing a custom connection logic.


    // For demonstration purposes, I'll show how a custom handler would generally interact.



    // A direct WebProxy to SOCKS5 might not work out-of-the-box for all scenarios.


    // You would typically need a custom HttpMessageHandler for full SOCKS5 support.

    // Example with a *conceptual* custom SOCKS handler not a real class from .NET Framework


    // In a real scenario, you'd integrate a third-party library or implement the SocketsHttpHandler.ConnectCallback.



    // var customSocksHandler = new CustomSocksHandlersocksProxyAddress // Imagine such a class
     // {
     //     ProxyType = ProxyType.SOCKS5,


    //     Credentials = new NetworkCredential"socks_user", "socks_pass" // If authentication is needed
     // }.



    // For .NET 5+, the more common approach for SOCKS would involve:
     // var handler = new SocketsHttpHandler


    //     ConnectCallback = async context, cancellationToken =>
     //     {


    //         // Here you would implement your SOCKS5 connection logic,


    //         // potentially using a SOCKS library or raw socket operations.


    //         // This is significantly more complex than WebProxy.
     //         // return new Socket....


    //         throw new NotImplementedException"SOCKS5 connection logic not implemented here.".
     //     }

    // For simplicity and practical advice, let's assume a WebProxy *might* work


    // if your SOCKS proxy supports a direct HTTP connection, which is often not the case.


    // For true SOCKS5, external libraries or advanced SocketsHttpHandler usage are required.



    Console.WriteLine"Direct SOCKS5 proxy configuration with HttpClient via WebProxy is limited.".


    Console.WriteLine"For robust SOCKS5, consider using a specialized library or advanced SocketsHttpHandler features .NET 5+.".


    Console.WriteLine"Example: SocksSharp NuGet package or implementing ConnectCallback for SocketsHttpHandler.".



    // As a fallback to demonstrate, if your SOCKS proxy somehow exposes an HTTP interface,


    // you could try WebProxy, but it's generally not the correct approach for SOCKS.
     try
         var handler = new HttpClientHandler


            Proxy = new WebProxysocksProxyAddress, // This is unlikely to work for pure SOCKS5
             UseProxy = true
         }.



        using var client = new HttpClienthandler


            Console.WriteLine$"Attempting request with unlikely to work for SOCKS5 proxy: {socksProxyAddress}".


            var response = await client.GetStringAsync"http://example.com".




     catch HttpRequestException ex


        Console.WriteLine$"Request failed as expected for SOCKS5 with WebProxy: {ex.Message}".
     catch Exception ex


        Console.WriteLine$"An unexpected error occurred: {ex.Message}".
  • SocketsHttpHandler introduced in .NET 5: This handler offers a ConnectCallback property, which allows you to define custom logic for establishing the underlying TCP connection. This is the recommended way to implement support for non-HTTP proxies like SOCKS5, as you can manually establish a SOCKS-proxied connection using a dedicated SOCKS client library e.g., SocksSharp from NuGet or by implementing the SOCKS protocol yourself.
  • External Libraries: For robust SOCKS support, especially with authentication, it’s often more practical to use a third-party library like SocksSharp from NuGet. These libraries abstract away the complexities of the SOCKS protocol.

Bypass Proxy for Specific Addresses

You might want to use a proxy for most requests but bypass it for specific internal or local addresses.

WebProxy provides BypassArrayList and BypassProxyOnLocal properties for this purpose.

public class BypassProxyExample

    string proxyAddress = "http://your.proxy.server:8080".
    string bypassList = { "localhost", "127.*", "*.local" }. // Example bypass patterns



    var webProxy = new WebProxyproxyAddress, bypassOnLocal: true // bypassOnLocal is true here


        BypassArrayList = bypassList // Addresses matching these patterns will bypass the proxy

         UseProxy = true





        // Request that should go through the proxy


            Console.WriteLine"Making request to external site through proxy if configured...".


            var externalResponse = await client.GetStringAsync"http://example.com".


            Console.WriteLine"External request successful!".


            Console.WriteLine$"External request failed: {ex.Message}".



        // Request that should bypass the proxy


            Console.WriteLine"\nMaking request to local address should bypass proxy...".


            // Note: For this to truly "bypass", your local machine must be serving something on this address.


            // This is a conceptual example for bypass logic.


            var localResponse = await client.GetStringAsync"http://localhost:8081".


            Console.WriteLine"Local request successful!".


            Console.WriteLine$"Local request failed expected if local server isn't running or proxy was used: {ex.Message}".
  • BypassArrayList: An array of strings that contain regular expression patterns for addresses that should bypass the proxy. For instance, *.local would bypass any address ending in .local.
  • BypassProxyOnLocal: If set to true, all requests to the local computer e.g., localhost, 127.0.0.1 will bypass the proxy. If false, even local requests will go through the proxy.

Custom Proxy Resolvers IWebProxy

For highly dynamic proxy selection or complex proxy logic, you can implement the IWebProxy interface.

This gives you full control over how HttpClient resolves the proxy for each request. Build a rag chatbot

// Custom IWebProxy implementation for dynamic proxy selection
public class DynamicProxy : IWebProxy
private Uri _defaultProxyUri.
private Uri _fallbackProxyUri.

public DynamicProxystring defaultProxy, string fallbackProxy
     _defaultProxyUri = new UridefaultProxy.


    _fallbackProxyUri = new UrifallbackProxy.

 public ICredentials Credentials { get. set. } // Can be set externally

 public Uri GetProxyUri destination


    Console.WriteLine$"Resolving proxy for: {destination.Host}".



    // Example: Use different proxy based on destination host


    if destination.Host.Contains"internal.com"


        Console.WriteLine"Using fallback proxy for internal.com".
         return _fallbackProxyUri. // Or Uri.Unspecified to bypass


    else if destination.Host.Contains"api.example.com"


        Console.WriteLine"Bypassing proxy for api.example.com".
         return null.

// Return null to bypass proxy for this specific destination
else

        Console.WriteLine"Using default proxy.".
         return _defaultProxyUri.

 public bool IsBypassedUri host


    // This method is called by the system to determine if a host should bypass the proxy.


    // If GetProxy returns null, IsBypassed might also be checked.


    // For simple bypass, returning null in GetProxy is usually sufficient.


    Console.WriteLine$"Checking bypass status for: {host.Host}".


    return host.Host.Contains"api.example.com". // Matches example in GetProxy

public class CustomProxyExample
// Replace with your actual proxy servers

    string defaultProxy = "http://main.proxy.server:8080".


    string fallbackProxy = "http://backup.proxy.server:8081".



    var dynamicProxy = new DynamicProxydefaultProxy, fallbackProxy.


    // Optionally set credentials if your dynamic proxy needs them


    // dynamicProxy.Credentials = new NetworkCredential"user", "pass".

         Proxy = dynamicProxy,





        Console.WriteLine"--- Requesting external.com ---".


            await client.GetStringAsync"http://external.com".


            Console.WriteLine"Request to external.com successful.".


        catch Exception ex { Console.WriteLine$"Request failed: {ex.Message}". }



        Console.WriteLine"\n--- Requesting internal.com ---".


            await client.GetStringAsync"http://internal.com".


            Console.WriteLine"Request to internal.com successful.".





        Console.WriteLine"\n--- Requesting api.example.com should bypass ---".


            await client.GetStringAsync"http://api.example.com".


            Console.WriteLine"Request to api.example.com successful bypassed proxy.".
  • IWebProxy Interface: Requires implementing GetProxyUri destination and IsBypassedUri host.
  • GetProxyUri destination: This method is called for each outgoing request. You return the Uri of the proxy to use, or null to bypass the proxy for that specific destination.
  • IsBypassedUri host: This method is often called by the system to confirm if a specific host should indeed bypass the proxy. You can return true if it should be bypassed.
  • Use Cases: Implementing IWebProxy is ideal for scenarios like:
    • Failover Proxies: If one proxy fails, you can dynamically switch to another.
    • Load Balancing Proxies: Distribute requests across multiple proxies.
    • Context-Based Proxying: Use different proxies based on the request’s headers, content, or the user making the request.

Best Practices and Considerations for Proxy Usage

When working with proxies and HttpClient, adhering to best practices can prevent common pitfalls, improve performance, and ensure the stability of your applications.

This section covers crucial aspects from security to resource management. Python ip rotation

HttpClient Instance Management

HttpClient is designed to be instantiated once and reused throughout the lifetime of an application.

Creating a new HttpClient for every request can lead to socket exhaustion issues, especially when dealing with proxies that maintain persistent connections.

  • Singleton Pattern: A common approach is to register HttpClient as a singleton in your Dependency Injection DI container.

    // In your Startup.cs or program entry point


services.AddHttpClient. // Registers IHttpClientFactory


// Then, inject IHttpClientFactory and create named clients or


// use services.AddHttpClient<YourService>. to register a typed client.

  • IHttpClientFactory: For more complex scenarios, especially in ASP.NET Core applications, IHttpClientFactory is the recommended way to manage HttpClient instances. It handles the lifetime of the underlying HttpClientHandler and connection pooling, mitigating socket exhaustion.

    Services.AddHttpClient”ProxiedClient”, client => Best social media data providers

    // Configure common settings for this named client

    }
    .ConfigurePrimaryHttpMessageHandler =>

    // Configure the proxy for this specific client
 return new HttpClientHandler


    Proxy = new WebProxy"http://your.proxy.server:8080",

    }.

    // In your consuming class e.g., a service
    public class MyService
    private readonly HttpClient _client.

    public MyServiceIHttpClientFactory httpClientFactory

    _client = httpClientFactory.CreateClient”ProxiedClient”. Web data points for retail success

    public async Task GetDataAsync

    return await _client.GetStringAsync”http://example.com“.
    According to Microsoft documentation, using IHttpClientFactory can improve the performance and reliability of HttpClient usage in long-running applications by managing connection pooling and handling DNS changes.

Proxy Security Implications

While proxies offer benefits, they also introduce security considerations that must not be overlooked.

  • Trusting the Proxy: You must implicitly trust the proxy server you are using. If the proxy is compromised or malicious, it can intercept, modify, or log your traffic, including sensitive data.
  • Man-in-the-Middle MitM Attacks: If your proxy performs SSL/TLS interception common in corporate environments for security scanning, it acts as a MitM. While legitimate in controlled environments, it means the proxy sees your unencrypted data. Ensure your application correctly validates the proxy’s certificate chain to prevent malicious interception.
  • Credential Handling: When providing credentials for an authenticated proxy, ensure they are stored and transmitted securely. Avoid hardcoding credentials in your application. Use environment variables, secure configuration files, or secrets management systems.
  • Logging: Be aware that proxy servers often log all requests passing through them, including URLs, IP addresses, and sometimes even headers. Understand the logging policies of your proxy provider.

Error Handling and Timeouts

Networking is inherently unreliable.

Proper error handling and timeout configurations are crucial when working with proxies. Fighting ad fraud

  • HttpRequestException: This exception is commonly thrown for network-related errors, DNS resolution failures, or HTTP status codes indicating an error e.g., 4xx, 5xx.

  • TaskCanceledException: If a request times out, this exception is typically thrown.

  • HttpClient.Timeout: Set an appropriate timeout for your requests. This prevents your application from hanging indefinitely if the proxy or the target server is unresponsive. A common timeout for external API calls might be between 30-60 seconds, but it depends heavily on the expected response time.

    Using var client = new HttpClienthandler { Timeout = TimeSpan.FromSeconds30 }
    // …

  • Retry Logic: Implement retry mechanisms with exponential backoff for transient network errors. Polly is an excellent .NET resilience library that can help with this.
    // Example using Polly for retry logic
    var retryPolicy = Policy
    .Handle Llm training data

    .WaitAndRetryAsync3, attempt => TimeSpan.FromSecondsMath.Pow2, attempt.
    await retryPolicy.ExecuteAsyncasync =>
    // Your HttpClient request here

    var response = await client.GetStringAsync”http://example.com“.

    Console.WriteLine”Request successful after retries.”.

  • Circuit Breaker Pattern: For more critical services, consider implementing a circuit breaker to prevent hammering an unresponsive proxy or target service, protecting your application from cascading failures.

Performance Considerations

Proxies can introduce overhead, but careful configuration can mitigate performance impacts. Node js user agent

  • Connection Pooling: HttpClientHandler automatically handles connection pooling. Ensure you reuse HttpClient instances or use IHttpClientFactory to benefit from this, reducing the overhead of establishing new TCP connections for each request.
  • Keep-Alive: By default, HttpClient uses HTTP Keep-Alive, which helps reuse existing connections. Proxies should also support this for optimal performance.
  • Proxy Location: For minimal latency, choose a proxy server geographically close to your application or the target server, depending on which hop is more latency-sensitive. A study by CDN provider Cloudflare showed that geographic proximity to edge servers can reduce latency by up to 80ms for users.
  • Proxy Server Performance: The performance of your proxy server itself is a major factor. A slow or overloaded proxy will degrade your application’s performance. Monitor proxy health and choose reliable providers.

Diagnosing Proxy Connectivity Issues

When HttpClient fails to connect through a proxy, pinpointing the exact cause can be challenging. A systematic approach to diagnosis is key.

This section provides steps and tools to troubleshoot common proxy connectivity problems.

Common Error Messages and Their Meanings

Understanding the error messages is the first step in diagnosis.

  • HttpRequestException: No such host is known / Name or service not known:

    • Meaning: The DNS name of the proxy server e.g., your.proxy.server could not be resolved to an IP address.
    • Possible Causes:
      • Incorrect proxy address.
      • DNS resolution issues on the client machine.
      • Typo in the proxy hostname.
    • Troubleshooting:
      • Verify the proxy address is correct.
      • Try ping or nslookup on the proxy hostname from your client machine to check DNS resolution.
      • Ensure no local firewall is blocking DNS queries.

  • HttpRequestException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. or similar “connection refused” / “timeout”: Avoid getting blocked with puppeteer stealth

    • Meaning: The client could not establish a TCP connection to the proxy server on the specified port, or the connection timed out.
      • Proxy server is down or unreachable.
      • Incorrect proxy port.
      • Firewall on the client, proxy, or intermediate network blocking the connection.
      • Proxy server is overloaded and not accepting new connections.
      • Verify the proxy IP address and port are correct.
      • Use telnet your.proxy.server proxy_port from your client to test if the port is open and accessible. If telnet fails, it’s likely a network or firewall issue.
      • Check the proxy server’s status if you have access.
      • Temporarily disable client-side firewalls to rule them out.

  • HttpRequestException: The remote server returned an error: 407 Proxy Authentication Required.:

    • Meaning: The proxy server requires authentication, and your HttpClient did not provide valid credentials.
      • No credentials provided.
      • Incorrect username or password.
      • Incorrect authentication scheme e.g., NTLM vs. Basic.
      • Ensure you are setting Credentials on your WebProxy instance using NetworkCredential.
      • Double-check the username and password.
      • Confirm the proxy’s authentication scheme. Some proxies might require CredentialCache.DefaultNetworkCredentials if they integrate with Windows domain authentication.

  • HttpRequestException: The remote server returned an error: 502 Bad Gateway or 504 Gateway Timeout:

    • Meaning: The proxy server itself couldn’t reach the target server.
      • Target server is down or unreachable from the proxy.
      • Proxy server’s own network issues.
      • Proxy server misconfiguration.
      • Target server’s firewall blocking the proxy’s IP.
      • Try accessing the target URL directly without the proxy from a machine with similar network access as the proxy.
      • Check the proxy server’s logs for more details if you have access.
      • If the issue persists, contact the proxy administrator.

  • HttpRequestException: The SSL connection could not be established, see inner exception. or similar TLS/SSL error:

    • Meaning: Issues with the SSL/TLS handshake between your client and the proxy, or between the proxy and the target server.
      • Invalid or untrusted SSL certificate on the proxy.
      • Proxy performing SSL interception with an untrusted root certificate.
      • TLS version mismatch.
      • If it’s a corporate proxy, you might need to install their root CA certificate on your client machine’s trust store.
      • Temporarily for debugging only, never in production set handler.ServerCertificateCustomValidationCallback to HttpClientHandler.DangerousAcceptAnyServerCertificateValidator to rule out certificate validation issues. This is highly insecure and for debugging only.
      • Ensure your .NET environment supports the TLS version used by the proxy/target server e.g., TLS 1.2 or 1.3.

Using Network Monitoring Tools

Tools like Wireshark and Fiddler are invaluable for understanding network traffic and diagnosing proxy issues.

  • Wireshark: Apis for dummies

    • What it does: A powerful network protocol analyzer that captures and displays network traffic at a low level.

    • How to use for proxy:

      1. Start capturing on your network interface.

      2. Run your application’s HttpClient request.

      3. Filter for traffic to and from your proxy’s IP address and port e.g., ip.addr == your.proxy.ip and tcp.port == your_proxy_port. Best languages web scraping

      4. Look for TCP handshake failures SYN, SYN-ACK, RST packets, retransmissions, or unexpected closes.

      5. For HTTP/HTTPS traffic, follow the TCP stream to see the raw request/response.

    • Benefits: Shows exactly what’s happening at the TCP/IP level, helping identify if the connection is even reaching the proxy.

  • Fiddler or Telerik Fiddler Classic/Everywhere:

    • What it does: A web debugging proxy that sits between your application and the internet, capturing HTTP/HTTPS traffic.

      1. Configure your application to use Fiddler as its proxy typically http://127.0.0.1:8888.

      2. Fiddler will then attempt to forward the request to your actual proxy.

      3. This allows you to see if your HttpClient is correctly sending requests to Fiddler.

If Fiddler then shows an error trying to connect to your actual proxy, you’ve narrowed down the problem.

    4.  Fiddler can also decrypt HTTPS traffic if its root certificate is trusted on your machine, allowing you to inspect encrypted requests.
*   Benefits: Excellent for inspecting HTTP/HTTPS requests and responses, seeing headers, body content, and HTTP status codes, and understanding the flow of traffic.

Verifying Proxy Configuration

A simple mistake in configuration can cause hours of debugging. Double-check everything.

  • Proxy Address and Port: Ensure the URL and port are exact.
  • Authentication: Verify username, password, and domain if applicable for NTLM.
  • Bypass List: Make sure the target URL isn’t accidentally included in a bypass list if it’s supposed to go through the proxy.
  • System Proxy: If UseDefaultCredentials or WebRequest.DefaultWebProxy is used, ensure the system’s proxy settings are correctly configured for the user running the application. For services running as a different user, this can be tricky.
  • Environment Variables: In some non-Windows environments or for command-line tools, proxy settings might be picked up from environment variables like HTTP_PROXY, HTTPS_PROXY, or NO_PROXY. While HttpClient primarily uses HttpClientHandler settings, it’s good to be aware of other potential influences.

By systematically applying these diagnostic steps and utilizing the right tools, you can effectively troubleshoot most proxy connectivity issues with HttpClient.

Common Pitfalls and How to Avoid Them

Even with a good understanding of HttpClient and proxies, certain traps can lead to frustrating debugging sessions.

Being aware of these common pitfalls can save you significant time and effort.

Socket Exhaustion

This is perhaps the most frequently encountered issue when not managing HttpClient instances correctly.

  • Pitfall: Creating a new HttpClient instance for every single request. Each HttpClient instance can potentially open new TCP connections and keep them alive. If you create too many instances rapidly without disposing of them properly, you can exhaust the available socket connections on your operating system, leading to “No connection could be made because the target machine actively refused it” or “Only one usage of each socket address protocol/network address/port is normally permitted” errors.
  • Why it happens: The underlying HttpClientHandler and its connection pool are disposed when the HttpClient instance is disposed. If you create and dispose HttpClient instances frequently, the connections don’t get pooled and reused, leading to resource depletion.
  • Solution:
    • Reuse a single HttpClient instance across multiple requests throughout the application’s lifetime.
    • Utilize IHttpClientFactory in ASP.NET Core applications. This factory manages the pooling and lifetime of HttpClientHandler instances, effectively preventing socket exhaustion while still allowing you to create “logical” HttpClient instances with different configurations. A 2023 survey revealed that applications migrating to .NET Core/5+ often faced these issues if not adopting IHttpClientFactory.

DNS Caching Issues

DNS resolution can sometimes be problematic, especially in long-running applications or when proxy servers change their IP addresses.

  • Pitfall: HttpClient or rather, the underlying ServicePointManager before .NET 5 or SocketsHttpHandler in .NET 5+ by default caches DNS resolutions for a certain period. If a proxy’s IP address changes, your application might continue trying to connect to the old, stale IP, resulting in connection errors.
  • Why it happens: This caching is for performance, to avoid repeated DNS lookups. However, in dynamic environments, it can cause issues.
    • For HttpClientHandler which uses ServicePointManager under the hood for .NET Framework and older .NET Core versions, you can set ServicePointManager.DnsRefreshTimeout to a lower value e.g., TimeSpan.FromMinutes1 or even 0 to disable caching though this has performance implications.
    • With SocketsHttpHandler the default for .NET 5+, DNS caching is handled by the OS and is more robust. If you’re using older .NET versions, this is more relevant.
    • Ensure your proxy server’s DNS record if you’re using a hostname is stable.

Incorrect Proxy Format or Protocol

Proxies come in different types, and HttpClientHandler‘s Proxy property expects a specific format.

  • Pitfall: Providing an incorrect URL scheme e.g., socks:// when WebProxy expects http:// or https:// or including credentials directly in the URL.
  • Why it happens: WebProxy is designed primarily for HTTP/HTTPS proxies. Trying to force a SOCKS proxy URL directly into WebProxy will often fail or result in unexpected behavior. Embedding credentials in the URI e.g., http://user:[email protected]:8080 is not the standard or secure way to pass credentials to WebProxy.
    • Always use http:// or https:// schemes for WebProxy addresses.
    • For authentication, use the Credentials property of WebProxy with NetworkCredential.
    • For SOCKS proxies, especially SOCKS5, consider using specialized libraries like SocksSharp or implementing custom connection logic with SocketsHttpHandler.ConnectCallback for .NET 5+.

Firewall Blocks

Firewalls, both client-side and server-side, are notorious for silently blocking connections.

  • Pitfall: The application cannot connect to the proxy, or the proxy cannot connect to the target, due to firewall rules. The error message might be a generic “connection refused” or “timeout.”
  • Why it happens: Firewalls are designed to restrict network traffic based on rules ports, IP addresses, protocols. A missing rule can block legitimate connections.
    • Client-side: Temporarily disable your local firewall to test. If it works, add an outbound rule to allow your application to connect to the proxy’s IP and port.
    • Proxy-side: If you manage the proxy, ensure its firewall allows inbound connections on its listening port from your application’s IP address.
    • Target-side: Ensure the target server’s firewall allows inbound connections from the proxy’s IP address.
    • Use telnet to check port connectivity e.g., telnet your.proxy.server 8080. If telnet fails, it’s a network/firewall issue before your code even executes.

Forgetting UseProxy = true

A simple oversight, but surprisingly common.

  • Pitfall: Setting the Proxy property on HttpClientHandler but forgetting to set UseProxy = true.
  • Why it happens: The UseProxy property acts as a toggle. If it’s false which is its default if no system proxy is detected, the HttpClient will ignore the Proxy property you set.
  • Solution: Always explicitly set handler.UseProxy = true. when you are manually configuring a proxy.

By keeping these pitfalls in mind and adopting the recommended solutions, you can build more robust and reliable applications that effectively utilize proxies with HttpClient.

Performance Benchmarking with and Without Proxy

Understanding the performance impact of using a proxy is crucial for optimizing your application.

Benchmarking can reveal the overhead introduced by the proxy and help you identify bottlenecks.

While specific numbers will vary wildly based on network conditions, proxy server performance, and geographical distance, the methodology remains consistent.

Designing Your Benchmark

To get meaningful data, your benchmark should simulate realistic usage and measure key metrics.

  • Test Environment:
    • Client Machine: The machine running your HttpClient code.
    • Proxy Server: The actual proxy you intend to use. Ensure it’s stable and not overloaded by other traffic during the test.
    • Target Server: The API or website your HttpClient will hit. Ideally, this should be consistent and responsive.
  • Metrics to Measure:
    • Request Latency Response Time: The time taken from sending the request to receiving the full response. This is often the most critical metric.
    • Throughput: The number of requests processed per unit of time e.g., requests per second.
    • Error Rate: The percentage of failed requests.
    • CPU/Memory Usage: On both the client and proxy server, to understand resource consumption.
  • Test Scenarios:
    • Direct Connection: HttpClient without any proxy configured. This serves as your baseline.
    • Proxied Connection: HttpClient configured to use your specific proxy.
    • Varying Load: Test with single requests, then simulate concurrent requests e.g., 10, 50, 100 concurrent requests to observe how performance degrades under stress.
    • Different Payload Sizes: Test with small responses e.g., a few KB and larger responses e.g., MBs to see the impact on data transfer.

Example Benchmark Code Structure

You can use libraries like BenchmarkDotNet for more rigorous and statistically sound benchmarking, but a simple manual loop can provide initial insights.

using System.Diagnostics.

public class ProxyBenchmark
private const int NumberOfRequests = 100.

private const string TargetUrl = "http://httpbin.org/get". // A reliable test endpoint



    Console.WriteLine"Starting proxy performance benchmark...\n".



    // --- Benchmark without Proxy Baseline ---


    Console.WriteLine"--- Running benchmark WITHOUT proxy ---".
     await RunBenchmarkuseProxy: false.



    Console.WriteLine"\n-------------------------------------\n".

     // --- Benchmark with Proxy ---


    Console.WriteLine"--- Running benchmark WITH proxy ---".
     // Replace with your actual proxy details




    await RunBenchmarkuseProxy: true, proxyAddress: proxyAddress.



    Console.WriteLine"\nBenchmark completed.".



private static async Task RunBenchmarkbool useProxy, string proxyAddress = null
     var handler = new HttpClientHandler.

     if useProxy && proxyAddress != null


        handler.Proxy = new WebProxyproxyAddress.
         handler.UseProxy = true.


        Console.WriteLine$"Using proxy: {proxyAddress}".
         Console.WriteLine"Not using proxy.".



    // Reuse HttpClient instance for the benchmark


    using var client = new HttpClienthandler { Timeout = TimeSpan.FromSeconds30 }
         var stopwatch = new Stopwatch.
         long totalLatencyMs = 0.
         int successfulRequests = 0.



        Console.WriteLine$"Making {NumberOfRequests} requests...".

         for int i = 0. i < NumberOfRequests. i++
             stopwatch.Restart.
             try


                var response = await client.GetStringAsyncTargetUrl.
                 stopwatch.Stop.


                totalLatencyMs += stopwatch.ElapsedMilliseconds.
                 successfulRequests++.


                // Console.WriteLine$"Request {i+1}: {stopwatch.ElapsedMilliseconds} ms". // Uncomment for verbose logging
             catch Exception ex


                Console.WriteLine$"Request {i+1} failed: {ex.Message}".


            // Optional: add a small delay to avoid overwhelming server in manual tests
             // await Task.Delay50.



        double averageLatency = doubletotalLatencyMs / successfulRequests.


        double requestsPerSecond = doublesuccessfulRequests / totalLatencyMs / 1000.0.



        Console.WriteLine$"\nResults for {useProxy switch { true => "Proxied", false => "Direct" }} Connection:".


        Console.WriteLine$"Total requests: {NumberOfRequests}".


        Console.WriteLine$"Successful requests: {successfulRequests}".


        Console.WriteLine$"Average latency: {averageLatency:F2} ms".


        Console.WriteLine$"Throughput: {requestsPerSecond:F2} requests/sec".


        Console.WriteLine$"Total time for successful requests: {totalLatencyMs} ms".

Interpreting Benchmark Results

  • Increased Latency: You will almost certainly see an increase in average latency when using a proxy. This is due to the extra hop and processing at the proxy server. For example, a direct request might take 50ms, while a proxied request might take 150ms. A 2x-5x increase in latency is not uncommon for basic HTTP proxies.
  • Reduced Throughput: Higher latency typically translates to lower throughput fewer requests per second unless you significantly increase concurrency.
  • Bottlenecks:
    • Proxy Server Overload: If throughput drops sharply or error rates spike under load, the proxy server might be the bottleneck. It could be CPU-bound, I/O-bound, or network-bound.
    • Network Bandwidth: The link between your client and the proxy, or the proxy and the target, might be saturated.
    • Client-Side Resources: Ensure your client machine isn’t CPU/memory limited, especially if running many concurrent HttpClient instances without IHttpClientFactory.
  • What to Look For:
    • Consistency: Is the latency consistent, or are there significant spikes? Inconsistent latency can indicate an unstable proxy or network.
    • Scalability: How does throughput change as you increase the number of concurrent requests? A proxy that scales well will maintain a relatively stable throughput per connection even as load increases.
    • Authentication Overhead: If using an authenticated proxy, compare its performance to an unauthenticated one if possible. Authentication adds a small, but measurable, overhead.

Optimization Strategies

If benchmarks reveal performance issues, consider these optimizations:

  • Optimize Proxy Location: Choose a proxy physically closer to your application or the target server. A proxy located across continents will add significant latency.
  • High-Performance Proxies: Invest in a higher-spec proxy server or a commercial proxy service known for its low latency and high throughput.
  • Connection Pooling: Ensure HttpClient instances are reused or managed by IHttpClientFactory to leverage persistent connections and reduce TCP handshake overhead.
  • Bypass Proxy for Internal Traffic: If some requests are to internal services, configure WebProxy.BypassArrayList to avoid unnecessary proxy hops.
  • Compression: Ensure both your HttpClient and the proxy server support GZIP/Deflate compression for data transfer, reducing payload size.
  • Timeouts and Retries: While not directly performance-enhancing, proper timeouts and retries prevent requests from hanging indefinitely, which can impact the overall perceived performance and resource utilization.

Benchmarking is an iterative process.

Run tests, analyze results, make changes, and re-test.

This data-driven approach will help you fine-tune your HttpClient and proxy configuration for optimal performance.

Maintaining and Monitoring Proxy Usage in Production

Deploying HttpClient with proxy configurations in a production environment requires ongoing maintenance and robust monitoring to ensure reliable operation and swift issue resolution. This isn’t a “set it and forget it” task.

Network conditions, proxy server health, and security threats evolve.

Centralized Configuration Management

Hardcoding proxy settings is a recipe for disaster in production.

You need a flexible way to manage these configurations.

  • Environment Variables: A common and effective method. You can set HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables. While HttpClientHandler itself doesn’t directly read these, you can write code to read them and configure your WebProxy.

    // Example of reading from environment variables

    String proxyUri = Environment.GetEnvironmentVariable”HTTP_PROXY”.
    if !string.IsNullOrEmptyproxyUri
    handler.Proxy = new WebProxyproxyUri.
    handler.UseProxy = true.

  • Configuration Files appsettings.json, app.config: Best practice for application-specific settings. Use .NET’s configuration system to load proxy details.

    // appsettings.json
  "ProxySettings": {
    "Address": "http://your.prod.proxy:8080",
    "Username": "prod_user",
    "Password": "prod_password",
   "BypassList": 
  }
Then, in your code:
public class ProxySettings
    public string Address { get. set. }
    public string Username { get. set. }
    public string Password { get. set. }
    public string BypassList { get. set. }



// In Startup.cs or where you configure services


services.Configure<ProxySettings>Configuration.GetSection"ProxySettings".


// Then inject IOptions<ProxySettings> into your service.

  • Secrets Management: For sensitive information like proxy credentials, avoid storing them in plaintext configuration files. Use:

    • Azure Key Vault / AWS Secrets Manager: Cloud-native solutions for storing secrets securely.
    • Environment Variables: If robust secret management systems are not available.
    • .NET User Secrets: For development environments, but not production.
    • HashiCorp Vault: An enterprise-grade solution for secrets management.

Logging and Monitoring

Effective logging and monitoring are critical for identifying and diagnosing proxy-related issues in real-time.

  • Application Logs:
    • Proxy Configuration: Log the proxy address and port used by HttpClient at startup.
    • Request/Response Details: Log HTTP status codes, request URLs, and response times. Avoid logging sensitive data.
    • Errors: Log HttpRequestException details, including inner exceptions, whenever a request fails. This helps distinguish between network issues, proxy issues, and target server issues. Use structured logging e.g., Serilog, NLog with JSON output for easier analysis.
  • Metrics Collection:
    • Request Latency: Track average, median, and 95th/99th percentile latency for proxied requests vs. direct requests.
    • Throughput: Monitor requests per second.
    • Error Rate: Track the percentage of failed requests.
    • Proxy-Specific Errors: Categorize HTTP status codes e.g., 407 Proxy Authentication Required, 502 Bad Gateway to quickly identify proxy-specific problems.
    • Connection Pool Size: If you’re managing HttpClient manually, monitor the number of open connections.
  • Alerting: Set up alerts for critical metrics:
    • Spikes in proxy-related error rates e.g., 407, 502.
    • Sudden increase in latency for proxied requests.
    • Significant drop in throughput.
    • Proxy server CPU/memory/network utilization if you manage the proxy.
  • Monitoring Tools:
    • Application Performance Monitoring APM tools: New Relic, Dynatrace, Application Insights Azure, Datadog. These tools can trace requests, identify bottlenecks, and visualize performance metrics. A 2023 report by Gartner highlighted the growing adoption of APM tools, with market revenue expected to reach over $7 billion by 2026.
    • Infrastructure Monitoring: Prometheus/Grafana, Nagios, Zabbix for monitoring the proxy server itself CPU, memory, network I/O, open connections.
    • Log Aggregation: ELK Stack Elasticsearch, Logstash, Kibana, Splunk, Sumo Logic for centralizing and analyzing logs.

Regular Health Checks

Implement health checks for your proxy and target services.

  • Proxy Health Check: Periodically try to connect to your proxy server’s address and port e.g., using a simple telnet check or a lightweight HTTP HEAD request through the proxy to a known reliable endpoint like http://example.com.
  • End-to-End Health Check: Make a full request through the proxy to a known, stable target endpoint and assert the response. This verifies the entire chain.
  • Dedicated Monitoring Service: Use an external monitoring service e.g., UptimeRobot, Pingdom to continuously monitor the availability and performance of your proxy and the target services from different geographical locations.

Rotation and Failover Strategies

For high availability and resilience, especially with external proxies.

  • Proxy Rotation: If you rely on a pool of proxies e.g., for web scraping, implement a rotation mechanism to distribute load and avoid IP bans. This involves having a list of proxies and switching between them on a predefined schedule or upon encountering specific errors.
  • Automated Failover: If a proxy becomes unresponsive or returns specific error codes e.g., 502, 407, implement logic to automatically switch to a fallback proxy. This can be achieved by implementing a custom IWebProxy or by dynamically reconfiguring HttpClient instances.
  • DNS Load Balancing: If you have multiple proxy servers, you can use DNS load balancing to distribute requests to different proxy instances using a single hostname.

By implementing these maintenance and monitoring strategies, you can ensure that your HttpClient‘s proxy usage is robust, transparent, and performs optimally in a production environment.

Conclusion

Frequently Asked Questions

What is the primary purpose of using a proxy with HttpClient?

The primary purpose is to route HTTP requests through an intermediary server.

This can be for reasons like accessing geo-restricted content, bypassing firewalls, enhancing anonymity, caching, or enforcing security policies and content filtering within a network.

How do I configure a basic HTTP proxy for HttpClient?

You configure a basic HTTP proxy by creating an instance of HttpClientHandler, setting its Proxy property to a WebProxy instance initialized with your proxy’s URI, and crucially, setting UseProxy = true. Then, you instantiate HttpClient with this configured handler.

Can HttpClient handle authenticated proxies?

Yes, HttpClient can handle authenticated proxies.

You achieve this by setting the Credentials property of your WebProxy instance to a NetworkCredential object containing the proxy’s username and password.

Should I create a new HttpClient instance for every request when using a proxy?

No, you should not create a new HttpClient instance for every request. HttpClient is designed for reuse.

Creating many instances can lead to socket exhaustion.

Instead, reuse a single HttpClient instance or use IHttpClientFactory in ASP.NET Core applications.

What is IHttpClientFactory and why is it recommended for proxy usage?

IHttpClientFactory is a factory for creating HttpClient instances, primarily used in ASP.NET Core.

It’s recommended because it manages the lifetime of underlying HttpClientHandler instances and their connection pools, preventing socket exhaustion and ensuring proper disposal, while still allowing for different HttpClient configurations including proxies via named or typed clients.

How can I bypass the proxy for specific local addresses?

You can bypass the proxy for specific local addresses by setting BypassProxyOnLocal = true on your WebProxy instance.

For more granular control, use the BypassArrayList property to provide a list of regular expression patterns for addresses that should bypass the proxy.

Is it possible to use a SOCKS proxy with HttpClient?

Direct out-of-the-box support for SOCKS proxies with WebProxy is limited.

For robust SOCKS5 support, especially with authentication, you often need to use a specialized library like SocksSharp from NuGet or implement custom connection logic using the SocketsHttpHandler.ConnectCallback available in .NET 5 and later.

What are common error messages encountered when using proxies?

Common error messages include “No such host is known” DNS resolution failure, “connection refused” or “timeout” proxy unreachable, “407 Proxy Authentication Required” incorrect credentials, “502 Bad Gateway” or “504 Gateway Timeout” proxy couldn’t reach target, and various SSL/TLS errors.

How can I diagnose proxy connectivity issues?

Diagnose issues by checking common error messages, verifying your proxy configuration address, port, credentials, and using network monitoring tools like Wireshark for low-level TCP issues and Fiddler for HTTP/HTTPS traffic inspection.

What is the performance impact of using a proxy?

Using a proxy typically introduces overhead, leading to increased request latency and potentially reduced throughput compared to direct connections.

The exact impact depends on network conditions, proxy server performance, and geographic distance.

How can I improve the performance of proxied requests?

To improve performance, ensure HttpClient instances are reused or use IHttpClientFactory, choose a high-performance proxy server, select a proxy geographically close to your application or target, leverage connection pooling, and use data compression.

How do I handle proxy credentials securely in production?

Avoid hardcoding proxy credentials.

Instead, use secure methods like environment variables, dedicated secrets management solutions e.g., Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, or secure configuration files.

What should I log and monitor when using proxies in production?

Log proxy configuration at startup, request/response details status codes, URLs, times, and detailed error information.

Monitor metrics like request latency, throughput, and proxy-specific error rates e.g., 407, 502. Use APM tools and log aggregators for centralized visibility.

Can a proxy introduce security risks?

Yes, using a proxy can introduce security risks.

You must trust the proxy, as it can intercept, modify, or log your traffic.

Be aware of potential Man-in-the-Middle attacks if the proxy performs SSL/TLS interception, and ensure secure handling of credentials.

What is a transparent proxy?

A transparent proxy is an intermediary that intercepts network traffic without requiring any client-side configuration. Users are often unaware they are using one.

They are commonly used at the network gateway level for content filtering or caching.

What is an IWebProxy and when would I use it?

IWebProxy is an interface that allows you to implement custom logic for how HttpClient resolves the proxy for each request.

You would use it for advanced scenarios like dynamic proxy selection based on the destination URL, implementing proxy failover, or load balancing requests across multiple proxy servers.

How do I set a timeout for an HttpClient request when using a proxy?

You set the timeout directly on the HttpClient instance using its Timeout property e.g., client.Timeout = TimeSpan.FromSeconds30. This timeout applies to the entire request, including connection establishment through the proxy.

What is socket exhaustion and how is it related to HttpClient?

Socket exhaustion occurs when an application opens too many TCP connections too quickly without properly closing or reusing them, depleting the available system resources sockets. This is a common pitfall if HttpClient instances are created and disposed of excessively instead of being reused.

Can HttpClient use system-wide proxy settings?

Yes, HttpClientHandler can be configured to use the system’s default proxy settings e.g., those configured in Internet Options on Windows by setting handler.UseProxy = true and handler.Proxy = WebRequest.DefaultWebProxy.

What is the difference between an HTTP proxy and a SOCKS proxy?

An HTTP proxy is designed specifically for HTTP and HTTPS traffic and operates at the application layer.

A SOCKS proxy e.g., SOCKS5 is more versatile, operating at a lower level session layer, and can handle any type of network traffic, including HTTP, FTP, and peer-to-peer connections.

0.0
0.0 out of 5 stars (based on 0 reviews)
Excellent0%
Very good0%
Average0%
Poor0%
Terrible0%

There are no reviews yet. Be the first one to write one.

​
Amazon.com: Check Amazon for Proxy with httpclient
Latest Discussions & Reviews:

•

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Social Media