Cara Menggunakan Proxy dengan HttpClient di C#: Pola & Solusi

Minggu lalu saya buang waktu yang bikin malu cuma buat menatap respons 407 Proxy Authentication Required, sambil yakin provider proxy saya yang error. Ternyata masalahnya ada di properti yang salah untuk kredensial—perbaikan dua baris yang butuh dua jam sampai akhirnya ketemu. Kalau Anda pernah kena hal serupa, panduan ini memang buat Anda.

Konfigurasi proxy dengan HttpClient di C# memang kelihatannya simpel di permukaan, tapi jebakan di dunia produksi—socket exhaustion, versi SOCKS5 yang tidak cocok, sampai kebingungan soal kredensial—bisa menghabiskan banyak waktu.

Saya sudah cukup lama berkutat dengan alat web scraping dan ekstraksi data di Thunderbit, dan saya lihat kesalahan yang sama muncul terus-menerus, baik di diskusi engineering internal maupun komunitas developer yang kami ikuti. Panduan ini membahas alurnya dari ujung ke ujung: setup, autentikasi, rotasi proxy, pemilihan protokol, sampai tabel troubleshooting yang sejujurnya saya harap sudah ada sejak hari pertama saya mulai.

Tingkat Kesulitan: Pemula hingga Menengah
Waktu yang Dibutuhkan: sekitar 15 menit untuk mengikuti contoh, lebih lama untuk pola rotasi di produksi
Yang Anda Butuhkan: .NET 6+ SDK (untuk SOCKS5 dan fitur handler modern; .NET Framework 4.x masih bisa untuk contoh proxy HTTP dasar), editor kode, dan setidaknya satu endpoint proxy untuk diuji

Apa Itu HttpClient dan Mengapa Butuh Proxy?

HttpClient adalah kelas bawaan .NET di System.Net.Http untuk mengirim request HTTP dan menerima respons. Kelas ini mendukung async/await, custom header, cancellation token, dan konfigurasi berbasis handler. Microsoft mendeskripsikannya sebagai kelas untuk mengirim request HTTP dan menerima respons HTTP dari sumber yang diidentifikasi oleh URI.

Proxy server adalah perantara di antara aplikasi Anda dan website tujuan. Saat lalu lintas lewat proxy, website tujuan akan melihat alamat IP proxy, bukan IP Anda.

HttpClient sendiri tidak punya properti Proxy. Routing proxy dikonfigurasi di handler yang mendasarinya—baik HttpClientHandler maupun SocketsHttpHandler—yang menerima instance WebProxy. Gambaran sederhananya seperti ini:

