Geçen hafta, 407 Proxy Authentication Required yanıtına bakıp durarak utanç verici derecede fazla zaman harcadım; proxy sağlayıcımın bozuk olduğuna emindim. Meğer kimlik bilgilerini yanlış özelliğe yazmışım — iki satırlık bir düzeltmeyi bulmam iki saatimi aldı. Size de tanıdık geldiyse, bu rehber tam size göre.
C# içinde HttpClient ile proxy yapılandırması, temel akışın oldukça basit olduğu; ancak üretimde karşınıza çıkan ayrıntıların — socket tükenmesi, SOCKS5 sürüm uyumsuzlukları, kimlik bilgisi karışıklığı — ciddi zaman yediği konulardan biri.
Bir süredir Thunderbit tarafında web scraping ve veri çıkarma araçlarıyla çalışıyorum. Bu hataları hem kendi mühendislik konuşmalarımızda hem de takip ettiğimiz geliştirici topluluklarında tekrar tekrar gördüm. Bu anlatım, kurulumdan kimlik doğrulamaya, proxy rotasyonundan protokol seçimine ve gerçekten ilk başladığım gün elimde olmasını dilediğim bir sorun giderme tablosuna kadar eksiksiz bir yol haritası sunuyor.
Zorluk Seviyesi: Başlangıç–Orta
Gerekli Süre: Adımları takip etmek için yaklaşık 15 dakika, üretim rotasyon desenleri için daha uzun
Gereksinimler: .NET 6+ SDK (SOCKS5 ve modern handler özellikleri için; temel HTTP proxy örnekleri için .NET Framework 4.x de yeterlidir), bir kod editörü ve test edebileceğiniz en az bir proxy uç noktası
HttpClient Nedir ve Neden Proxy’ye İhtiyaç Duyar?

