Jak používat proxy s HttpClient v C#: postupy a opravy

Minulý týden jsem zbytečně promrhal fakt hodně času zíráním na odpověď 407 Proxy Authentication Required, protože jsem byl přesvědčený, že je rozbitý můj poskytovatel proxy. Nakonec jsem zjistil, že jsem přihlašovací údaje nastavil na špatnou vlastnost — oprava na dva řádky, kterou mi trvalo dvě hodiny vypátrat. Jestli vám to zní povědomě, tenhle průvodce je přesně pro vás.

Nastavení proxy pro HttpClient v C# je jeden z těch témat, kde je základní postup snadný, ale produkční zádrhely — vyčerpání socketů, nesoulad verze SOCKS5, záměna přihlašovacích údajů — vám dokážou sebrat spoustu času.

U nástrojů pro web scraping a extrakci dat v Thunderbit se s tímhle potkávám už dlouho a ty samé chyby vídám pořád dokola, ať už v našich technických diskusích, nebo v komunitách vývojářů, které sledujeme. Tenhle návod pokrývá celý postup: nastavení, autentizaci, rotaci proxy, volbu protokolu i tabulku řešení problémů, kterou bych si sám v ten den, kdy jsem začínal, hrozně přál mít po ruce.

Obtížnost: Začátečník až mírně pokročilý
Časová náročnost: zhruba 15 minut na přečtení, u produkční rotace déle
Co budete potřebovat: .NET 6+ SDK (kvůli SOCKS5 a moderním handler funkcím; pro základní příklady HTTP proxy funguje i .NET Framework 4.x), editor kódu a aspoň jeden proxy endpoint k otestování

Co je HttpClient a proč vůbec potřebuje proxy?

HttpClient je vestavěná třída v .NET v oboru názvů System.Net.Http, která slouží k odesílání HTTP požadavků a přijímání odpovědí. Podporuje async/await, vlastní hlavičky, zrušovací tokeny i konfiguraci přes handlery. Microsoft ji popisuje jako třídu pro odesílání HTTP požadavků a přijímání HTTP odpovědí ze zdroje identifikovaného URI.

Proxy server funguje jako prostředník mezi vaší aplikací a cílovým webem. Když provoz směrujete přes proxy, cílový web vidí IP adresu proxy, ne vaši vlastní.

Samotný HttpClient nemá vlastnost Proxy. Směrování přes proxy se nastavuje na podkladovém handleru — buď HttpClientHandler, nebo SocketsHttpHandler — který přijímá instanci WebProxy. Mentální model vypadá takto:

