Berapa Banyak Proksi yang Sebenarnya Anda Butuhkan?

Kami menjual proxy di Geonode, sehingga artikel ini pada dasarnya berargumen bahwa Anda sebaiknya membeli dalam jumlah yang lebih sedikit daripada yang semula Anda rencanakan. Itulah posisi kami yang sebenarnya: jumlah proxy yang berlebihan tidak membuat Anda lebih aman, dan pada sistem penetapan harga berbasis lalu lintas, hal itu bahkan tidak membuat biayanya lebih mahal — yang berarti orang-orang memiliki model pemikiran yang salah tanpa pernah melihat tagihan yang akan mengoreksinya. Angka yang penting adalah jumlah koneksi bersamaan terhadap satu target, dan hal ini dapat diukur dalam waktu satu sore. Jika Anda hanya mengambil satu hal dari artikel ini, jadikanlah pengukuran yang dijelaskan di bagian berikutnya, bukan angka apa pun yang bisa kami berikan kepada Anda.

Satu-Satunya Metode yang Berhasil

Tiga langkah, semuanya berdasarkan pengalaman.

Langkah pertama: tentukan batas atas per alamat. Jalankan beban kerja aktual Anda dari satu alamat, tingkatkan laju permintaan secara bertahap, dan temukan titik di mana target mulai menunjukkan tanda-tanda keterbatasan — kode status 429, permintaan verifikasi, respons yang lebih lambat, atau konten yang terganggu. Ambang batas tersebut adalah kapasitas per alamat Anda untuk target tersebut, dan itu adalah satu-satunya angka dalam perhitungan ini yang bukan sekadar perkiraan.

Langkah kedua: tentukan throughput yang Anda butuhkan. Berapa banyak permintaan, dalam jangka waktu berapa lama. Jujurlah mengenai bagian "dalam jangka waktu berapa lama", karena hal itu berperan lebih besar dalam persamaan ini daripada hal lainnya.

Langkah ketiga: bagi. Throughput yang dibutuhkan dibagi dengan kapasitas per alamat akan menghasilkan jumlah alamat bersamaan yang diperlukan. Tambahkan margin untuk percobaan ulang dan variabilitas — 50% sudah cukup besar, dan jika Anda membutuhkan lebih dari itu, kemungkinan besar pengukuran Anda pada langkah pertama terlalu optimis.

Itulah keseluruhan metodenya. Alasan mengapa ini bukan saran standar adalah karena metode ini mengharuskan Anda menjalankan pengujian sebelum membeli, dan vendor tidak memiliki insentif untuk menyarankannya.

Catatan mengenai langkah pertama: ukur jumlah respons berguna yang berhasil per detik, bukan jumlah permintaan yang dicoba. Sebuah pool yang mengembalikan kode status 200 dengan konten yang dihilangkan tidak berfungsi dengan baik, namun metrik tingkat keberhasilan agregat akan melaporkannya sebagai sehat. Periksa adanya penanda yang diketahui stabil dalam respons dan hitung hanya respons yang mengandung penanda tersebut.

Melakukan Pengukuran dengan Benar

Seluruh metode ini bergantung pada langkah pertama, jadi penting untuk menjelaskan secara rinci cara melakukannya agar tidak menyesatkan diri sendiri.

Lakukan pengujian terhadap target sebenarnya, bukan titik akhir pengujian. Pengujian terhadap layanan yang hanya menampilkan alamat IP Anda hanya menunjukkan bahwa proxy Anda berfungsi, tetapi tidak memberi informasi apa pun tentang bagaimana situs yang Anda tuju akan merespons Anda. Setiap target memiliki batas toleransi masing-masing, dan angka yang Anda butuhkan bergantung pada target tersebut.

Tingkatkan secara bertahap dan catat semuanya. Mulailah jauh di bawah batas yang Anda perkirakan, lalu tingkatkan secara bertahap, pertahankan setiap laju cukup lama untuk melihat pola — setidaknya beberapa menit. Catat laju, kode status, ukuran respons, dan waktu aktual untuk setiap langkah:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Perhatikan ukuran respons sama cermatnya dengan kode status. Bentuk penolakan yang paling umum bukanlah kode 429; melainkan kode 200 yang disertai halaman berukuran lebih kecil. Penurunan ukuran respons rata-rata pada kecepatan tertentu menandakan bahwa target mulai menyajikan data yang lebih ringkas, dan hal ini tidak akan terlihat jika Anda hanya menghitung kode status.