HttpClient, .NET’in System.Net.Http içinde yer alan ve HTTP istekleri gönderip yanıtları almak için kullanılan yerleşik sınıfıdır. async/await desteği, özel başlıklar, cancellation token’lar ve handler tabanlı yapılandırma sunar. Microsoft bunu URI ile tanımlanan bir kaynaktan HTTP isteği gönderip HTTP yanıtı almak için kullanılan bir sınıf olarak tanımlar.
Proxy sunucusu, uygulamanız ile hedef site arasında duran bir ara katmandır. Trafiği proxy üzerinden yönlendirdiğinizde hedef site sizin IP’niz yerine proxy’nin IP adresini görür.
HttpClient’ın kendisinde bir Proxy özelliği yoktur. Proxy yönlendirmesi, alttaki handler üzerinde yapılandırılır — yani HttpClientHandler ya da SocketsHttpHandler — ve bu handler bir WebProxy örneği kabul eder. Zihinsel model şöyle görünür:
[Sizin C# Uygulamanız] → [HttpClient + Handler] → [Proxy Sunucusu] → [Hedef Web Sitesi]
Bu yüzden “canlı bir HttpClient’ın proxy’sini değiştir” meselesi basit bir özellik atamasından ziyade bir tasarım problemidir. Rotasyon bölümünde buna yeniden döneceğiz.
Daha kolay veri çıkarımı için Thunderbit’i deneyin
C#’ta HttpClient ile Neden Proxy Kullanılır?
Geliştiriciler HttpClient trafiğini proxy üzerinden birkaç tekrar eden sebeple yönlendirir; doğru proxy türü ise işin amacına göre değişir.
- IP ban’lerinden ve rate limit’lerden kaçınmak: Ölçekli web scraping, lead oluşturma veya fiyat izleme için kritik önemdedir. Tek bir IP’nin siteyi sürekli yoklaması kısa sürede engellenir.
- Coğrafi kısıtları aşmak: Belirli ülkelerdeki proxy’ler üzerinden geçerek bölge kilitli API’lere veya içeriklere erişebilirsiniz.
- Kaynak IP’nizi gizlemek: Hassas veri toplama ya da rekabet araştırmaları için ek bir gizlilik katmanı sağlar.
- Kurumsal ya da uyumluluk gereksinimleri: Birçok şirket, giden trafiğin merkezi bir ağ geçidinden geçmesini; böylece loglama ve denetimin tek noktadan yapılmasını ister.
- Test ve QA: O bölgelerde fiziksel altyapı kurmadan farklı konumlar ya da ağ koşullarından gelen istekleri simüle edebilirsiniz.
| Kullanım Senaryosu | Tipik Proxy Seçimi | Neden Uygun |
|---|---|---|
| Ölçekli web scraping | Dönen residential proxy’ler | Daha fazla IP çeşitliliği, anti-bot sistemleri için daha zor sınıflandırma |
| E-ticaret fiyat takibi | Residential veya coğrafi hedefli datacenter proxy | Bölgeye göre fiyat ve stok kontrolleri |
| Sabit bir ağ geçidi üzerinden API erişimi | Datacenter proxy veya kurumsal proxy | Tahmin edilebilir IP allowlisting, daha düşük maliyet |
| Kurumsal uyumluluk | Sistem proxy’si, PAC proxy’si, kimlik doğrulamalı şirket proxy’si | Merkezi loglama ve çıkış trafiği kontrolü |
| QA ve lokalizasyon testi | Ülke bazlı proxy havuzu | Hedef bölgelerdeki gerçek kullanıcı erişimini taklit eder |
Proxy kullanımı da tahmin edilebilir aşamalarda ölçeklenir. Önce yönlendirmeyi doğrulamak için tek bir statik proxy ile başlarsınız. Üretim ortamındaki bir scraper, istekleri hedef domaine, coğrafyaya ya da hata oranına göre proxy’lere eşleyen bir havuza geçer. Olgun ekipler çoğu zaman rotasyon, retry ve oturum sürekliliğinin tek bir uç noktanın arkasında yönetildiği bir proxy gateway’e taşınır.
Proxy rotasyonu her derde deva değildir. Hedef site şüpheli davranışı engelliyorsa, IP değiştirmek yalnızca istek sıklığı, başlıklar, çerezler ve TLS parmak izi de dikkatle yönetiliyorsa işe yarar.
Hangi .NET Sürümü Neyi Destekler: Hızlı Uyumluluk Tablosu
Bir blog postundaki proxy örneğini yanlış target framework’e kopyalamak, sessiz hataların en büyük sebeplerinden biridir. En belirgin ayrım .NET Framework 4.x ile modern .NET (.NET 6+) arasındadır. İşte nerede ne çalışır:

| Özellik | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | Evet | Evet | Evet | Evet |
WebProxy("socks5://...") ile SOCKS5 | Hayır | Evet (.NET 6’da eklendi) | Evet | Evet |
SocketsHttpHandler (varsayılan handler) | Hayır | Evet | Evet | Evet |
HttpClient.DefaultProxy statik özelliği | Hayır | Evet | Evet | Evet |
PooledConnectionLifetime | Hayır | Evet | Evet | Evet |
Eğer hedefiniz .NET Framework 4.x ise, HttpClientHandler ve WebProxy ile HTTP/HTTPS proxy’lerine bağlı kalın. SOCKS5 ve modern pooling kontrolleri için .NET 6 veya sonrası gerekir.
Dikkat edilmesi gereken ince bir davranış daha var: modern .NET’te HttpClient.DefaultProxy statik bir özelliktir. Ortak başlangıç kodunda ayarlanmışsa veya HTTPS_PROXY ya da HTTP_PROXY gibi ortam değişkenlerinden geliyorsa, handler’ı açıkça geçersiz kılmadığınız sürece her HttpClient örneği bunu devralır. Container tabanlı dağıtımlarda bu, sık görülen “istemcim neden hiç ayarlamadığım bir proxy’yi kullanıyor?” karmaşasının başlıca nedenidir.
Adım 1: Yeni Bir C# Console Projesi Oluşturun
Bir terminal açın ve yeni bir proje oluşturun:
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
SDK sürümünüzü dotnet --version ile doğrulayın. Bu rehberdeki örnekler tam özellik kapsamı için .NET 6+ hedeflenmiştir. En güncel LTS SDK’yı almak isterseniz Microsoft’un indirme sayfasına göz atın.
Editörünüzde Program.cs dosyasını açın. Tüm işlemler orada gerçekleşecek.
Adım 2: Proxy Olmadan Temel Bir HTTP İsteği Gönderin
Proxy yapılandırmadan önce gerçek çıkış IP’nizi görün. Böylece proxy aktif olduğunda IP’nin gerçekten değişip değişmediğini doğrulayabilirsiniz.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");
Çalıştırın. Mevcut genel IP adresinizi görmelisiniz; örneğin:
Direct IP: 203.0.113.10
Bu değeri aklınızda tutun. Bir sonraki adımdan sonra farklı olmalıdır.
Adım 3: HttpClientHandler ile WebProxy Yapılandırın
Klasik yapı üç nesneden oluşur: bir WebProxy, bir handler ve client.
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
BypassProxyOnLocal = false
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true,
UseDefaultCredentials = false
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Proxy IP: {ip}");
proxy.example.com:8080 kısmını kendi proxy uç noktanızla değiştirin. Her şey doğru bağlandıysa çıktıdaki IP artık gerçek IP’niz değil, proxy’nizin çıkış IP’si olmalıdır.
Anlamanız gereken temel özellikler:
Proxy— handler’ın yönlendirme için kullandığıIWebProxyörneği.UseProxy = true— handler’a yapılandırılmış proxy’yi gerçekten kullanmasını söyler. (Basit görünüyor, ama bunu unutmak ciddi bir debug tuzağıdır.)BypassProxyOnLocal = false— handler’ın “yerel” görünen hedefler için proxy’yi atlamasını engeller.UseDefaultCredentials— handler’ın Windows varsayılan kimlik bilgilerini gönderip göndermeyeceğini belirler. Bu, proxy kullanıcı adı/parolasıyla aynı şey değildir.

Adım 4: NetworkCredential ile Proxy Kimlik Doğrulaması Ekleyin
Ücretli proxy sağlayıcılarının çoğu kimlik bilgisi ister. Doğru yöntem, bilgileri doğrudan WebProxy nesnesine eklemektir:
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($"Authenticated proxy IP: {ip}");
Birçok sağlayıcı http://username:password@host:port gibi bir URL formatı verir. .NET kodunda, kimlik bilgilerini URI string’inin içine gömmek yerine NetworkCredential kullanmanız daha doğrudur. Bu yöntem, paroladaki özel karakterler için kaçış sorunlarını önler ve URI ile kimlik bilgileri arasındaki ayrımı net tutar.
En yaygın kimlik doğrulama hatasını — ve bunun neden 407 hatalarına yol açtığını — aşağıdaki özel bölümde ele alacağım.
Adım 5: Yanıt Verisini Dışa Aktarın veya Kullanın
Hızlı bir IP kontrolünün ötesinde her durumda yanıtı doğru şekilde işlemeniz gerekir:
using var response = await client.GetAsync("https://example.com/api/products");
if (!response.IsSuccessStatusCode)
{
Console.WriteLine($"İstek başarısız: {(int)response.StatusCode} {response.ReasonPhrase}");
return;
}
var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);
Scraping akışlarında proxy üzerinden gönderilen istek yalnızca taşıma katmanıdır. Hâlâ ayrıştırma, normalizasyon, yinelenen kayıtları temizleme, retry ve Excel, Google Sheets, veritabanları ya da başka hedeflere dışa aktarma gerekir. Thunderbit gibi araçlar, çıkarma ve export adımlarını otomatikleştirebilir — Chrome uzantısı yapılandırılmış veri çıkarımını ve Google Sheets, Excel, Airtable veya Notion’a ücretsiz dışa aktarmayı, ayrıştırma kodu yazmanıza gerek kalmadan yapar.
Çıkarılan veriyi Excel, Sheets, Airtable veya Notion’a aktarın Get Started Free
Proxy Kimlik Bilgileri ile Sunucu Kimlik Bilgileri: 407 Hatasına Yol Açan Karışıklık