[Aplikasi C# Anda] → [HttpClient + Handler] → [Server Proxy] → [Website Target]

Karena itu, “mengganti proxy pada HttpClient yang sedang aktif” bukan sekadar soal set properti biasa, melainkan masalah desain. Nanti kita bahas lebih lanjut di bagian rotasi.

Coba Thunderbit untuk ekstraksi data yang lebih mudah

Mengapa Menggunakan Proxy dengan HttpClient di C#

Developer memakai proxy untuk HttpClient karena beberapa alasan yang cukup umum, dan jenis proxy yang tepat bergantung pada kebutuhan masing-masing.

• Menghindari blokir IP dan rate limit: Sangat penting untuk web scraping, lead generation, atau pemantauan harga dalam skala besar. Satu IP yang terlalu agresif akan cepat diblokir.
• Melewati pembatasan wilayah: Akses API atau konten yang hanya tersedia di region tertentu dengan merutekan trafik lewat proxy di negara yang relevan.
• Menyamarkan IP asal: Menambah lapisan privasi saat melakukan pengumpulan data sensitif atau riset kompetitor.
• Kebutuhan korporat atau kepatuhan: Banyak perusahaan mewajibkan trafik keluar lewat gateway terpusat untuk logging dan pengawasan.
• Testing dan QA: Mensimulasikan request dari lokasi atau kondisi jaringan yang berbeda tanpa perlu men-deploy infrastruktur fisik di wilayah tersebut.

Use Case	Pilihan Proxy yang Umum	Alasan Cocok
Web scraping skala besar	Rotating residential proxy	Variasi IP lebih banyak, lebih sulit diklasifikasikan sistem anti-bot
Pemantauan harga e-commerce	Residential atau datacenter geo-targeted	Cek harga dan stok berdasarkan region
Akses API lewat gateway tetap	Datacenter proxy atau corporate proxy	IP bisa di-allowlist secara konsisten, biaya lebih rendah
Kepatuhan enterprise	System proxy, PAC proxy, authenticated company proxy	Logging terpusat dan kontrol trafik keluar
QA dan pengujian lokalitas	Pool proxy spesifik negara	Mensimulasikan akses pengguna nyata dari region target

Penggunaan proxy juga biasanya berkembang lewat tahapan yang cukup bisa ditebak. Awalnya Anda pakai satu proxy statis untuk memastikan routing bekerja. Scraper produksi lalu pindah ke pool, memetakan request ke proxy berdasarkan domain target, geografi, atau tingkat kegagalan. Tim yang sudah matang sering beralih ke managed proxy gateway, di mana rotasi, retry, dan session affinity ditangani di balik satu endpoint.

Rotasi proxy bukan solusi ajaib. Kalau target memblokir perilaku yang mencurigakan, pergantian IP hanya membantu jika cadence request, header, cookie, dan fingerprinting TLS juga dikelola dengan cermat.

Versi .NET Mana yang Mendukung Apa: Matriks Kompatibilitas Singkat

Menyalin snippet proxy dari blog ke target framework yang salah adalah sumber kegagalan diam-diam yang besar. Batas paling penting adalah perbedaan antara .NET Framework 4.x dan .NET modern (.NET 6+). Berikut dukungannya:

Kemampuan	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
WebProxy + HttpClientHandler	Ya	Ya	Ya	Ya
SOCKS5 lewat WebProxy("socks5://...")	Tidak	Ya (ditambahkan di .NET 6)	Ya	Ya
SocketsHttpHandler (handler default)	Tidak	Ya	Ya	Ya
HttpClient.DefaultProxy statis	Tidak	Ya	Ya	Ya
PooledConnectionLifetime	Tidak	Ya	Ya	Ya

Kalau Anda menargetkan .NET Framework 4.x, tetap gunakan proxy HTTP/HTTPS dengan HttpClientHandler dan WebProxy. SOCKS5 dan kontrol pooling modern butuh .NET 6 atau lebih baru.

Ada satu perilaku halus yang perlu diperhatikan: HttpClient.DefaultProxy adalah properti statis di .NET modern. Kalau diatur di startup code yang dipakai bersama atau diwarisi dari environment variable seperti HTTPS_PROXY atau HTTP_PROXY, setiap instance HttpClient akan memakainya kecuali Anda menimpanya secara eksplisit di handler. Di deployment berbasis container, ini sering jadi sumber kebingungan: “Kenapa client saya pakai proxy yang sama sekali tidak saya konfigurasi?”

Langkah 1: Buat Proyek Console C# Baru

Buka terminal lalu buat proyek baru:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Cek versi SDK dengan dotnet --version. Contoh di panduan ini menargetkan .NET 6+ supaya semua fitur tercakup. Kalau Anda butuh SDK LTS terbaru, unduh dari halaman download Microsoft.

Buka Program.cs di editor Anda. Di sanalah semua contoh akan dijalankan.

Langkah 2: Buat HTTP Request Dasar (Tanpa Proxy)

Sebelum mengonfigurasi proxy, pastikan dulu IP keluar asli Anda. Dengan begitu, setelah proxy aktif, Anda bisa memastikan IP-nya benar-benar berubah.

using System.Net.Http;

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

Jalankan. Anda akan melihat alamat IP publik saat ini, misalnya:

Direct IP: 203.0.113.10

Simpan nilainya di kepala. Setelah langkah berikutnya, nilainya harus berbeda.

Langkah 3: Konfigurasikan WebProxy dengan HttpClientHandler

Pola standar memakai tiga objek: WebProxy, handler, dan 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}");

Ganti proxy.example.com:8080 dengan endpoint proxy Anda yang sebenarnya. Kalau semuanya terhubung dengan benar, IP yang keluar sekarang harus cocok dengan exit IP proxy, bukan IP asli Anda.

Properti penting yang perlu dipahami:

• Proxy — instance IWebProxy yang dipakai handler untuk routing.
• UseProxy = true — memberi tahu handler agar benar-benar memakai proxy yang dikonfigurasi. (Kelihatannya jelas, tapi lupa mengaktifkannya adalah jebakan debugging yang sangat umum.)
• BypassProxyOnLocal = false — mencegah handler melewati proxy untuk tujuan yang dianggap “lokal.”
• UseDefaultCredentials — mengontrol apakah handler mengirim kredensial default Windows. Ini bukan username/password proxy.

Langkah 4: Tambahkan Autentikasi Proxy dengan NetworkCredential

Sebagian besar penyedia proxy berbayar membutuhkan kredensial. Pola yang benar adalah menaruh kredensial di objek WebProxy itu sendiri:

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

Banyak provider memberi format URL seperti http://username:password@host:port. Untuk kode .NET, lebih baik gunakan NetworkCredential daripada menyisipkan kredensial langsung di string URI. Ini menghindari masalah escape pada karakter khusus di password dan membuat batas antara URI dan kredensial jadi lebih jelas.

Kesalahan autentikasi yang paling umum—dan kenapa itu memicu error 407—akan saya bahas di bagian tersendiri di bawah.

Langkah 5: Ekspor atau Gunakan Data Respons

Untuk kebutuhan yang lebih dari sekadar cek IP cepat, tangani respons dengan benar:

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

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"Request failed: {(int)response.StatusCode} {response.ReasonPhrase}");
    return;
}

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

Untuk workflow scraping, request lewat proxy hanya menangani lapisan transport. Anda tetap butuh parsing, normalisasi, deduplikasi, retry, dan ekspor ke Excel, Google Sheets, database, atau tujuan lainnya. Alat seperti Thunderbit bisa mengotomatisasi proses ekstraksi dan ekspor—ekstensi Chrome miliknya menangani ekstraksi data terstruktur dan ekspor gratis ke Google Sheets, Excel, Airtable, atau Notion tanpa perlu menulis kode parsing.

Ekspor data hasil scrape ke Excel, Sheets, Airtable, atau Notion Get Started Free

Kredensial Proxy vs. Kredensial Server: Kesalahan yang Menyebabkan Error 407

Saya sering melihat kesalahan ini di thread Stack Overflow, posting Microsoft Q&A, dan—jujur saja—di kode saya sendiri.

Perbedaannya sederhana, tapi gampang banget tertukar:

• Kredensial proxy mengautentikasi Anda ke server proxy itu sendiri.
• Kredensial server mengautentikasi Anda ke server tujuan.

Di HttpClientHandler, keduanya berada di properti yang berbeda. Menaruh kredensial di tempat yang salah adalah penyebab utama error 407 Proxy Authentication Required.

// ❌ SALAH — menetapkan kredensial untuk server tujuan, bukan proxy
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ BENAR — menetapkan kredensial pada objek proxy itu sendiri
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials menargetkan server tujuan. WebProxy.Credentials menargetkan proxy. Kalau proxy mengembalikan 407, berarti kredensial Anda harus ditempatkan di proxy.

Satu jebakan lagi: HttpClientHandler.PreAuthenticate mengatur perilaku pre-authentication untuk autentikasi server tujuan. Itu bukan pengatur header Proxy-Authorization. Jadi jangan dipakai sebagai solusi untuk 407.

Cara Melakukan Rotasi Proxy dengan HttpClient di C#

Developer sering bertanya ini di forum. Jawaban pertamanya memang agak mengecewakan: Anda tidak bisa mengubah proxy pada instance HttpClient yang sedang aktif. Proxy berada di handler. Handler ditetapkan saat konstruksi. HttpClient tidak menyediakan properti Proxy yang bisa diubah.

Solusi naif—new HttpClient(new HttpClientHandler { Proxy = ... }) untuk setiap request—justru memunculkan masalah lain. Microsoft secara eksplisit memperingatkan bahwa membuat dan membuang client per request bisa menghabiskan port TCP yang tersedia karena port tidak langsung dilepas setelah koneksi ditutup.

Jadi, berikut tiga pola produksi yang benar-benar bekerja.

Opsi 1: Named Clients lewat IHttpClientFactory

Kalau kumpulan proxy sudah diketahui saat startup, named clients adalah opsi dengan kompleksitas paling rendah. Setiap named client punya konfigurasi handler sendiri, dan aplikasi memilihnya berdasarkan nama saat runtime.

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

// Saat request:
var client = httpClientFactory.CreateClient("proxy-us");