[Vaše C# aplikace] → [HttpClient + handler] → [Proxy server] → [Cílový web]

Proto je „změnit proxy na běžícím HttpClientu“ spíš návrhový problém než obyčejné přiřazení vlastnosti. K tomu se ještě vrátím v části o rotaci.

Vyzkoušejte Thunderbit pro jednodušší extrakci dat

Proč používat proxy s HttpClient v C#

Vývojáři směrují provoz z HttpClient přes proxy z několika opakujících se důvodů a správný typ proxy závisí na konkrétním úkolu.

• Vyhnout se blokacím IP a rate limitům: Nezbytné pro web scraping, generování leadů nebo monitoring cen ve větším měřítku. Jedna IP, která web neustále zatěžuje, bude rychle zablokována.
• Obejít geografická omezení: Přístup k API nebo obsahu uzamčenému pro určité regiony díky proxy v konkrétních zemích.
• Skrýt původní IP: Další vrstva soukromí při citlivém sběru dat nebo konkurenční analýze.
• Firemní nebo compliance požadavky: Mnoho firem vyžaduje, aby odchozí provoz procházel přes centrální bránu kvůli logování a správě.
• Testování a QA: Simulace požadavků z různých lokalit nebo síťových podmínek bez fyzického nasazení infrastruktury v těchto regionech.

Případ použití	Typická volba proxy	Proč se hodí
Web scraping ve velkém	Rotující rezidenční proxy	Více IP adres, anti-bot systémy je hůř vyhodnocují
Monitoring cen e-shopů	Rezidenční nebo geograficky cílená datacentrová proxy	Kontrola regionálních cen a dostupnosti
Přístup k API přes pevnou bránu	Datacentrová nebo firemní proxy	Předvídatelná allowlistace IP, nižší náklady
Firemní compliance	Systémová proxy, PAC proxy, autentizovaná firemní proxy	Centralizované logování a kontrola odchozího provozu
QA a lokalizační testování	Pool proxy podle zemí	Simuluje reálný přístup uživatelů z cílových regionů

Používání proxy také obvykle prochází předvídatelnými fázemi. Začnete s jednou statickou proxy, abyste ověřili, že směrování funguje. Produkční scraper pak přejde na pool, který mapuje požadavky na proxy podle cílové domény, geografie nebo míry selhání. Zralejší týmy často přecházejí na spravovanou proxy bránu, kde rotaci, retry i session affinity řeší jedna endpoint adresa.

Rotace proxy není všelék. Pokud cílový web blokuje podezřelé chování, samotné střídání IP pomůže jen tehdy, když zároveň pečlivě řešíte i četnost požadavků, hlavičky, cookies a TLS fingerprinting.

Která verze .NET podporuje co: rychlá tabulka kompatibility

Kopírování proxy ukázky z blogu do špatného cílového frameworku je častý zdroj tichých chyb. Největší hranice vede mezi .NET Framework 4.x a moderním .NETem (.NET 6+). Tady je přehled, co funguje kde:

Funkce	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
WebProxy + HttpClientHandler	Ano	Ano	Ano	Ano
SOCKS5 přes WebProxy("socks5://...")	Ne	Ano (přidáno v .NET 6)	Ano	Ano
SocketsHttpHandler (výchozí handler)	Ne	Ano	Ano	Ano
Statická HttpClient.DefaultProxy	Ne	Ano	Ano	Ano
PooledConnectionLifetime	Ne	Ano	Ano	Ano

Pokud cílíte na .NET Framework 4.x, držte se HTTP/HTTPS proxy s HttpClientHandler a WebProxy. SOCKS5 a moderní řízení poolingu vyžadují .NET 6 nebo novější.

Na jeden nenápadný detail si dejte pozor: HttpClient.DefaultProxy je v moderním .NET statická vlastnost. Pokud je nastavená ve sdíleném startup kódu nebo zděděná z proměnných prostředí jako HTTPS_PROXY nebo HTTP_PROXY, převezme ji každá instance HttpClient, pokud ji výslovně nepřepíšete v handleru. V kontejnerových nasazeních je to hodně častý zdroj zmatku typu „proč můj klient používá proxy, kterou jsem nikdy nenastavil?".

Krok 1: Vytvořte nový C# konzolový projekt

Otevřete terminál a vygenerujte nový projekt:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Zkontrolujte verzi SDK příkazem dotnet --version. Příklady v tomhle průvodci míří na .NET 6+ kvůli plné podpoře funkcí. Pokud potřebujete nejnovější LTS SDK, stáhněte si ho z download stránky Microsoftu.

Otevřete Program.cs ve svém editoru. Tam se bude dít všechno podstatné.

Krok 2: Udělejte základní HTTP požadavek bez proxy

Než proxy nakonfigurujete, zjistěte svou skutečnou odchozí IP adresu. Jakmile proxy zapnete, snadno ověříte, že se IP opravdu změnila.

using System.Net.Http;

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

Spusťte to. Měli byste vidět svou aktuální veřejnou IP adresu, například:

Přímá IP: 203.0.113.10

Hodnotu si zapamatujte. V dalším kroku by měla být jiná.

Krok 3: Nakonfigurujte WebProxy s HttpClientHandler

Klasický postup stojí na třech objektech: WebProxy, handler a klient.

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

Nahraďte proxy.example.com:8080 skutečným proxy endpointem. Pokud je všechno správně nastavené, výstupní IP by měla odpovídat exit IP proxy — ne vaší skutečné.

Klíčové vlastnosti, které je dobré chápat:

• Proxy — instance IWebProxy, kterou handler používá pro směrování.
• UseProxy = true — říká handleru, aby skutečně používal nakonfigurovanou proxy. (Zní to samozřejmě, ale zapomenout na to je opravdu běžný zdroj zdržení při ladění.)
• BypassProxyOnLocal = false — zabrání tomu, aby handler přeskočil proxy pro cíle, které vypadají jako „lokální“.
• UseDefaultCredentials — určuje, zda handler posílá výchozí Windows přihlašovací údaje. To není totéž co uživatelské jméno a heslo pro proxy.

Krok 4: Přidejte autentizaci proxy pomocí NetworkCredential

Většina placených poskytovatelů proxy vyžaduje přihlášení. Správný postup je nastavit přihlašovací údaje přímo na objektu 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($"Autentizovaná IP přes proxy: {ip}");

Mnoho poskytovatelů používá formát URL jako http://username:password@host:port. Pro .NET kód je ale lepší použít NetworkCredential než vkládat údaje přímo do URI řetězce. Vyhnete se problémům s escapováním speciálních znaků v heslech a zároveň je jasně oddělená adresa od přihlašovacích údajů.

Nejčastější chybu při autentizaci — a proč vede k chybám 407 — rozebírám v samostatné části níže.

Krok 5: Využijte nebo uložte data z odpovědi

U všeho, co je víc než rychlá kontrola IP, je potřeba s odpovědí správně pracovat:

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

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"Požadavek selhal: {(int)response.StatusCode} {response.ReasonPhrase}");
    return;
}

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