Bu hatayı Stack Overflow başlıklarında, Microsoft Q&A gönderilerinde ve itiraf etmeliyim ki kendi kodumda gördüm.
Ayrım basit, fakat karıştırması kolaydır:
- Proxy kimlik bilgileri sizi proxy sunucusuna doğrular.
- Sunucu kimlik bilgileri sizi hedef sunucuya doğrular.
HttpClientHandler içinde bunlar farklı özelliklerde yer alır. Kimlik bilgilerini yanlış yere koymak, 407 Proxy Authentication Required hatalarının bir numaralı sebebidir.
// ❌ YANLIŞ — hedef sunucu için kimlik bilgisi ayarlar, proxy için değil
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ DOĞRU — kimlik bilgilerini doğrudan proxy nesnesine ayarlar
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials hedef sunucuyu, WebProxy.Credentials ise proxy’yi hedefler. Proxy 407 döndürüyorsa kimlik bilgileriniz proxy tarafında olmalıdır.
Bir tuzak daha var: HttpClientHandler.PreAuthenticate, hedef sunucu kimlik doğrulaması için ön kimlik doğrulama davranışını kontrol eder. Proxy-Authorization başlığını kontrol etmez. Bunu 407 çözümü olarak kullanmayın.
C#’ta HttpClient ile Proxy Rotasyonu Nasıl Yapılır
Geliştiriciler forumlarda bunu sürekli sorar. İlk cevap biraz hayal kırıklığı yaratır: canlı bir HttpClient örneğinde proxy’yi değiştiremezsiniz. Proxy handler üzerinde yaşar. Handler, oluşturma anında belirlenir. HttpClient mutable bir Proxy özelliği sunmaz.
Saf yaklaşım — her istek için new HttpClient(new HttpClientHandler { Proxy = ... }) oluşturmak — başka bir sorun yaratır. Microsoft, istek başına client oluşturup dispose etmenin özellikle TCP portlarını tüketebileceği konusunda açıkça uyarır; çünkü bağlantı kapandıktan hemen sonra portlar serbest bırakılmaz.