Jalankan pengujian ini pada waktu yang berbeda sepanjang hari. Toleransi seringkali lebih rendah selama jam-jam sibuk situs, dan batas yang diukur pada pukul 03.00 dini hari tidak akan berlaku pada tengah hari. Gunakan angka terburuk sebagai acuan.

Ulangi pengujian dengan alamat kedua. Jika satu alamat mencapai batas pada dua permintaan per detik dan alamat kedua mencapai batas yang sama pada waktu yang sama, batas tersebut bukan per alamat — melainkan terkait dengan subnet Anda, pola permintaan Anda, atau faktor lain yang tidak dapat diatasi dengan menambah alamat. Ini adalah hasil negatif yang penting dan memerlukan satu kali pengujian tambahan untuk mendapatkannya.

Kemudian berhentilah sebelum mencapai batas atas, bukan tepat di batas tersebut. Beroperasi pada laju maksimum yang dapat ditoleransi oleh target berarti setiap fluktuasi biasa akan mendorong Anda melampaui batas tersebut. Menentukan ukuran dari 60–70% batas atas yang diukur akan memberi Anda pekerjaan yang diselesaikan dengan andal, bukan yang hanya diselesaikan saat kondisi sedang baik.

Contoh Penerapan: Pemantauan Harga Harian

Beban kerja yang paling umum, dan yang jawabannya paling mengejutkan orang.

Persyaratan: 50.000 halaman produk diperiksa sekali sehari.

Batas atas yang diukur: target tersebut dapat menoleransi kira-kira satu permintaan setiap dua detik dari satu alamat sebelum pembatasan laju — katakanlah 1.800 permintaan per jam.

Dibagi selama 24 jam: 50.000 ÷ 24 ≈ 2.100 permintaan per jam.

Alamat yang dibutuhkan: 2.100 ÷ 1.800 ≈ 1,2. Dibulatkan ke atas dan ditambah margin: dua hingga empat alamat.

Dua alamat. Untuk lima puluh ribu halaman sehari, dibandingkan dengan kumpulan alamat yang jumlahnya jutaan.

Sekarang ubah satu asumsi. Misalkan pekerjaan harus selesai dalam rentang waktu dua jam, bukan tersebar sepanjang hari:

Persyaratan: 50.000 halaman dalam 2 jam = 25.000 per jam. Alamat yang dibutuhkan: 25.000 ÷ 1.800 ≈ 14, ditambah margin: sekitar 20.

Volume sama, target sama, alamat sepuluh kali lipat — karena keputusan penjadwalan, bukan karena kebutuhan pengumpulan data.

Itulah wawasan paling berguna dalam artikel ini. Jendela waktu yang Anda berikan pada diri sendiri adalah variabel yang paling menentukan. Sebelum membeli lebih banyak alamat, tanyakan apakah pekerjaan tersebut benar-benar perlu diselesaikan dengan cepat, dan seberapa besar nilai kecepatan tersebut. Seringkali nilainya sama sekali tidak ada, karena data tersebut akan digunakan keesokan paginya.

Contoh Penerapan: Pemeriksaan Geografis

Bentuknya benar-benar berbeda, dan perhitungannya pun berjalan sebaliknya.

Persyaratan: memeriksa harga dan ketersediaan regional di 30 pasar, empat kali sehari, dengan 50 halaman per pasar.

Volume: 30 × 4 × 50 = 6.000 permintaan per hari. Sangat mudah.

Alamat yang dibutuhkan untuk throughput: pada dasarnya satu. Enam ribu permintaan yang tersebar sepanjang hari berarti satu permintaan setiap empat belas detik.

Alamat yang dibutuhkan untuk cakupan: setidaknya satu titik keluar yang berfungsi di masing-masing dari 30 negara, pada saat Anda membutuhkannya.

Di sini, kendalanya sama sekali bukan volume, melainkan kehadiran. Yang seharusnya Anda evaluasi adalah apakah penyedia tersebut benar-benar memiliki cakupan yang andal di pasar-pasar spesifik yang Anda butuhkan, pada waktu-waktu Anda beroperasi — bukan berapa banyak alamat yang terdapat dalam kumpulan tersebut. Sebuah kumpulan sebesar sepuluh juta dengan cakupan yang minim di tiga pasar Anda lebih buruk daripada kumpulan sebesar sepuluh ribu yang mencakup ketiga puluh pasar tersebut.