U scrapingových workflow je požadavek přes proxy jen transportní vrstva. Stále potřebujete parsování, normalizaci, deduplikaci, retry i export do Excelu, Google Sheets, databází nebo jiných cílů. Nástroje jako Thunderbit umí automatizovat extrakci i export — jeho Chrome rozšíření zvládá strukturovanou extrakci dat a export zdarma do Google Sheets, Excelu, Airtable nebo Notionu, aniž byste museli psát parsovací kód.

Exportujte sebraná data do Excelu, Sheets, Airtable nebo Notionu Get Started Free

Proxy přihlašovací údaje vs. serverové přihlašovací údaje: chyba, která způsobuje 407

Tuhle chybu jsem viděl v diskusích na Stack Overflow, v Microsoft Q&A a — upřímně — i ve vlastním kódu.

Rozdíl je jednoduchý, ale snadno se plete:

• Přihlašovací údaje k proxy autentizují vás vůči samotnému proxy serveru.
• Serverové přihlašovací údaje autentizují vás vůči cílovému serveru.

V HttpClientHandler jsou tyto údaje na různých vlastnostech. Když je nastavíte na špatnou, je to nejčastější příčina chyby 407 Proxy Authentication Required.

// ❌ ŠPATNĚ — nastavuje údaje pro cílový server, ne pro proxy
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ SPRÁVNĚ — nastavuje údaje přímo na objektu proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials míří na cílový server. WebProxy.Credentials míří na proxy. Pokud proxy vrací 407, přihlašovací údaje patří na proxy.

Ještě jedna past: HttpClientHandler.PreAuthenticate ovlivňuje předběžnou autentizaci pro cílový server. Neovlivňuje hlavičku Proxy-Authorization. Nepoužívejte ji jako opravu pro 407.

Jak rotovat proxy v HttpClient v C#

Vývojáři se na to ptají pořád dokola ve fórech. Odpověď je na začátku zklamáním: na běžící instanci HttpClient proxy změnit nemůžete. Proxy je na handleru. Handler se nastavuje při vytvoření. HttpClient nemá mutovatelnou vlastnost Proxy.

Naivní obcházení — new HttpClient(new HttpClientHandler { Proxy = ... }) pro každý požadavek — vytváří jiný problém. Microsoft výslovně upozorňuje, že vytváření a likvidace klienta pro každý request může vyčerpat dostupné TCP porty, protože porty se po zavření spojení neuvolňují okamžitě.

Tady jsou tedy tři produkční postupy, které opravdu fungují.

Varianta 1: Pojmenovaní klienti přes IHttpClientFactory

Pokud znáte sadu proxy už při startu aplikace, pojmenovaní klienti jsou nejmíň složitá možnost. Každý pojmenovaný klient má vlastní konfiguraci handleru a aplikace ho za běhu vybírá podle názvu.

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

// Při odeslání požadavku:
var client = httpClientFactory.CreateClient("proxy-us");

Factory se postará o životní cyklus handlerů a vyhnete se antipatternu klienta vytvářeného pro každý request.

