Pengaturan sistem OS dan ekstensi browser memang cukup untuk menghubungkan proxy secara manual sekali saja, tetapi tidak cocok untuk skrip atau parser. Di sana proxy harus dihubungkan secara terprogram, yaitu di klien HTTP, di sesi, dan di driver browser, lengkap dengan penanganan koneksi terputus serta pemeriksaan bahwa lalu lintas benar-benar keluar lewat alamat yang dituju.

Format string koneksi dengan autentikasi

Alamat proxy untuk koneksi dari kode disusun dengan skema yang seragam: protocol://login:password@host:port. Protokol menentukan mode kerja (http, https, socks5), login dan kata sandi dipisahkan titik dua sebelum simbol @, lalu diikuti host dan port. Pustaka klien HTTP dan sebagian besar driver browser menerima string ini secara utuh, tanpa perlu mengirim login dan kata sandi secara terpisah.

Kata sandi tidak boleh memuat simbol @ maupun karakter lain yang dicadangkan untuk URL tanpa persen-encoding. Jika tidak, parser akan memotong string pada karakter khusus pertama dan koneksi dikirim dengan kredensial yang salah. Login dan kata sandi yang dihasilkan otomatis sebaiknya di-encode dengan fungsi URL-encoding sebelum disisipkan.

Perbedaan mode HTTP dan SOCKS

Mode HTTP bekerja pada tingkat protokol: server memahami permintaan HTTP dan dapat membaca header. Untuk lalu lintas HTTPS, server tidak mendekripsi apa pun, melainkan meneruskan koneksi TLS terenkripsi dengan metode CONNECT. Karena itu mode HTTP sama-sama cocok untuk alamat http dan https, meskipun namanya demikian.

Mode SOCKS (hampir selalu SOCKS5) bekerja satu tingkat di bawahnya: tidak mengurai protokol aplikasi, hanya meneruskan byte antara klien dan tujuan. SOCKS5 bersifat transparan untuk HTTP dan koneksi TCP apa pun, dan berbeda dengan mode HTTP, mendukung UDP, yang penting untuk DNS dan sebagian pustaka jaringan. Resolusi nama dapat diserahkan ke server yang sama, sehingga nama host tidak keluar dalam bentuk terbuka lewat DNS lokal, hal yang krusial untuk situs yang sensitif terhadap geolokasi. Untuk scraping biasanya mode HTTP sudah cukup, sedangkan untuk utilitas jaringan dan aplikasi dengan protokol sendiri diperlukan SOCKS5.

Pengaturan di tingkat klien, sesi, dan driver browser

Alamat dapat ditetapkan pada tiga tingkat, dan ketiganya tidak dapat saling menggantikan. Pada tingkat permintaan, parameter dikirim ulang di setiap pemanggilan klien; cocok bila setiap permintaan harus lewat alamat yang berbeda, misalnya pada rotasi IP di setiap halaman. Pada tingkat sesi, alamat ditetapkan satu kali saat sesi atau connection pool dibuat, dan semua permintaan di dalamnya memakai satu jalur keluar serta koneksi keep-alive. Cara ini mengurangi biaya TLS handshake dan menjaga IP tetap konsisten selama satu skenario, yang penting untuk situs yang mencocokkan alamat antar-langkah autentikasi.

Tingkat driver browser lebih rumit: argumen peluncuran browser standar biasanya hanya menerima host dan port, tanpa login dan kata sandi di dalam string. Untuk kanal dengan autentikasi, dipakai salah satu skema berikut: ekstensi yang mencegat dialog autentikasi dan mengisikan kredensial, server lokal tanpa kata sandi yang meneruskan ke node eksternal dengan autentikasi, atau driver yang mencegat peristiwa jaringan dan menjawab permintaan dari browser. Panduan langkah demi langkah ada di artikel proxy untuk browser antidetect.

Penanganan kesalahan koneksi

