Kami menjual proxy di Geonode, jadi anggaplah informasi berikut ini sebagai saran dari pihak yang berkepentingan dan bandingkan dengan log Anda sendiri. Inilah pandangan jujur dari pihak yang berkepentingan: pengujian terhadap proxy Anda umumnya menemukan masalah yang merupakan kesalahan kami, bukan kesalahan Anda, dan pelanggan yang melakukan pengujian dengan benar adalah pelanggan yang membuka tiket dukungan yang kemudian harus kami tanggapi. Namun, kami tetap lebih suka jika Anda melakukan pengujian. Sebuah pool yang mengalami penurunan kinerja tanpa tanda-tanda peringatan dan baru terdeteksi tiga minggu kemudian oleh rekan kerja yang bertanya mengapa dasbor harga terlihat salah, jauh lebih merugikan bagi semua pihak daripada alat pemantauan yang langsung memberi peringatan pada hari pertama.
Insting kebanyakan orang tentang pengujian proxy adalah bahwa ini hanyalah langkah awal. Anda membeli akses, menempelkan kredensial ke alat penguji, tanda centang hijau muncul, dan masalah dianggap selesai hingga sesuatu secara jelas bermasalah. Model tersebut salah secara spesifik dan mahal: proxy biasanya tidak gagal dengan cara menolak berfungsi. Proxy gagal dengan tetap berfungsi sambil mengembalikan hasil yang sedikit berbeda dari yang Anda minta. Scraper Anda terus berjalan. Metrik tingkat keberhasilan Anda tetap di 99%. Data di baliknya menjadi salah.
Artikel ini merupakan pelengkap dari panduan praktis kami tentang cara menguji proxy, yang membahas perintah dan skrip. Di sini kami menjawab pertanyaan sebelumnya — mengapa perlu repot-repot, berapa sebenarnya biaya yang harus ditanggung jika tidak melakukan pengujian, dan bagaimana Anda menentukan seberapa banyak pengujian yang cukup.
Mode Kegagalan yang Tak Pernah Diperkirakan
Pikirkan apa arti "proxy rusak" bagi kode Anda. Hampir setiap klien proxy menganggapnya sebagai peristiwa di tingkat koneksi: proses handshake TCP gagal, otentikasi ditolak dengan kode status 407, terowongan CONNECT ditolak, atau terjadi timeout. Itulah kegagalan yang sudah ditangani oleh logika percobaan ulang Anda, karena kegagalan tersebut memicu pengecualian (exception) dan pengecualian mudah dikenali.
Sekarang pertimbangkan kegagalan yang tidak memicu apa pun:
- Proxy terhubung, tetapi node keluar telah dialihkan dari Manchester ke Frankfurt. Pengambilan data harga di Inggris Anda kini menjadi pengambilan data harga di Jerman. Setiap bidang diparsing dengan benar. Setiap nilainya salah.
- Situs target mulai menyajikan halaman yang dipangkas kepada kumpulan proxy Anda alih-alih memblokirnya — respons anti-bot yang umum dan rasional, karena pemblokiran lunak hanya membuang-buang anggaran pengikis tanpa memberikan informasi apa pun. Parser Anda menemukan kontainer yang diharapkan, mengekstrak tiga produk alih-alih empat puluh, dan melaporkan keberhasilan.
- Proksi telah mulai menyisipkan atau menghapus header. Permintaan Anda tetap berhasil. Situs tersebut kini mengklasifikasikan Anda secara berbeda dibandingkan minggu lalu.
- Resolusi DNS secara diam-diam telah berpindah dari proksi ke mesin Anda sendiri. Lalu lintas Anda keluar melalui proksi; permintaan DNS Anda keluar melalui ISP Anda. Anda memiliki geolokasi dari satu negara dan perilaku resolver dari negara lain, dan situs mana pun yang mengkorelasikan keduanya kini melihat ketidaksesuaian yang tidak akan pernah dihasilkan oleh pengguna asli.
- Endpoint tersebut aktif, cepat, berlokasi dengan benar, dan dibagikan dengan seseorang yang menghabiskan pagi hari untuk membanjiri situs yang Anda perhatikan. Tidak ada yang salah dengan konfigurasi Anda. Tingkat keberhasilan Anda pada target tersebut kini mencapai 40%.
Tidak ada yang menimbulkan kesalahan. Itulah inti masalahnya. Logika percobaan ulang, pemutus sirkuit, dan peringatan tingkat kesalahan semuanya dibangun berdasarkan asumsi bahwa kegagalan itu mencolok, sedangkan kegagalan yang paling penting dalam kerja proxy bersifat diam secara inheren.
Apa Saja yang Sebenarnya Rusak dan Seberapa Sering
Sebaiknya kita membedakan hal-hal yang berubah dengan sendirinya dari hal-hal yang berubah karena diubah oleh seseorang. Kedua kategori tersebut perlu diuji; namun, jadwal pengujiannya berbeda.
| Apa yang berubah | Mengapa berubah | Bagaimana Anda menyadarinya tanpa pengujian | Keterlambatan deteksi umum |
|---|
| Geolokasi IP keluar | Penyedia layanan internet (ISP) mengalokasikan ulang blok; basis data geolokasi diperbarui sesuai jadwalnya sendiri | Pemangku kepentingan menanyakan data regional yang tidak biasa | Berminggu-minggu |
| Reputasi IP pada satu target | Alamat tersebut digunakan secara agresif oleh pihak lain | Tingkat keberhasilan menurun hanya pada target tersebut | Beberapa hari hingga beberapa minggu |
| Pemblokiran lunak atau penyaringan konten | Target mengubah kebijakan anti-botnya | Jumlah baris menurun | Beberapa minggu |
| Pergeseran sidik jari header atau TLS | Anda memperbarui pustaka klien | Tingkat pemblokiran naik setelah penerapan | Hari |
| Kebocoran DNS | Perubahan konfigurasi, pengaturan default pustaka, jaringan kontainer | Biasanya tidak pernah, hingga terkorelasi dengan aktivitas Anda | Tidak terbatas |
| Kematian titik akhir yang sebenarnya | Penyedia memutar infrastruktur | Segera, terjadi kegagalan | Menit |
Baris terakhir adalah satu-satunya yang terdeteksi oleh sebagian besar konfigurasi, dan ini yang paling tidak merugikan. Inversi tersebut — kegagalan yang paling mencolok justru yang paling murah — adalah alasan mengapa pengujian memiliki reputasi intuitif yang buruk. Orang-orang mengingat bahwa pemantauan mereka mendeteksi titik akhir yang mati dan menyimpulkan bahwa pemantauan berfungsi.
Geolokasi layak mendapat perhatian khusus karena ini adalah hal yang paling dipercaya orang, padahal seharusnya paling tidak dipercaya. Pemetaan IP ke lokasi bukanlah fakta tentang internet; ini adalah basis data komersial yang menyimpulkan dari data perutean, catatan registri, dan umpan yang dipublikasikan sendiri. MaxMind, salah satu penyedia yang paling banyak digunakan, mencatat di halaman permintaan koreksi bahwa pengiriman geofeed “diimpor dan ditinjau sekali per hari kerja” dan koreksi satu kali “biasanya ditinjau dalam 1–2 hari kerja”, serta bahwa koreksi yang diterima “dimasukkan ke dalam rilis basis data berikutnya”. Umpan yang diterbitkan sendiri distandarisasi dalam RFC 8805, dan jaringan yang menerbitkannya merupakan minoritas yang patuh.
Konsekuensi praktisnya: dua pencarian geolokasi dapat secara sah memberikan hasil yang berbeda untuk IP yang sama, dan situs yang Anda scrape mungkin menggunakan basis data ketiga yang hasilnya berbeda dari keduanya. Sebuah proxy yang dijual sebagai proxy Inggris mungkin dianggap sebagai proxy Inggris oleh pemeriksa Anda dan sebagai proxy Irlandia oleh target Anda. Hanya pengujian terhadap sesuatu yang menyerupai target Anda yang sebenarnya yang dapat mengungkap hal tersebut.
Biaya Tidak Melakukan Pengujian dalam Bentuk Uang
Argumen abstrak mengenai kualitas data tidak akan bertahan saat dibahas dalam konteks anggaran; oleh karena itu, berikut ini perhitungan matematisnya dalam bentuk yang lebih konkret.
Misalkan Anda menjalankan tugas pemantauan harga di 50.000 halaman produk setiap hari, menggunakan bandwidth rumahan seharga sekitar $0,79/GB, dengan rata-rata 400 KB per halaman setelah kompresi. Itu setara dengan sekitar 20 GB dan sekitar $16 per hari untuk lalu lintas data — anggap saja $480 sebulan. Cukup wajar.
Sekarang, misalkan 15% dari kumpulan data Anda telah bergeser secara geografis dan Anda tidak menyadarinya selama empat minggu. Tiga hal terjadi, dan biaya lalu lintas adalah yang paling kecil di antaranya:
Lalu lintas tersebut terbuang percuma. Sekitar $72 dari pengeluaran bulanan Anda digunakan untuk membeli data yang harus Anda buang. Menyebalkan, tapi tidak fatal.
Proses pengulangan memakan biaya yang sama lagi. Anda tidak bisa menambal celah tersebut; Anda harus mengumpulkan ulang potongan data yang terpengaruh begitu proxy sudah berfungsi, yang berarti membayar dua kali untuk baris data yang sama dan menunggu pekerjaan selesai.
Keputusan yang diambil berdasarkan data yang salah itulah tagihan sesungguhnya. Empat minggu penetapan harga regional yang tanpa disadari salah wilayah berarti empat minggu posisi kompetitif yang dibangun di atas pasar milik orang lain. Tidak ada yang merinci hal itu dalam faktur, dan itulah tepatnya mengapa masalah ini bertahan begitu lama.
Ada biaya keempat yang lebih sulit diukur namun lebih mudah dirasakan: kepercayaan. Saat pertama kali diketahui bahwa satu set data salah selama sebulan, setiap angka berikutnya dari pipa data tersebut akan dipertanyakan. Memulihkan kepercayaan itu membutuhkan waktu lebih lama daripada membangun ulang pipa data itu sendiri.
Dibandingkan dengan itu, biaya pengujian hanyalah beberapa ratus permintaan per hari ke titik akhir yang diketahui. Pada bandwidth yang dihitung berdasarkan lalu lintas, satu siklus validasi hanya menghabiskan beberapa sen. Pada sistem penetapan harga per IP, biayanya sama sekali tidak ada selain waktu yang diperlukan untuk menulisnya. Ini adalah salah satu kasus langka di mana opsi yang murah dan opsi yang benar adalah opsi yang sama.
Kegagalan Tersembunyi yang Diurutkan Berdasarkan Lamanya Waktu Tersembunyi
Tidak semua kegagalan tersembunyi itu sama. Mengurutkan kegagalan berdasarkan lamanya waktu mereka dapat bertahan tanpa terdeteksi akan memberi tahu Anda bagian mana yang perlu diuji secara lebih intensif, dan pengurutan ini lebih berguna daripada pengurutan berdasarkan tingkat keparahan.
Tersembunyi tanpa batas waktu: kebocoran DNS, ketidakkonsistenan header, ketidaksesuaian sidik jari TLS. Masalah-masalah ini mungkin tidak pernah menimbulkan gejala yang terlihat. Masalah-masalah ini mengubah cara Anda diklasifikasikan, dan klasifikasi tersebut tidak terlihat dari sisi Anda. Jika sebuah situs memutuskan bahwa lalu lintas Anda bersifat otomatis dan merespons dengan menyajikan konten cache yang sedikit kedaluwarsa, Anda tidak akan mengetahuinya dari log Anda — hanya dengan membandingkan output Anda dengan permintaan yang dibuat dari browser biasa.
Tersembunyi selama berminggu-minggu: Pergeseran geolokasi dan penghilangan konten. Keduanya pada akhirnya akan terungkap ketika seseorang menyadari bahwa data terlihat aneh, yang merupakan mekanisme deteksi dengan latensi yang diukur berdasarkan seberapa lama waktu yang dibutuhkan manusia untuk menjadi curiga.
Tersembunyi selama beberapa hari: Penurunan reputasi pada target tertentu. Yang satu ini memang muncul dalam metrik tingkat keberhasilan, tetapi hanya jika Anda memisahkan metrik tersebut berdasarkan target. Tingkat keberhasilan agregat di seluruh dua belas situs akan dengan mudah menyerap satu situs yang anjlok hingga 40% dan tetap terlihat sehat.
Tidak tersembunyi: Titik akhir yang mati, kegagalan otentikasi, dan timeout. Penanganan kesalahan yang sudah ada akan mendeteksi hal-hal ini pada permintaan pertama.
Polanya cukup jelas untuk dijadikan pedoman praktis: semakin mirip kegagalan dengan keberhasilan, semakin lama berlangsung, dan semakin mahal biayanya. Lakukan pengujian dalam urutan terbalik dari seberapa mencolok suatu kegagalan terjadi.
Pengujian Sebelum Membeli versus Pengujian Saat Beroperasi
Ini adalah dua kegiatan yang berbeda dengan tujuan yang berbeda pula, dan seringkali orang salah mengartikannya.
Pengujian sebelum pembelian menjawab pertanyaan: apakah pool ini cocok untuk target saya? Pengujian ini dilakukan dalam masa uji coba, dengan volume kecil, dan menargetkan situs-situs yang benar-benar Anda pedulikan. Cara yang salah adalah menjalankan alat penguji proxy generik dan membandingkan tanda centang hijau — setiap penyedia lulus tes tersebut, termasuk yang akan gagal saat digunakan dalam produksi. Cara yang benar adalah mengambil sampel yang representatif dari beban kerja nyata Anda dan menjalankannya. Jika penyedia menawarkan masa uji coba (layanan kami mencakup 1 TB lalu lintas residensial untuk akun baru, dan penawaran serupa sudah menjadi standar di pasar), masa uji coba tersebut memang disediakan untuk tujuan ini, dan Anda sebaiknya memanfaatkan setiap gigabyte-nya untuk permintaan yang realistis, bukan untuk httpbin.org.
Pengujian operasional menjawab pertanyaan yang berbeda: apakah ada yang berubah sejak kemarin? Pengujian ini berjalan secara terus-menerus, pada sampel kecil yang tetap, dan nilai utamanya terletak pada perubahannya. Pengujian operasional yang hanya memberi tahu Anda keadaan saat ini hampir tidak layak dilakukan. Pengujian yang menunjukkan bahwa keadaan saat ini berbeda dari minggu lalu sangatlah berharga.
Perbedaan ini penting karena pengujian kedua jauh lebih mudah dibenarkan, namun justru lebih sering diabaikan. Pengujian pra-pembelian terasa seperti due diligence dan orang-orang melakukannya. Pengujian operasional terasa seperti beban tambahan dan orang-orang menghentikannya setelah bulan pertama yang tenang.
Apa yang Sebenarnya Harus Diperiksa dalam Sebuah Pengujian
Pengujian yang hanya memeriksa apakah "permintaan berhasil" hampir tidak berguna, karena semua alasan di atas. Kumpulan pernyataan verifikasi yang berguna harus singkat namun spesifik.
| Pernyataan Verifikasi | Mendeteksi | Seberapa Sering |
|---|
| Alamat IP keluar berada di negara dan wilayah yang diharapkan | Penyimpangan geolokasi | Setiap kali dijalankan |
| Isi respons mengandung penanda yang diketahui stabil dari target | Pemblokiran lunak, penghilangan konten | Setiap kali dijalankan |
| Jumlah baris atau item berada dalam rentang yang diharapkan | Respons parsial | Setiap kali dijalankan |
| Resolusi DNS terjadi melalui proxy | Kebocoran | Harian |
| Header permintaan tiba sesuai yang dikirim | Injeksi dan penghilangan | Mingguan |
| Tingkat keberhasilan per target, bukan agregat | Penurunan reputasi | Secara terus-menerus |
| Persentil latensi, bukan rata-rata | Degradasi yang tersembunyi oleh permintaan cepat | Secara terus-menerus |
Dua di antaranya layak untuk dijelaskan lebih lanjut.
Selalu segmentasikan berdasarkan target. Angka tingkat keberhasilan agregat tunggal adalah kesalahan pemantauan paling umum di bidang ini. Dua belas target dengan 99% dan satu dengan 40% akan menghasilkan rata-rata yang tampak baik-baik saja. Setiap metrik yang Anda pantau harus per-target.
Persentil, bukan rata-rata. Distribusi latensi proxy secara alami memiliki ekor yang panjang — beberapa node keluar menggunakan koneksi perumahan dengan karakteristik perumahan. Rata-rata 800 ms bisa saja berasal dari kumpulan yang seragam atau kumpulan bimodal di mana sepertiga permintaan Anda memakan waktu empat detik. Penyebaran p50/p95/p99 memberi tahu Anda mana yang dimaksud, dan hanya yang kedua yang memerlukan tindakan.
Implementasi konkret dari semua ini — skrip, titik akhir, perintah — terdapat dalam panduan pengujian proxy.
Mengintegrasikan Pengujian ke Dalam Alur Kerja, Bukan di Luarnya
Alasan pengujian sering diabaikan hampir tidak pernah karena orang-orang menganggapnya tidak perlu. Masalahnya adalah rangkaian pengujian berada dalam skrip terpisah yang harus diingat untuk dijalankan, dan ingatan adalah sumber daya yang dapat habis.
Pengujian yang bertahan adalah pengujian yang tidak bisa dilewati. Tiga pola berikut ini efektif:
Validasi N respons pertama dari setiap pekerjaan. Sebelum proses utama dilanjutkan, ambil beberapa halaman dan periksa sesuai dengan asersi Anda. Jika geolokasi salah atau penanda hilang, hentikan sebelum menghabiskan bandwidth. Ini adalah pola dengan nilai tertinggi karena gagal dengan cepat tepat pada eksekusi yang sebaliknya akan menghasilkan data yang salah selama sebulan.
Tetapkan invarian di dalam parser. Jika halaman kategori tidak pernah memiliki kurang dari dua puluh item, jadikan jumlah kurang dari dua puluh sebagai kesalahan, bukan hasil. Parser adalah tempat di mana kegagalan yang tidak terdeteksi menjadi permanen, sehingga di situlah mekanisme pengaman harus ditempatkan.
Pertahankan target canary. Satu halaman, yang stabil, yang Anda ambil sesuai jadwal tetap melalui pool yang sama. Ketika canary berubah tetapi halaman tersebut tidak, berarti ada sesuatu yang berubah di jalur Anda. Canary tidak mahal dan mengubah "data terlihat aneh" dari pengamatan manusia menjadi peringatan yang dilengkapi cap waktu.
Semua ini tidak memerlukan kerangka kerja pengujian atau layanan baru. Yang diperlukan adalah agar pemeriksaan tersebut secara struktural tidak mungkin terlupakan, yang merupakan sifat desain, bukan masalah disiplin.
Ketika Pengujian Hanya Membuang-buang Waktu Anda
Kami lebih memilih mengatakan ini secara blak-blakan daripada membiarkan Anda membangun sistem pemantauan yang sebenarnya tidak Anda butuhkan.
Tugas satu kali. Jika Anda hanya mengumpulkan data sekali, minggu ini, dan tidak akan pernah lagi, perangkat validasi yang rumit akan menghabiskan biaya lebih besar daripada tugas itu sendiri. Periksa hasilnya secara kasat mata. Jika terlihat benar, kemungkinan besar memang benar. Seluruh argumen untuk pengujian didasarkan pada penyimpangan seiring waktu, dan tidak ada waktu untuk itu.
Target kecil, statis, dan berperilaku baik. Situs yang tidak menerapkan langkah-langkah anti-bot dan yang Anda akses beberapa ratus kali sehari bukanlah tempat di mana proxy mengalami degradasi. Penanganan kesalahan dasar sudah cukup.
Proksi pusat data dengan alokasi stabil, khususnya untuk geolokasi. Blok alamat pusat data dialokasikan kepada penyedia dan tetap di tempatnya, sehingga argumen pergeseran geolokasi jauh lebih lemah dibandingkan dengan pool alamat residensial. Reputasi tetap penting dan perlu dipantau, tetapi Anda dapat menguji lokasi jauh lebih jarang. Jika pekerjaan Anda tidak memerlukan karakteristik residensial, ini adalah salah satu dari beberapa alasan mengapa bandwidth pusat data — milik kami mulai dari $0,14/GB, dihitung berdasarkan lalu lintas bukan per IP — seringkali merupakan pilihan pembelian yang lebih masuk akal.
Sebelum Anda memiliki scraper yang berfungsi. Menguji proxy secara terpisah saat pipeline belum ada hanya akan menghasilkan tanda centang hijau yang tidak berarti. Bangun sistemnya terlebih dahulu, lalu uji sistem tersebut dari awal hingga akhir.
Dan skenario batas yang jujur: jika pekerjaan Anda tidak sensitif terhadap negara asal permintaan dan tidak sensitif terhadap pemblokiran, Anda mungkin tidak memerlukan proxy sama sekali. Kami lebih memilih memberi tahu Anda hal ini di sini daripada menjual sesuatu yang tidak akan Anda gunakan. Harga yang kami cantumkan telah diverifikasi berdasarkan halaman harga kami per September 2026; pastikan untuk memverifikasi angka terkini sebelum menyusun anggaran, termasuk harga kami.
Pertanyaan Lainnya
Seberapa sering saya harus menguji proxy saya?
Tergantung pada apa yang Anda uji. Konektivitas diuji secara implisit pada setiap permintaan. Geolokasi dan integritas konten perlu diperiksa di awal setiap pekerjaan, atau setiap hari jika pekerjaan berjalan terus-menerus. Perilaku header dan DNS jarang berubah dan hanya terjadi ketika ada perubahan pada stack Anda, jadi pemeriksaan mingguan biasanya sudah cukup — ditambah setelah setiap pembaruan dependensi.
Apakah alat penguji proxy online gratis sudah cukup baik?
Alat tersebut berguna untuk satu hal: memastikan endpoint masih aktif dan melaporkan alamat yang dikembalikannya. Alat tersebut tidak dapat memberi tahu Anda bagaimana target Anda memperlakukan alamat tersebut, yang justru merupakan pertanyaan yang paling penting. Sebuah proxy bisa lolos dari setiap alat penguji publik, namun tetap diblokir oleh satu situs yang Anda pedulikan. Gunakan alat-alat tersebut sebagai uji awal, bukan sebagai validasi.
Mengapa proxy saya menunjukkan negara yang berbeda dari yang dijanjikan penyedia?
Biasanya karena basis data geolokasi yang Anda gunakan berbeda dari yang digunakan penyedia, atau karena blok alamat tersebut telah dialihkan dan basis data belum diperbarui. Keduanya tidak selalu menipu — geolokasi IP adalah kesimpulan, bukan fakta, dan vendor yang berbeda memperbarui basis datanya sesuai jadwal masing-masing. Yang penting adalah apa yang diyakini oleh situs target Anda, jadi lakukan pengujian terhadap layanan pencarian yang kemungkinan besar digunakan oleh target, dan periksa lebih dari satu layanan.
Apakah pengujian dapat menyebabkan proxy saya diblokir?
Volume pengujian sangat kecil dibandingkan dengan volume produksi, sehingga risikonya kecil, tetapi pola yang ditampilkan bisa menjadi masalah. Mengakses titik akhir yang sama dari setiap alamat dalam kumpulan besar dalam hitungan detik merupakan pola yang mudah dikenali. Lakukan permintaan validasi secara bertahap dan gunakan sampel, bukan seluruh kumpulan.
Apa perbedaan antara proxy yang lambat dan proxy yang buruk?
Latensi merupakan karakteristik rute dan, untuk alamat residensial, koneksi internet rumah seseorang yang sebenarnya — proxy yang lambat bisa saja berfungsi dengan baik. Proksi yang buruk mengembalikan konten yang salah atau diubah, membocorkan informasi tentang pengaturan Anda, atau dianggap mencurigakan oleh target Anda. Nilai berdasarkan tingkat keberhasilan dan integritas konten terlebih dahulu, baru kemudian latensi, kecuali jika beban kerja Anda benar-benar sensitif terhadap latensi.
Apakah saya harus menguji proxy bergilir secara berbeda dari proxy statis?
Ya. Dengan alamat statis, Anda menguji satu hal berulang kali, sehingga sampel kecil sudah memberi gambaran hampir seluruhnya. Dengan kumpulan proxy bergilir, setiap permintaan mungkin menggunakan titik keluar yang berbeda, sehingga satu pengujian hanya memberi informasi tentang satu alamat dan tidak mencerminkan kondisi kumpulan secara keseluruhan. Uji kumpulan proxy bergilir secara statistik: ambil sampel permintaan yang cukup untuk menggambarkan distribusinya, dan lacak bentuk distribusi tersebut seiring waktu, bukan hasil individu mana pun.
Tingkat keberhasilan saya 99% — apakah saya masih perlu menguji?
Kemungkinan besar, ya, dan angka itulah alasannya. Tingkat keberhasilan mengukur apakah permintaan berhasil diselesaikan, bukan apakah responsnya benar. Blokir lunak, konten yang dipotong, dan data dari wilayah yang salah semuanya mengembalikan kode status 200. Tingkat keberhasilan yang tinggi disertai dengan penurunan jumlah baris adalah tanda klasik dari pool yang telah mengalami degradasi secara diam-diam.
Apakah pengujian penting jika saya hanya menggunakan proxy pusat data?
Kurang penting, untuk geolokasi, karena alokasi pusat data bersifat stabil. Namun sama pentingnya untuk reputasi dan integritas konten: rentang alamat pusat data lebih mudah diidentifikasi oleh situs dan sering kali menjadi sasaran pemblokiran menyeluruh, sehingga selisih antara "terhubung dengan baik" dan "mendapatkan halaman yang sebenarnya" bisa lebih lebar dibandingkan dengan alamat perumahan.
Kesimpulan
Alasan mengapa perlu menguji proxy bukanlah karena proxy itu tidak dapat diandalkan. Sebagian besar waktu, proxy berfungsi dengan baik. Alasannya adalah bahwa ketika proxy berhenti berfungsi dengan benar, biasanya proxy tersebut tetap beroperasi secara tidak benar, sementara setiap mekanisme yang sudah Anda miliki untuk mendeteksi masalah dirancang untuk menangani kasus sebaliknya.
Asimetri itulah intinya. Logika percobaan ulang Anda, sistem peringatan kesalahan, dan dasbor ketersediaan layanan Anda semuanya mendeteksi gangguan, sedangkan kegagalan yang merugikan justru terjadi tanpa tanda-tanda. Proksi yang mengembalikan kode status 200 dengan konten dari negara yang salah tidak akan pernah memicu sistem-sistem tersebut. Proksi tersebut hanya akan menghasilkan data yang masuk akal, terstruktur dengan baik, namun salah, hingga ada manusia yang kebetulan memeriksanya dengan cermat — dan rentang waktu sebelum ada manusia yang memeriksanya dengan cermat itu bisa mencapai berminggu-minggu.
Pengujian mempersempit interval tersebut. Bukan dengan cara menyeluruh, melainkan dengan cara spesifik: periksa lokasi, periksa konten, segmentasikan berdasarkan target, dan letakkan pemeriksaan di tempat yang tidak dapat dilewati. Itu adalah upaya yang tidak terlalu besar, dan itulah perbedaan antara mengetahuinya pada hari pertama dan mengetahuinya pada hari ketiga puluh.