Varianta 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)

Pro dlouho běžícího klienta za proxy bránou, která mění výstupní IP při nových spojeních, PooledConnectionLifetime vynutí znovuvytvoření spojení po nastavené době.

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

Tím se samotný objekt Proxy magicky nemění pro každý request. Nejlépe to funguje s proxy bránami, které při každém novém TCP spojení přidělí jinou exit IP, nebo s pooly proxy založenými na DNS, kde se hostname v čase překládá na různé endpointy.

Varianta 3: Vlastní DelegatingHandler pro pokročilý výběr proxy

Když výběr proxy závisí na URL požadavku, payloadu nebo běhovém kontextu, vlastní směrovací handler může každý request zkontrolovat a předat ho správné vnitřní pipeline.

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

Tohle je pokročilé řešení. Thread safety, disposal, znovupoužití handlerů, retry chování i logging pak řešíte sami. Doporučil bych ho jen tehdy, když první dvě varianty skutečně nevyhovují.

Srovnání tří přístupů

Přístup	Složitost	Verze .NET	Thread safety	Režie
Pojmenovaní klienti (IHttpClientFactory)	Nízká	.NET Core 2.1+	Vysoká (neměnná konfigurace)	Nízká
SocketsHttpHandler + PooledConnectionLifetime	Střední	.NET 6+	Vysoká	Nízká
Vlastní DelegatingHandler	Vysoká	Jakákoli	Záleží na implementaci	Střední

Pro většinu týmů jsou pojmenovaní klienti nejlepší výchozí bod. Na stabilní rotující brány přejděte s PooledConnectionLifetime a vlastní routing použijte jen tehdy, když volba proxy závisí na metadatech konkrétního requestu.

Jak vybrat správný proxy protokol: HTTP, HTTPS a SOCKS5

Ne všechny proxy mluví stejným jazykem a použití špatného protokolu povede ke zmateným chybám.

HTTP proxy: Rozumí HTTP požadavkům. Pro čistě HTTP cíle může požadavky přeposílat přímo. Pro HTTPS cíle klient pošle požadavek CONNECT, tím vytvoří tunel a TLS se pak vyjedná skrz ten tunel s cílovým serverem. To je nejběžnější model.

HTTPS-terminující proxy: Proxy prezentuje vlastní TLS certifikát a znovu šifruje upstream provoz. Běžné ve firemních inspekčních systémech a u některých spravovaných scraping API. Pokud klient nedůvěřuje řetězci certifikátů proxy, může to vyvolat chyby při ověřování certifikátu.

SOCKS5 proxy: TCP tunel na transportní vrstvě, který funguje pro jakýkoli TCP provoz, nejen pro HTTP. Široce používaný poskytovateli rezidenčních proxy. Nativně podporován v .NET 6+.

Ukázka 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);

Poznámka k ověřování SSL certifikátu

Při použití HTTPS-terminujících proxy můžete narazit na chyby RemoteCertificateNameMismatch. ServerCertificateCustomValidationCallback umožňuje upravit validaci:

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

Používejte to jen v lokálním vývoji nebo u důvěryhodné, schválené TLS-inspekční proxy. Slepo vracet true vypíná zásadní bezpečnostní kontrolu a otevírá cestu útokům typu man-in-the-middle. V produkci s běžnými CONNECT nebo SOCKS proxy nechte SSL validaci zapnutou.

Řešení nejčastějších chyb proxy v C# HttpClient

Tahle tabulka mapuje viditelný symptom na pravděpodobnou příčinu a první opravu, kterou stojí za to zkusit. Doporučuji si tuhle sekci uložit — pokrývá chyby, které se nejčastěji objevují v diskusích na Stack Overflow a na vývojářských fórech.