Kesalahan pada node perantara berbeda dari kesalahan pada situs tujuan, dan keduanya harus dibedakan berdasarkan kode serta jenis pengecualian, bukan sekadar karena permintaan gagal. Penolakan autentikasi berarti server mengembalikan kode 407, bukan respons situs: login, kata sandi, atau string koneksi salah disusun, atau akses sudah berakhir, dan mengulang permintaan tanpa perubahan tidak ada gunanya. Timeout dan koneksi terputus berarti node tidak merespons atau memutus sesi sebelum ada jawaban; yang membantu adalah timeout yang wajar dan jumlah pengulangan terbatas dengan jeda, bukan retry seketika.

Penolakan oleh situs tujuan lewat proxy berarti situs mengembalikan 403, captcha, atau pengalihan ke halaman verifikasi. Ini bukan kesalahan koneksi, melainkan sinyal bahwa alamat sudah terpakai atau tidak memenuhi reputasi yang diminta platform, dan mengulang permintaan dengan IP yang sama tidak ada gunanya, sehingga alamat perlu diganti. Untuk membedakan alamat yang berfungsi baik dari yang bermasalah sejak awal, metrik kualitas proxy dapat membantu.

Memastikan permintaan benar-benar lewat proxy

Sebelum menjalankan skenario utama, sebaiknya akses layanan apa pun yang mengembalikan IP permintaan, lalu bandingkan dengan alamat asli klien. Satu permintaan ini menghindarkan situasi ketika koneksi tampak sudah dikonfigurasi, tetapi klien karena salah ketik justru mengakses langsung.

Hal kedua adalah header node transparan: X-Forwarded-For atau Via yang berisi alamat asli klien. Server seperti ini menerima koneksi, tetapi mengungkap IP asli, sehingga untuk tugas yang menuntut anonimitas diperlukan mode tidak transparan tanpa header tersebut. Bila alamat berganti pada setiap sesi, pemeriksaan sebaiknya dimasukkan ke dalam skenario itu sendiri; selengkapnya ada di artikel tentang rotasi IP lewat API.

Untuk driver browser, pemeriksaan lebih rumit: browser dapat melewati node yang sudah dikonfigurasi lewat WebRTC, yang membangun koneksi P2P langsung dan mengungkap IP lokal, bahkan terkadang IP publik. Jika skenario Anda sensitif terhadap kebocoran, WebRTC perlu dinonaktifkan dengan parameter peluncuran tersendiri, bukan hanya mengandalkan rute lewat server.

Pertanyaan yang Sering Diajukan

Bisakah proxy yang sama dipakai sekaligus untuk klien HTTP dan driver browser?

Secara teknis bisa, jika tipe alamat mendukung kedua mode. Namun dalam praktiknya orang membuat dua koneksi terpisah: klien dan driver memiliki logika pengulangan dan masa hidup koneksi yang berbeda, dan satu jalur keluar yang dipakai dua proses meningkatkan peluang diblokir karena pola permintaan yang sama.

Mengapa proxy berfungsi di satu klien HTTP tetapi tidak di klien lain dengan string koneksi yang sama?

Pustaka mengurai string koneksi dengan cara berbeda dan memperlakukan variabel lingkungan secara berbeda pula: satu klien membacanya otomatis, yang lain memerlukan parameter yang dikirim secara eksplisit, dan yang ketiga mengabaikan pengaturan sistem. String sebaiknya dikirim secara eksplisit, tanpa mengandalkan perilaku implisit.

Apakah koneksi ke proxy perlu ditutup manual setelah setiap permintaan?

Untuk mode sesi tidak perlu: koneksi dipakai ulang oleh pool dan ditutup saat timeout tidak aktif atau saat sesi ditutup. Penutupan eksplisit hanya perlu dilakukan bila skenario menahan koneksi lebih lama daripada tugasnya, karena jika tidak, batas sesi bersamaan pada kanal dengan penerbitan alamat per sesi akan mudah tercapai.

Proxy siap pakai dengan login dan kata sandi untuk mode HTTP dan SOCKS5 beserta dokumentasi koneksi tersedia di bagian proxy. Format permintaan dan batasan untuk integrasi terprogram ada di API proxy.