Inilah mengapa “berapa banyak yang saya butuhkan” adalah pertanyaan yang salah untuk pekerjaan berbasis geografis, sedangkan “di mana Anda dapat menjangkau dengan andal, dan apakah saya dapat mengujinya” adalah pertanyaan yang tepat.

Contoh Soal: Pekerjaan Berbasis Sesi

Kasus di mana konkurensi dan identitas merupakan hal yang sama.

Persyaratan: mengoperasikan 10 sesi yang telah diautentikasi secara paralel, masing-masing menjalankan urutan bertahap.

Alamat yang dibutuhkan: 10, dan alamat-alamat tersebut harus bersifat sticky — satu alamat dipertahankan selama durasi setiap sesi.

Volume tidak relevan di sini. Yang penting adalah setiap sesi memiliki identitas yang konsisten: alamat yang sama sepanjang sesi, dengan pengaturan wilayah dan zona waktu yang sesuai. Sesi yang permintaannya berasal dari empat negara bukanlah sesi, melainkan pola.

Kesalahan yang harus dihindari adalah menggunakan titik akhir (endpoint) yang berganti-ganti per permintaan untuk hal ini, yang merupakan pengaturan default pada sebagian besar gateway. Permintaan berhasil, status sesi hilang, dan gejalanya tampak seperti bug aplikasi selama waktu yang dibutuhkan seseorang untuk memeriksa alamat keluar.

Perhatikan juga bahwa sepuluh sesi bersamaan tidak berarti sepuluh alamat selamanya — artinya sepuluh sekaligus. Beban kerja yang menjalankan 200 sesi secara berurutan sepanjang hari tetap hanya membutuhkan sepuluh alamat tetap, yang digunakan kembali.

Mengapa Lebih Banyak Bukan Berarti Lebih Aman

Asumsi di balik sebagian besar pembelian dalam jumlah berlebihan ini, dan asumsi tersebut keliru dalam tiga hal spesifik.

Pemblokiran dilakukan berdasarkan subnet, bukan berdasarkan alamat. Situs-situs umumnya melakukan pemblokiran pada tingkat granularitas /24. Lima puluh alamat dalam satu blok berperilaku seperti satu alamat ketika blok tersebut diblokir, sehingga kumpulan alamat yang besar dengan distribusi yang buruk bukanlah kumpulan alamat yang besar dalam hal yang penting. Distribusi lebih penting daripada jumlah, dan kami telah membahas mekanismenya dalam apa itu ID subnet.

Laju adalah sinyalnya, bukan identitas. Jika permintaan Anda terlihat otomatis berdasarkan waktu, header, atau sidik jari TLS, menyebarkannya ke lebih banyak alamat hanya akan menyebar sinyal tersebut tanpa menghilangkannya. Anda justru akan menandai lebih banyak alamat daripada lebih sedikit.

Alamat yang tidak digunakan akan menjadi usang. Dalam kumpulan yang berputar, alamat yang belum Anda gunakan tidak memiliki hubungan apa pun dengan target, baik atau buruk. Menyimpan "kapasitas cadangan" bukanlah menimbun apa pun.

Ada satu alasan yang sah untuk menyimpan lebih banyak alamat daripada yang dibutuhkan oleh throughput: pergantian. Jika target menandai alamat seiring waktu, Anda memerlukan pengganti untuk digilir. Itu adalah kebutuhan nyata, dan ukurannya ditentukan oleh tingkat penandaan yang diamati, bukan berdasarkan intuisi — ukur berapa banyak alamat yang ditandai per hari dan simpan cadangan untuk beberapa hari.

Apa yang Sebenarnya Anda Beli

Perlu dijelaskan dengan jelas, karena jawabannya berbeda-beda tergantung model penetapan harga dan hal ini bahkan mengubah makna pertanyaan itu sendiri.

Pada sistem penetapan harga per gigabyte, yang merupakan cara penjualan lalu lintas data untuk pengguna rumahan dan seringkali untuk pusat data, Anda sama sekali tidak membeli alamat. Anda membeli data, dan jumlah alamat merupakan bagian dari kumpulan (pool), bukan dari paket Anda. Bertanya “berapa banyak proxy yang saya butuhkan” dalam konteks ini merupakan kesalahan kategori — pertanyaan sebenarnya adalah seberapa banyak lalu lintas yang akan Anda alirkan dan apakah kumpulan tersebut memiliki jangkauan di lokasi yang Anda butuhkan. Tarif lalu lintas perumahan kami mulai dari $0,79/GB dan pusat data mulai dari $0,14/GB, diperiksa pada September 2026 berdasarkan halaman harga.