Bu yüzden, gerçekten işe yarayan üç üretim düzeyi yaklaşım aşağıdadır.
Seçenek 1: IHttpClientFactory ile Adlandırılmış Client’lar
Proxy listeniz başlangıçta belliyse, adlandırılmış client’lar en düşük karmaşıklıktaki seçenektir. Her adlandırılmış client kendi handler yapılandırmasını alır ve uygulama kodu çalışma anında isme göre çözümleme yapar.
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
});
// İstek anında:
var client = httpClientFactory.CreateClient("proxy-us");
Factory, handler ömürlerini yönetir ve istek başına client oluşturma anti-pattern’ini engeller.
Seçenek 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
Yeni bağlantılarda çıkış IP’sini döndüren bir proxy gateway arkasında uzun ömürlü bir client kullanıyorsanız, PooledConnectionLifetime bağlantıların belirli bir süreden sonra yeniden oluşturulmasını sağlar.
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);
Bu, Proxy nesnesini istek bazında sihirli şekilde değiştirmez. En iyi sonucu, her yeni TCP bağlantısında farklı bir çıkış IP atayan proxy gateway’lerle ya da hostname’inin zaman içinde farklı uç noktalara çözümlendiği DNS tabanlı proxy havuzlarıyla verir.
Seçenek 3: Gelişmiş Proxy Seçimi için Özel DelegatingHandler
Proxy seçimi istek URL’sine, payload’a veya çalışma zamanı bağlamına bağlıysa, özel bir yönlendirme handler’ı her isteği inceleyip doğru iç handler hattına iletebilir.
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);
}
}
Bu ileri seviye bir tasarımdır. Thread safety, disposal, handler yeniden kullanımı, retry davranışı ve loglama tamamen sizin sorumluluğunuz olur. İlk iki seçenek gerçekten uymuyorsa ancak o zaman öneririm.
Üç Yaklaşımın Karşılaştırması
| Yaklaşım | Karmaşıklık | .NET Sürümü | Thread Safety | Ek Yük |
|---|---|---|---|---|
| Adlandırılmış client’lar (IHttpClientFactory) | Düşük | .NET Core 2.1+ | Yüksek (değişmez yapılandırma) | Düşük |
| SocketsHttpHandler + PooledConnectionLifetime | Orta | .NET 6+ | Yüksek | Düşük |
| Özel DelegatingHandler | Yüksek | Herhangi biri | Uygulamaya bağlı | Orta |
Çoğu ekip için başlangıç noktası adlandırılmış client’lardır. Kararlı dönen gateway’ler için PooledConnectionLifetime’a geçin; proxy seçimi istek düzeyindeki metadata’ya bağlıysa özel yönlendirmeyi kullanın.
Doğru Proxy Protokolünü Seçmek: HTTP, HTTPS ve SOCKS5
Tüm proxy’ler aynı dili konuşmaz; yanlış protokol şeması kullanırsanız kafa karıştırıcı hatalar alırsınız.
HTTP proxy: HTTP isteklerini anlar. Düz HTTP hedeflerinde istekleri doğrudan iletebilir. HTTPS hedeflerinde, istemci tünel oluşturmak için bir CONNECT isteği gönderir; ardından TLS, bu tünel üzerinden hedefle müzakere edilir. En yaygın model budur.
HTTPS-terminating proxy: Proxy kendi TLS sertifikasını sunar ve upstream trafiğini yeniden şifreler. Kurumsal inceleme sistemlerinde ve bazı yönetilen scraping API’lerinde yaygındır. İstemci proxy’nin sertifika zincirine güvenmiyorsa sertifika doğrulama hatalarına yol açabilir.
SOCKS5 proxy: Yalnızca HTTP değil, herhangi bir TCP trafiği için çalışan taşıma katmanı TCP tünelidir. Residential proxy sağlayıcılarında yaygın olarak kullanılır. .NET 6+ içinde doğal olarak desteklenir.
SOCKS5 örneği:
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);
SSL Sertifika Doğrulaması Hakkında Bir Not
HTTPS-terminating proxy kullanırken RemoteCertificateNameMismatch hataları görebilirsiniz. ServerCertificateCustomValidationCallback ile doğrulamayı özelleştirebilirsiniz:
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
Bunu yalnızca yerel geliştirmede veya güvenilir, onaylı bir TLS-intercepting proxy ile kullanın. Körü körüne true döndürmek kritik bir güvenlik kontrolünü devre dışı bırakır ve sizi man-in-the-middle saldırılarına açık hâle getirir. Üretimde standart CONNECT ya da SOCKS proxy’lerinde SSL doğrulamasını açık bırakın.
C# HttpClient’ta Yaygın Proxy Hatalarını Giderme