Chyba / symptom	Běžná příčina	Oprava
407 Proxy Authentication Required	Přihlašovací údaje jsou nastavené na handler.Credentials místo handler.Proxy.Credentials; špatný formát uživatelského jména; speciální znaky v hesle vloženém přímo v URL	Použijte WebProxy.Credentials = new NetworkCredential(...); nevkládejte přihlašovací údaje do URI; ověřte formát uživatelského jména u poskytovatele
TaskCanceledException / Timeout	Proxy endpoint je pomalý, nedostupný, přetížený nebo blokovaný firewallem; výchozí timeout 100 s je příliš krátký	Otestujte proxy přes curl; prodlužujte HttpClient.Timeout až po ověření, že endpoint funguje; přidejte retry a health checky proxy
SocketException / vyčerpání socketů	Vytváření a likvidace HttpClient nebo handlerů pro každý request	Použijte IHttpClientFactory, singleton klienty nebo SocketsHttpHandler s řízeními poolingu
SSL RemoteCertificateNameMismatch	HTTPS intercept přes firemní nebo spravovanou proxy	Nainstalujte/důvěřujte CA proxy tam, kde je to vhodné; vlastní validaci používejte jen v kontrolovaném dev prostředí nebo ve schválených MITM scénářích
302 Redirect loop	Captive stránka firemní proxy/VPN nebo allowlist blok, který opakovaně přesměrovává	Otestujte přímé připojení; zkontrolujte hlavičky Location; ověřte allowlist a autentizační portál proxy
HttpRequestException / No connection with SOCKS URL	SOCKS kód běží na .NET Frameworku nebo starším .NET; špatné schéma nebo port	Pro nativní podporu SOCKS použijte .NET 6+; ověřte socks5://host:port; testujte podle dokumentace poskytovatele
Proxy se zdá ignorovaná	UseProxy = false; cíl je považován za lokální; proměnná prostředí NO_PROXY; handler je nakonfigurován jinak, než čekáte	Nastavte UseProxy = true; zkontrolujte HttpClient.DefaultProxy; vymažte nebo přepište proměnné prostředí; nastavte BypassProxyOnLocal = false

Rychlý postup ladění

1. Požadavek proběhl úspěšně? → Ano: porovnejte výstup z api.ipify.org s očekávanou IP proxy.
2. Ne, ale je tu HTTP status kód? → 407: opravte přihlašovací údaje proxy. 403/429: cíl blokuje proxy nebo na ni uplatňuje rate limit. Smyčka 3xx: přesměrovává proxy nebo firemní gateway.
3. Žádný status kód, jen výjimka? → Timeout: otestujte dosažitelnost proxy. Socket/certificate exception: zkontrolujte pooling, protokol, TLS a verzi .NET.

Užitečné první příkazy pro ověření samotné proxy mimo .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/

Pokud curl funguje, ale vaše C# aplikace ne, rozdíl bývá většinou v auth schématu, TLS trust store, proměnných prostředí nebo escapování přihlašovacích údajů. Srovnejte proxy URL, schéma i autentizaci přesně s curl, a teprve potom přeneste přihlašovací údaje do NetworkCredential.

Kdy proxy management přeskočit: no-code alternativa

Významná část vývojářů, kteří hledají „HttpClient proxy C#“, se ve skutečnosti nechce učit teorii proxy — chtějí udržet scraper v provozu. Stojí za to být upřímný v tom, kdy je vlastní C# proxy kód správný nástroj a kdy ne.

Postavte vlastní C# scraper s rotací proxy, když:

• Potřebujete plnou kontrolu nad logikou požadavků, cookies, hlavičkami, retry a parsováním
• Scraper se integruje do existující .NET codebase nebo interní služby
• Compliance nebo bezpečnostní požadavky vyžadují, abyste vlastnili infrastrukturu end-to-end

Použijte no-code nástroj jako Thunderbit, když:

• Cílem je strukturovaná extrakce dat z webů, ne správa HTTP infrastruktury
• Nechcete udržovat pooly proxy, řešit CAPTCHA nebo ladit vyčerpání socketů
• Tým potřebuje data do Excelu, Google Sheets, Airtable nebo Notionu bez psaní parsovacího kódu

Chrome rozšíření Thunderbit zvládá rotaci proxy i anti-bot opatření automaticky díky cloud scraping režimu. Jeho API umožňuje vývojářům definovat JSON schéma a získat zpět strukturovaná data bez správy HttpClient nebo WebProxy. Pro týmy, které dělají web scraping pro porovnání cen nebo exktrakci leadů, je rozdíl v čase na nasazení výrazný.