Factory akan mengelola lifetime handler dan mencegah pola anti-pattern client per request.

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

Untuk client jangka panjang di belakang proxy gateway yang mengganti exit IP pada koneksi baru, PooledConnectionLifetime memaksa koneksi dibuat ulang setelah durasi tertentu.

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

Ini bukan sihir yang otomatis mengganti objek Proxy per request. Pendekatan ini paling cocok untuk proxy gateway yang menetapkan exit IP berbeda di setiap koneksi TCP baru, atau pool proxy berbasis DNS yang hostnamenya bisa mengarah ke endpoint berbeda dari waktu ke waktu.

Opsi 3: DelegatingHandler Kustom untuk Pemilihan Proxy yang Lebih Lanjut

Kalau pemilihan proxy bergantung pada URL request, payload, atau konteks runtime, routing handler kustom bisa memeriksa setiap request lalu meneruskannya ke pipeline inner handler yang sesuai.

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

Ini desain tingkat lanjut. Thread safety, disposal, reuse handler, perilaku retry, dan logging semuanya jadi tanggung jawab Anda. Saya sarankan hanya jika dua opsi pertama memang tidak cocok.

Membandingkan Tiga Pendekatan

Pendekatan	Kompleksitas	Versi .NET	Thread Safety	Overhead
Named clients (IHttpClientFactory)	Rendah	.NET Core 2.1+	Tinggi (konfigurasi immutable)	Rendah
SocketsHttpHandler + PooledConnectionLifetime	Menengah	.NET 6+	Tinggi	Rendah
DelegatingHandler kustom	Tinggi	Apa saja	Bergantung implementasi	Menengah

Untuk sebagian besar tim, named clients adalah titik awal terbaik. Pindah ke PooledConnectionLifetime untuk rotating gateway yang stabil, dan pakai routing kustom hanya saat pilihan proxy bergantung pada metadata level request.

Memilih Protokol Proxy yang Tepat: HTTP, HTTPS, dan SOCKS5

Tidak semua proxy berbicara dengan bahasa yang sama, dan salah memilih skema protokol bisa menghasilkan error yang membingungkan.

HTTP proxy: Memahami request HTTP. Untuk target HTTP biasa, proxy bisa meneruskan request langsung. Untuk target HTTPS, client mengirim request CONNECT untuk membuat tunnel, lalu TLS dinegosiasikan lewat tunnel itu ke tujuan. Ini model yang paling umum.

HTTPS-terminating proxy: Proxy menampilkan sertifikat TLS miliknya sendiri lalu mengenkripsi ulang trafik ke upstream. Umum di sistem inspeksi enterprise dan sebagian managed scraping API. Ini bisa memicu error validasi sertifikat kalau client tidak mempercayai rantai sertifikat proxy.

SOCKS5 proxy: Tunnel TCP di lapisan transport yang bisa dipakai untuk semua trafik TCP, bukan hanya HTTP. Banyak dipakai oleh penyedia residential proxy. Didukung secara native di .NET 6+.

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

Catatan tentang Validasi Sertifikat SSL

Saat memakai HTTPS-terminating proxy, Anda mungkin melihat error RemoteCertificateNameMismatch. ServerCertificateCustomValidationCallback bisa dipakai untuk menyesuaikan validasi:

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

Gunakan ini hanya di pengembangan lokal atau dengan proxy intercept TLS yang memang Anda percayai dan setujui. Mengembalikan true secara buta akan mematikan pemeriksaan keamanan yang penting dan membuka risiko man-in-the-middle attack. Di produksi dengan CONNECT proxy standar atau SOCKS proxy, biarkan validasi SSL tetap aktif.

Troubleshooting Error Proxy yang Umum di C# HttpClient

Tabel ini memetakan gejala yang terlihat ke penyebab yang paling mungkin dan perbaikan pertama yang layak dicoba. Saya sarankan bagian ini di-bookmark—karena inilah error yang paling sering muncul di thread Stack Overflow dan forum developer.