Mengenai harga per-IP, yang merupakan cara penjualan produk ISP dan banyak produk pusat data, jumlah alamat IP yang Anda bayar secara harfiah menentukan biaya, dan perhitungan ini merupakan pos anggaran. Tarif kami adalah $1,25 per IP. Di sini, perhitungan di atas berkaitan langsung dengan biaya, dan meluangkan waktu dua puluh menit untuk menghitungnya dengan benar sangatlah sepadan.

Model mana yang cocok untuk Anda bergantung pada pola beban kerja Anda, bukan pada tarif utama, dan keduanya tidak dapat dibandingkan. Beban kerja yang membutuhkan banyak alamat untuk waktu singkat lebih menguntungkan dengan harga berbasis lalu lintas; sedangkan yang membutuhkan sedikit alamat sangat menguntungkan dengan harga per-IP. Kami telah membahas perhitungannya secara mendetail dalam panduan harga proxy.

Pedoman Umum, Beserta Batasannya

Jika Anda membutuhkan titik awal sebelum melakukan pengukuran, pedoman ini dapat dipertanggungjawabkan. Anggaplah ini sebagai perkiraan awal yang dapat diganti, bukan sebagai jawaban akhir.

Dua angka yang perlu diingat. Hampir tidak ada beban kerja yang membutuhkan lebih dari beberapa lusin alamat bersamaan, dan yang benar-benar membutuhkannya adalah yang bersifat geografis (banyak lokasi, volume rendah masing-masing) atau yang memiliki tenggat waktu yang ditetapkan sendiri. Dan jumlah yang paling sering perlu diubah bukanlah jumlah alamat, melainkan jadwalnya.

Tanda-tanda Anda Salah Menentukan Angka

Terlalu sedikit terlihat seperti: angka 429 yang meningkat, munculnya kendala, tingkat keberhasilan menurun seiring berjalannya proses, dan pekerjaan selesai lebih lambat dari yang direncanakan. Solusinya adalah meningkatkan jumlah proses yang berjalan bersamaan atau memperpanjang jendela waktu.

Terlalu banyak terlihat seperti: tidak ada tanda-tanda apa pun. Inilah sebabnya mengapa kesalahan tersebut terus berlanjut. Pool yang terlalu besar tidak menimbulkan gejala apa pun pada penetapan harga berdasarkan lalu lintas, sehingga tidak ada yang menyadarinya. Pada penetapan harga per-IP, hal ini menghasilkan tagihan, yang setidaknya memicu pertanyaan.

Dua hal yang tampak seperti "terlalu sedikit" namun sebenarnya tidak:

Pool yang diblokir. Jika tingkat keberhasilan anjlok di semua alamat secara bersamaan, menambah alamat tidak akan membantu — ada sesuatu yang berubah di sisi target, atau pola permintaan Anda terdeteksi melalui sinyal non-alamat.

Target yang lambat. Jika respons lambat tetapi berhasil, meningkatkan koncurrency akan meningkatkan throughput hingga batas tertentu, lalu berhenti. Ukur jumlah permintaan yang berhasil diselesaikan per detik dan hentikan penambahan saat angka tersebut mencapai titik jenuh, yang akan terjadi lebih cepat dari yang diperkirakan.

Diagnosis umum: tingkatkan koncurrency secara bertahap dan perhatikan jumlah respons berguna yang berhasil diselesaikan per detik. Angka tersebut akan naik, mencapai titik jenuh, lalu turun. Titik jenuh itulah yang optimal, dan biasanya angkanya lebih kecil daripada yang diperkirakan siapa pun.

Pertanyaan Lainnya

Berapa banyak proxy yang saya butuhkan untuk web scraping?

Lebih baik hitung daripada menebak: cari tahu tingkat permintaan di mana satu alamat mulai dibatasi pada target Anda yang sebenarnya, bagi throughput yang Anda butuhkan dengan angka tersebut, lalu tambahkan margin. Sebagian besar beban kerja hanya membutuhkan satu digit atau dua digit rendah alamat yang aktif secara bersamaan, bukan ribuan.

Apakah menggunakan lebih banyak proxy membuat saya lebih kecil kemungkinannya untuk diblokir?

Hanya jika pemblokiran tersebut spesifik berdasarkan alamat. Jika permintaan Anda teridentifikasi sebagai otomatis berdasarkan waktu, komposisi header, atau sidik jari TLS, menambah alamat hanya akan menyebarkan sinyal yang sama ke lebih banyak alamat dalam pool Anda, bukan menghindarinya. Laju dan pola permintaan lebih penting daripada jumlahnya.