Bu tablo, görünen semptomu olası kök nedene ve denenecek ilk çözüme eşler. Bu bölümü yer imlerine eklemeniz iyi olur — Stack Overflow başlıklarında ve geliştirici forumlarında en sık çıkan hataları kapsıyor.
| Hata / Belirti | Yaygın Neden | Çözüm |
|---|---|---|
| 407 Proxy Authentication Required | Kimlik bilgileri handler.Proxy.Credentials yerine handler.Credentials üzerine ayarlanmış; kullanıcı adı formatı yanlış; URL içine gömülü parolada özel karakterler var | WebProxy.Credentials = new NetworkCredential(...) kullanın; kimlik bilgilerini URI içine gömmeyin; sağlayıcının kullanıcı adı formatını doğrulayın |
| TaskCanceledException / Timeout | Proxy uç noktası yavaş, erişilemiyor, aşırı yük altında veya firewall tarafından engellenmiş; varsayılan 100 saniyelik zaman aşımı kısa kalıyor | Proxy’yi curl ile test edin; HttpClient.Timeout değerini yalnızca uç noktanın çalıştığı doğrulandıktan sonra artırın; retry ve health check ekleyin |
| SocketException / Socket exhaustion | Her istek için HttpClient ya da handler oluşturulup dispose ediliyor | IHttpClientFactory, singleton client’lar veya pooling kontrolleri olan SocketsHttpHandler kullanın |
| SSL RemoteCertificateNameMismatch | Kurumsal veya yönetilen proxy tarafından HTTPS interception yapılıyor | Uygunsa proxy CA’yı kurun/güvenilir hâle getirin; özel doğrulamayı yalnızca kontrollü geliştirme veya onaylı MITM senaryolarında kullanın |
| 302 Redirect loop | Kurumsal proxy/VPN captive sayfası veya allowlist engeli sürekli yönlendirme yapıyor | Doğrudan bağlantıyı test edin; Location başlıklarını inceleyin; proxy allowlist ve kimlik doğrulama portalını kontrol edin |
| HttpRequestException / SOCKS URL ile bağlantı yok | SOCKS kodu .NET Framework veya daha eski .NET üzerinde çalışıyor; şema ya da port yanlış | Yerel SOCKS desteği için .NET 6+ kullanın; socks5://host:port doğrulayın; sağlayıcı dokümantasyonuyla test edin |
| Proxy yok sayılıyor gibi görünüyor | UseProxy = false; hedef yerel olarak atlanıyor; NO_PROXY ortam değişkeni; handler beklenenden farklı yapılandırılmış | UseProxy = true ayarlayın; HttpClient.DefaultProxy’yi inceleyin; ortam değişkenlerini temizleyin ya da geçersiz kılın; BypassProxyOnLocal = false ayarlayın |
Hızlı Sorun Giderme Akışı
- İstek başarılı oldu mu? → Evet:
api.ipify.orgçıktısını beklenen proxy IP’siyle karşılaştırın. - Hayır, bir HTTP durum kodu mu var? → 407: proxy kimlik bilgilerini düzeltin. 403/429: hedef, proxy’yi engelliyor veya rate limit uyguluyor. 3xx döngüsü: proxy/kurumsal ağ geçidi yönlendirme yapıyor olabilir.
- Durum kodu yok, sadece exception mı var? → Timeout: proxy erişilebilirliğini test edin. Socket/sertifika exception’ı: pooling, protokol, TLS ve .NET sürümünü kontrol edin.
Proxy’nin kendisini .NET dışında doğrulamak için kullanışlı ilk komutlar:
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/
curl çalışıyor ama C# kodunuz çalışmıyorsa fark genellikle kimlik doğrulama şeması, TLS trust store, ortam değişkenleri ya da kimlik bilgisi kaçışlama biçiminden kaynaklanır. curl’ün proxy URL’sini, şemasını ve auth biçimini birebir eşleştirin; ardından kimlik bilgilerini NetworkCredential içine taşıyın.
Proxy Yönetimini Ne Zaman Atlamalı: No-Code Alternatifi
“HttpClient proxy C#” araması yapan geliştiricilerin önemli bir kısmı aslında proxy teorisi öğrenmek istemiyor — bir scraper’ı ayakta tutmaya çalışıyor. Bu noktada özel C# proxy kodunun doğru araç olup olmadığını dürüstçe değerlendirmek gerekir.
Şunlar gerekiyorsa özel C# scraper + proxy rotasyonu kurun:
- İstek mantığı, çerezler, başlıklar, retry ve ayrıştırma üzerinde tam kontrol
- Scraper’ın mevcut bir .NET kod tabanına ya da iç servise entegre olması
- Uyumluluk veya güvenlik gereksinimleri nedeniyle altyapının uçtan uca sizin sorumluluğunuzda olması
Şunlar gerekiyorsa Thunderbit gibi no-code bir araç kullanın:
- Hedefiniz HTTP altyapısı değil, web sitelerinden yapılandırılmış veri çıkarmaksa
- Proxy havuzlarıyla uğraşmak, CAPTCHA çözmek ya da socket exhaustion debug etmek istemiyorsanız
- Ekibin, ayrıştırma kodu yazmadan Excel, Google Sheets, Airtable veya Notion içine veri alması gerekiyorsa
Thunderbit’in Chrome uzantısı, bulut scraping seçeneği üzerinden proxy rotasyonu ve anti-bot önlemlerini otomatik olarak yönetir. API’si, geliştiricilerin bir JSON şeması tanımlayıp HttpClient ya da WebProxy yönetmeden yapılandırılmış veri almasını sağlar. Fiyat karşılaştırması için web scraping veya lead çıkarımı yapan ekipler için kurulum süresi farkı çok belirgindir.
| Senaryo | Özel C# + Proxy | Thunderbit |
|---|---|---|
| İstek mantığı üzerinde tam kontrol | Evet | Hayır (API seviyesinde kontrol) |
| Proxy yönetimi gerekir | Evet | Hayır (otomatik yönetilir) |
| Anti-bot / CAPTCHA yönetimi | Manuel veya üçüncü taraf | Yerleşik |
| Kurulum süresi | Saatler–günler | Dakikalar |
| En uygun kullanım | Mevcut .NET kod tabanları, özel akışlar | Hızlı veri çıkarma, teknik olmayan ekipler, spreadsheet export’ları |
Bu, “asla HttpClient kullanmayın” argümanı değil. Üretim bir .NET servisi geliştiriyorsanız, proxy yapılandırmasını mutlaka anlamalısınız. Ama tek seferlik bir veri toplama işi için 407 hatalarını saatlerce debug ediyorsanız, daha basit seçenekler vardır — ve onları kullanmanın hiçbir ayıbı yoktur. Thunderbit fiyatlandırmasını inceleyebilir ya da adım adım anlatımlar için YouTube kanalına göz atabilirsiniz.
Önemli Çıkarımlar
Temel desen değişmez: WebProxy → handler → HttpClient. Bunun sonrasında gelen her şey, üretimde ortaya çıkan operasyonel hatalardan kaçınmakla ilgilidir.
- Kimlik bilgileri handler’a değil, proxy’ye yazılır. 407 bölümündeki yan yana örnek, akılda tutulması gereken en önemli noktadır.
- Her istek veya her proxy için yeni bir
HttpClientoluşturmayın. Adlandırılmış client’lar içinIHttpClientFactory, dönen gateway’ler içinPooledConnectionLifetimeileSocketsHttpHandler, gelişmiş senaryolar için özel routing handler kullanın. - SOCKS5 ya da
SocketsHttpHandlerkodunu kopyalamadan önce .NET sürümünüzü kontrol edin. Yukarıdaki uyumluluk tablosu sizi sessiz hatalardan kurtarır. - Önce proxy’yi .NET dışında test edin. Hızlı bir
curlkomutu, debug edilecek sorunların büyük bir kısmını eleyebilir. - Proxy baş ağrısı olmadan yapılandırılmış veri çıkarmak için Thunderbit gibi araçlar taşıma katmanını sizin yerinize yönetir; siz verinin kendisine odaklanırsınız.
Bir dahaki sefer 407 veya bir TaskCanceledException gördüğünüzde, önce yukarıdaki sorun giderme tablosuna bakın.
SSS
Mevcut bir HttpClient örneğinde proxy’yi değiştirebilir miyim?
Hayır. Proxy handler’a bağlıdır ve handler oluşturma anında belirlenir. HttpClient değiştirilebilir bir Proxy özelliği sunmaz. Farklı proxy’ler için ayrı handler’lar ve client’lar oluşturun; bunları IHttpClientFactory adlandırılmış client’lar ya da önceden yapılandırılmış client havuzlarıyla yönetin.
HttpClient varsayılan olarak sistem proxy’sini kullanır mı?
Evet. Modern .NET’te handler’ı açıkça ayarlamazsanız HttpClient, HttpClient.DefaultProxy üzerinden HTTPS_PROXY ve HTTP_PROXY gibi ortam değişkenleri de dahil olmak üzere sistemin varsayılan proxy ayarlarını devralır. Bunu kapatmak için handler üzerinde açıkça UseProxy = false ayarlayın.
C#’ta HttpClient ile SOCKS5 proxy’yi nasıl kullanırım?
SocketsHttpHandler ile new WebProxy("socks5://host:port") kullanın. Yerel SOCKS proxy desteği yalnızca .NET 6 veya sonrası için geçerlidir. .NET Framework 4.x’te SOCKS5 doğal olarak desteklenmez; üçüncü taraf bir kütüphane gerekir.
Neden sürekli 407 Proxy Authentication Required alıyorum?
Büyük olasılıkla kimlik bilgilerini handler.Proxy.Credentials yerine handler.Credentials üzerine yazıyorsunuzdur. İlk seçenek proxy’yi, ikinci seçenek hedef sunucuyu hedefler. Doğru desen için yukarıdaki “Proxy Kimlik Bilgileri ile Sunucu Kimlik Bilgileri” bölümüne bakın.
Proxy kullanırken SSL sertifika doğrulamasını kapatmak güvenli mi?
Yalnızca yerel geliştirmede veya proxy sağlayıcısına tamamen güvendiğiniz durumda güvenlidir (örneğin HTTPS proxy modunda yönetilen bir scraping API). Üretimde standart CONNECT ya da SOCKS proxy’leriyle SSL doğrulamasını açık tutun; aksi hâlde man-in-the-middle saldırılarına açık hâle gelirsiniz.
Zahmetsiz web scraping için Thunderbit’i deneyin Get Started Free
Daha Fazla Bilgi