Error / Gejala	Penyebab Umum	Perbaikan
407 Proxy Authentication Required	Kredensial dipasang di handler.Credentials alih-alih handler.Proxy.Credentials; format username salah; password dengan karakter khusus dimasukkan langsung ke URL	Gunakan WebProxy.Credentials = new NetworkCredential(...); hindari menyisipkan kredensial ke URI; verifikasi format username dari provider
TaskCanceledException / Timeout	Endpoint proxy lambat, tidak bisa diakses, terlalu sibuk, atau diblokir firewall; timeout default 100 detik terlalu pendek	Uji proxy dengan curl; naikkan HttpClient.Timeout hanya setelah memastikan endpoint bekerja; tambahkan retry dan health check proxy
SocketException / Socket exhaustion	Membuat dan membuang HttpClient atau handler setiap request	Gunakan IHttpClientFactory, singleton client, atau SocketsHttpHandler dengan kontrol pooling
SSL RemoteCertificateNameMismatch	Intersepsi HTTPS oleh proxy korporat atau managed proxy	Pasang/trust CA proxy jika memang tepat; gunakan validasi kustom hanya di dev terkontrol atau skenario MITM yang disetujui
302 Redirect loop	Halaman captive portal proxy/VPN atau allowlist block yang terus me-redirect	Uji koneksi langsung; periksa header Location; cek allowlist dan portal autentikasi proxy
HttpRequestException / Tidak ada koneksi dengan URL SOCKS	Kode SOCKS dijalankan di .NET Framework atau .NET yang lebih lama; skema atau port salah	Gunakan .NET 6+ untuk dukungan SOCKS native; verifikasi socks5://host:port; uji dengan dokumentasi provider
Proxy seolah diabaikan	UseProxy = false; tujuan dianggap lokal lalu dibypass; environment variable NO_PROXY; konfigurasi handler berbeda dari yang diharapkan	Set UseProxy = true; periksa HttpClient.DefaultProxy; kosongkan atau override environment variable; set BypassProxyOnLocal = false

Alur Debugging Cepat

1. Apakah request berhasil? → Ya: bandingkan output api.ipify.org dengan IP proxy yang diharapkan.
2. Tidak, ada status HTTP? → 407: perbaiki kredensial proxy. 403/429: target memblokir atau me-rate-limit proxy. Loop 3xx: proxy/gateway korporat mungkin melakukan redirect.
3. Tidak ada status code, hanya exception? → Timeout: uji konektivitas proxy. Socket/certificate exception: cek pooling, protokol, TLS, dan versi .NET.

Perintah awal yang berguna untuk memvalidasi proxy di luar .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/

Kalau curl berhasil tapi kode C# Anda tidak, biasanya perbedaannya ada di skema autentikasi, trust store TLS, environment variable, atau escaping kredensial. Samakan URL proxy, skema, dan autentikasi seperti di curl, lalu pindahkan kredensial ke NetworkCredential.

Kapan Sebaiknya Tidak Mengelola Proxy Sendiri: Alternatif No-Code

Banyak developer yang mencari “HttpClient proxy C#” sebenarnya bukan ingin belajar teori proxy—mereka ingin scraper tetap jalan. Penting untuk jujur soal kapan kode proxy C# kustom adalah pilihan yang tepat dan kapan tidak.

Bangun scraper C# kustom dengan rotasi proxy jika:

• Anda butuh kontrol penuh atas logika request, cookie, header, retry, dan parsing
• Scraper terintegrasi ke dalam codebase .NET atau service internal yang sudah ada
• Persyaratan compliance atau security mengharuskan Anda punya infrastruktur end-to-end

Gunakan alat no-code seperti Thunderbit jika:

• Tujuannya adalah ekstraksi data terstruktur dari website, bukan infrastruktur HTTP
• Anda tidak ingin memelihara pool proxy, menangani CAPTCHA, atau debugging socket exhaustion
• Tim butuh data ke Excel, Google Sheets, Airtable, atau Notion tanpa menulis kode parsing

Ekstensi Chrome Thunderbit menangani rotasi proxy dan anti-bot secara otomatis lewat opsi cloud scraping. API-nya memungkinkan developer mendefinisikan skema JSON dan mendapatkan data terstruktur tanpa harus mengelola HttpClient atau WebProxy. Untuk tim yang melakukan web scraping untuk perbandingan harga atau ekstraksi lead, perbedaan waktu setup-nya sangat besar.

Skenario	C# Kustom + Proxy	Thunderbit
Kontrol penuh atas logika request	Ya	Tidak (kontrol di level API)
Perlu manajemen proxy	Ya	Tidak (ditangani otomatis)
Penanganan anti-bot / CAPTCHA	Manual atau pihak ketiga	Built-in
Waktu setup	Jam hingga hari	Menit
Paling cocok untuk	Codebase .NET yang sudah ada, pipeline kustom	Ekstraksi data cepat, tim non-teknis, ekspor spreadsheet