Berapa banyak proxy yang dibutuhkan untuk 1 juta permintaan per hari?

Tergantung sepenuhnya pada rentang waktu. Jika dibagi selama 24 jam, itu sekitar 12 permintaan per detik, yang jika dihitung satu permintaan setiap dua detik per alamat berarti sekitar 25 alamat bersamaan. Jika dikompres menjadi dua jam, angkanya menjadi dua belas kali lipat. Jadwalnya yang menjadi variabel, bukan volumenya.

Apakah saya memerlukan satu proxy per akun?

Untuk apa pun yang berbasis sesi, satu alamat tetap per sesi bersamaan — bukan per akun. Sepuluh akun yang dioperasikan secara berurutan sepanjang hari hanya membutuhkan sepuluh alamat jika kesepuluh akun tersebut aktif secara bersamaan. Perhatikan bahwa banyak platform secara eksplisit melarang pengoperasian multi-akun, jadi periksa ketentuan sebelum merancang sistem yang mengatasinya.

Apakah lebih baik memiliki lebih banyak IP atau IP yang lebih baik?

Lebih baik, artinya terdistribusi dengan baik di seluruh subnet dan sesuai dengan target. Pemblokiran umumnya terjadi pada tingkat granularitas /24, sehingga lima puluh alamat dalam satu blok berperilaku seperti satu alamat. Kumpulan alamat yang lebih kecil namun tersebar merata akan berkinerja lebih baik daripada kumpulan yang lebih besar namun terkonsentrasi.

Bagaimana cara mengetahui jika saya memiliki terlalu sedikit proxy?

Meningkatnya kode kesalahan 429, munculnya halaman tantangan, dan tingkat keberhasilan yang menurun seiring berjalannya proses. Jika tingkat keberhasilan anjlok di semua alamat sekaligus, itu adalah masalah yang berbeda — ada sesuatu yang berubah di target atau permintaan Anda terdeteksi berdasarkan sinyal non-alamat, dan menambah alamat tidak akan membantu.

Apakah jumlah proxy memengaruhi harga?

Pada sistem penetapan harga per-IP, secara langsung — jumlah alamat adalah apa yang Anda beli. Pada sistem penetapan harga per-gigabyte, sama sekali tidak, karena Anda membayar berdasarkan data dan jumlah alamat hanyalah sifat dari kumpulan proxy tersebut. Inilah mengapa kedua model tersebut tidak dapat dibandingkan berdasarkan tarif utama.

Berapa banyak proxy yang dibutuhkan untuk penargetan geografis?

Anda membutuhkan satu titik keluar yang andal per lokasi, dan volume biasanya tidak relevan. Pertanyaan yang harus diajukan kepada penyedia bukanlah berapa banyak alamat yang mereka miliki, melainkan apakah mereka memiliki jangkauan yang andal di pasar spesifik Anda, dan apakah Anda dapat mengujinya sebelum berkomitmen.

Kesimpulan

Angka yang Anda butuhkan diperoleh dari satu pengukuran dan satu pembagian: temukan di mana sebuah alamat mulai mengalami pembatasan laju pada target aktual Anda, lalu bagi kebutuhan throughput Anda dengan angka tersebut. Selebihnya hanyalah penyempurnaan.

Variabel yang paling memengaruhi hasil bukanlah volume, melainkan jendela waktu yang Anda izinkan. Lima puluh ribu halaman per hari memerlukan beberapa alamat yang tersebar selama dua puluh empat jam, sedangkan dua puluh ribu halaman hanya memerlukan dua alamat yang tersebar selama dua jam. Sebelum membeli kapasitas untuk mempercepat proses, periksa apakah ada hal yang benar-benar bergantung pada penyelesaian pekerjaan lebih cepat — seringkali tidak ada, dan optimasi termurah yang tersedia adalah kesabaran.

Dan untuk pekerjaan berbasis geografis, pertanyaannya berubah sepenuhnya. Volume tidaklah penting, kehadiranlah yang menjadi segalanya, dan evaluasi yang berguna adalah apakah penyedia layanan secara andal mencakup pasar spesifik Anda, bukan seberapa besar kumpulan alamat yang dimilikinya. Hal ini dapat diuji dalam masa percobaan, hanya membutuhkan waktu satu sore, dan akan memberi Anda informasi lebih banyak daripada angka apa pun yang ditampilkan vendor di halaman arahan — termasuk milik kami.