Scénář	Vlastní C# + proxy	Thunderbit
Plná kontrola nad logikou requestů	Ano	Ne (řízení na úrovni API)
Nutná správa proxy	Ano	Ne (řešeno automaticky)
Anti-bot / CAPTCHA handling	Ručně nebo přes třetí stranu	Vestavěné
Doba nastavení	Hodiny až dny	Minuty
Nejvhodnější pro	Existující .NET codebase, vlastní pipeline	Rychlá extrakce dat, netechnické týmy, exporty do tabulek

Tohle není argument proti používání HttpClient za každou cenu. Pokud stavíte produkční .NET službu, konfiguraci proxy rozhodně rozumět musíte. Ale pokud u jednorázového sběru dat trávíte hodiny laděním chyb 407, existují jednodušší možnosti — a není důvod se jim bránit. Můžete si projít ceník Thunderbit nebo se podívat na YouTube kanál s ukázkami.

Hlavní závěry

Základní vzorec zůstává stejný: WebProxy → handler → HttpClient. Všechno ostatní je o tom vyhnout se provozním chybám, které se objeví až v produkci.

• Přihlašovací údaje patří na proxy, ne na handler. Ukázka vedle části o 407 je to nejdůležitější, co si zapamatovat.
• Nevytvářejte nový HttpClient pro každý request ani pro každou proxy. Použijte IHttpClientFactory pro pojmenované klienty, SocketsHttpHandler s PooledConnectionLifetime pro rotující brány nebo vlastní routing handler pro pokročilé scénáře.
• Před kopírováním SOCKS5 nebo SocketsHttpHandler kódu zkontrolujte verzi .NET. Tabulka kompatibility výše vám ušetří tiché chyby.
• Nejdřív proxy otestujte mimo .NET. Rychlý curl eliminuje celou kategorii ladění.
• Pro strukturovanou extrakci dat bez starostí s proxy nástroje jako Thunderbit přebírají transportní vrstvu, takže se můžete soustředit na samotná data.

Až příště narazíte na 407 nebo TaskCanceledException, začněte tabulkou řešení problémů výše.

FAQ

Můžu změnit proxy na existující instanci HttpClient?

Ne. Proxy je navázaná na handler a handler se nastavuje při vytvoření. HttpClient nemá mutovatelnou vlastnost Proxy. Pro různé proxy vytvořte samostatné handlery a klienty a spravujte je pomocí pojmenovaných klientů IHttpClientFactory nebo poolu předkonfigurovaných klientů.

Používá HttpClient ve výchozím stavu systémovou proxy?

Ano. V moderním .NETu, pokud explicitně nenastavíte handler, HttpClient přebírá výchozí systémová proxy nastavení — včetně proměnných prostředí jako HTTPS_PROXY a HTTP_PROXY přes HttpClient.DefaultProxy. Pokud to chcete vypnout, nastavte na handleru UseProxy = false.

Jak použít SOCKS5 proxy s HttpClient v C#?

Použijte new WebProxy("socks5://host:port") spolu s SocketsHttpHandler. Nativní podpora SOCKS proxy vyžaduje .NET 6 nebo novější. V .NET Framework 4.x SOCKS5 nativně podporován není — potřebovali byste knihovnu třetí strany.

Proč pořád dostávám 407 Proxy Authentication Required?

Nejspíš nastavujete přihlašovací údaje na handler.Credentials (což míří na cílový server) místo na handler.Proxy.Credentials (což míří na proxy). Podívejte se výše na sekci „Proxy přihlašovací údaje vs. serverové přihlašovací údaje“ pro správný postup.

Je bezpečné vypnout ověřování SSL certifikátu při použití proxy?

Jen v lokálním vývoji nebo tehdy, když poskytovateli proxy plně důvěřujete (například spravované scraping API v režimu HTTPS proxy). V produkci s běžnými CONNECT nebo SOCKS proxy nechte SSL validaci zapnutou, abyste předešli útokům typu man-in-the-middle.

Vyzkoušejte Thunderbit pro bezproblémový web scraping Get Started Free

Další informace

• Nejlepší automatizované nástroje pro web scraping
• Jak vytvořit web scraper
• Nejlepší služby pro web scraping
• Nejlepší jazyk pro web scraping
• Web scraping bez blokací