Ini bukan ajakan “jangan pernah pakai HttpClient.” Kalau Anda membangun service .NET produksi, Anda memang harus paham konfigurasi proxy. Tapi kalau Anda sudah menghabiskan berjam-jam memperbaiki error 407 demi pekerjaan pengumpulan data sekali jalan, ada opsi yang jauh lebih sederhana—dan tidak ada alasan untuk malu memakainya. Anda bisa lihat harga Thunderbit atau menonton channel YouTube untuk panduan langkah demi langkah.

Poin-Poin Utama

Pola intinya tetap sama: WebProxy → handler → HttpClient. Sisanya soal menghindari kesalahan operasional yang biasanya muncul di produksi.

• Kredensial harus ditempatkan di proxy, bukan di handler. Snippet berdampingan di bagian 407 adalah hal paling penting untuk diingat.
• Jangan membuat HttpClient baru untuk setiap request atau setiap proxy. Gunakan IHttpClientFactory untuk named clients, SocketsHttpHandler dengan PooledConnectionLifetime untuk rotating gateway, atau custom routing handler untuk skenario lanjutan.
• Periksa versi .NET Anda sebelum menyalin kode SOCKS5 atau SocketsHttpHandler. Matriks kompatibilitas di atas akan menyelamatkan Anda dari kegagalan diam-diam.
• Uji proxy di luar .NET terlebih dahulu. Perintah curl singkat bisa menghapus banyak kemungkinan penyebab masalah.
• Untuk ekstraksi data terstruktur tanpa repot mengelola proxy, alat seperti Thunderbit menangani lapisan transport sehingga Anda bisa fokus ke datanya.

Lain kali Anda ketemu 407 atau TaskCanceledException, mulai dulu dari tabel troubleshooting di atas.

FAQ

Bisakah saya mengubah proxy pada instance HttpClient yang sudah ada?

Tidak. Proxy terikat pada handler, dan handler ditetapkan saat konstruksi. HttpClient tidak menyediakan properti Proxy yang bisa diubah. Kalau ingin proxy berbeda, buat handler dan client terpisah, lalu kelola dengan named clients dari IHttpClientFactory atau kumpulan client yang sudah dikonfigurasi sebelumnya.

Apakah HttpClient memakai system proxy secara default?

Ya. Di .NET modern, kalau Anda tidak mengatur handler secara eksplisit, HttpClient akan mewarisi pengaturan proxy default sistem—termasuk environment variable seperti HTTPS_PROXY dan HTTP_PROXY melalui HttpClient.DefaultProxy. Untuk menonaktifkannya, set UseProxy = false secara eksplisit pada handler.

Bagaimana cara memakai proxy SOCKS5 dengan HttpClient di C#?

Gunakan new WebProxy("socks5://host:port") bersama SocketsHttpHandler. Dukungan native proxy SOCKS membutuhkan .NET 6 atau lebih baru. Di .NET Framework 4.x, SOCKS5 tidak didukung secara native—Anda perlu library pihak ketiga.

Mengapa saya terus mendapat 407 Proxy Authentication Required?

Kemungkinan besar Anda menaruh kredensial di handler.Credentials (yang menargetkan server tujuan) alih-alih handler.Proxy.Credentials (yang menargetkan proxy). Lihat bagian “Kredensial Proxy vs. Kredensial Server” di atas untuk pola yang benar.

Apakah aman menonaktifkan validasi sertifikat SSL saat memakai proxy?

Hanya saat pengembangan lokal atau ketika Anda sepenuhnya mempercayai penyedia proxy (misalnya managed scraping API dalam mode HTTPS proxy). Di produksi dengan CONNECT proxy standar atau SOCKS proxy, tetap aktifkan validasi SSL untuk mencegah man-in-the-middle attack.

Coba Thunderbit untuk web scraping tanpa repot Get Started Free

Pelajari Lebih Lanjut

• Alat Web Scraping Otomatis Terbaik
• Cara Membuat Web Scraper
• Layanan Web Scraping Terbaik
• Bahasa Terbaik untuk Web Scraping
• Web Scraping Tanpa Kena Blokir