Dengan membeli proxy residensial, Anda sebenarnya menyewa koneksi rumah orang lain. Siapa yang memiliki dan dengan persetujuan siapa — adalah pertanyaan yang pada tahun 2026 berhenti menjadi filosofis. Pada bulan Januari, Google bersama mitranya membongkar jaringan IPIDEA, di mana alamat dikumpulkan termasuk melalui program yang terinfeksi trojan dan perangkat set-top box dengan kode proxy tersembunyi. Dan mulai bulan September, perusahaan AppEsteem, yang mengelola daftar publik perangkat lunak "menipu", memeriksa para operator proxy setiap bulan: apa yang dapat dilakukan klien melalui mereka dengan pemeriksaan minimal dan apakah pemilik IP rumah menderita akibatnya.
Di bawah ini adalah perbandingan empat model yang digunakan operator untuk mengumpulkan alamat residensial, dan analisis sepuluh persyaratan tes AppEsteem: mana yang relevan bagi pembeli biasa dan bagaimana operator "bertanggung jawab" akan berbeda dari yang "serba bisa" dalam tugas Anda.
Apa yang terjadi: operator proxy mulai diuji seperti antivirus
AppEsteem terdaftar di AMTSO (organisasi yang menetapkan standar pengujian antivirus) untuk serangkaian "AppEsteem 2026 Residential Proxy Operator Responsibilities Test Series". Pemberitahuan tentang tes tersebut dipublikasikan pada 21 September 2026, tanggal publikasi hasil di kartu AMTSO — 19 November 2026.
Dari rencana tes yang dipublikasikan (versi 1.1 dari 11 September):
- Tes bersifat permanen dan bulanan. Tiga Selasa pertama setiap bulan adalah latihan, hasilnya hanya dapat dilihat oleh operator yang membayar layanan ini. Selasa keempat adalah latihan resmi untuk semua, hasilnya dipublikasikan secara gratis. Latihan resmi pertama sesuai rencana — Selasa keempat bulan September 2026.
- Diuji atas nama "klien dengan pemeriksaan paling sedikit" — akun yang terdaftar dengan ambang terendah yang diizinkan oleh operator. Bagi sebagian orang, ini adalah email dan kartu, bagi yang lain sudah KYC.
- Memeriksa setiap akses secara terpisah: proxy HTTP(S), port SOCKS5, dan seiring waktu juga antarmuka "agen"/MCP. Alasan disebutkan secara langsung dalam rencana: operator yang memblokir situs melalui HTTP terkadang membiarkannya lewat melalui SOCKS5 mereka sendiri.
- Konsekuensi: operator bersertifikat yang melanggar janji menghadapi peninjauan atau pencabutan sertifikat; yang tidak bersertifikat, yang mengiklankan alamat "etis", tetapi membiarkannya tersedia untuk penyalahgunaan, — masuk dalam daftar Deceptor. Hasil dan daftar ini disampaikan AppEsteem kepada vendor antivirus dan mereka yang melindungi jaringan perusahaan.
Detail penting: pertanyaan tentang persetujuan itu sendiri (RPR-001, "pengumpulan etis") tidak termasuk dalam tes ini — AppEsteem memeriksanya secara terpisah, dalam kerangka sertifikasi. Tes baru ini tentang hal lain: bahkan alamat yang diperoleh secara jujur tidak boleh menjadi alat serangan.
Empat model pengumpulan IP residensial: perbandingan
Menurut laporan Google Threat Intelligence Group tentang jaringan IPIDEA dan tinjauan industri, alamat masuk ke dalam kumpulan residensial melalui empat jalur utama. Mereka berbeda tidak hanya dalam etika, tetapi juga dalam seberapa stabil kumpulan tersebut dan seberapa "kotor" alamat-alamat tersebut.
1. Aplikasi "dapatkan uang dari lalu lintas" (opt-in sadar)
Orang tersebut sendiri menginstal program yang membayar atau memberikan bonus untuk berbagi saluran. Persetujuan paling jelas: pengguna memahami mengapa mereka menginstal perangkat lunak tersebut. Namun, di sini juga penting untuk melihat apakah orang tersebut mengetahui lalu lintas apa yang akan melalui salurannya, dan apakah mereka dapat mematikan berbagi kapan saja: persetujuan yang jelas saat instalasi belum tentu menjamin penggunaan yang jujur kemudian.
2. SDK dalam aplikasi biasa
Pengembang game, utilitas, atau aplikasi dengan konten menyematkan SDK monetisasi, dan perangkat tersebut menjadi node keluar. Operator SDK membayar pengembang — menurut data GTIG, biasanya untuk instalasi. Kualitas persetujuan tergantung pada bagaimana layar persetujuan ditampilkan: Infoblox dalam penelitian bulan Juni mencatat bahwa persetujuan sering tersembunyi dalam perjanjian pengguna yang tidak dibaca oleh siapa pun. Ini adalah sumber terbesar dan paling rentan: kumpulan dapat menghilang dalam satu hari. Dalam kasus IPIDEA, Google Play Protect mulai memperingatkan tentang aplikasi dengan SDK-nya, menghapusnya dan memblokir instalasi baru di perangkat Android yang bersertifikat.
3. VPN gratis dan perangkat dengan pra-instalasi
Kelas terpisah — VPN gratis, yang benar-benar berfungsi sebagai VPN, tetapi juga menyertakan perangkat dalam jaringan proxy, serta set-top box yang tidak bersertifikat dan perangkat Android murah dengan kode proxy tersembunyi "dari pabrik". Dalam laporan tentang IPIDEA disebutkan aplikasi VPN Galleon VPN, Radish VPN, dan Aman VPN. Di sini pada dasarnya tidak ada persetujuan, dan kumpulan ini bertahan hingga pembersihan platform atau firmware pertama.
4. Trojan dan botnet
Varian paling gelap: perangkat terinfeksi, pemilik tidak tahu. GTIG menemukan 3.075 hash unik file Windows yang berinteraksi dengan domain pengendali IPIDEA, termasuk biner yang menyamar sebagai OneDriveSync dan Pembaruan Windows. Alamat-alamat tersebut biasanya sudah terdaftar dalam basis data ancaman — dan, yang lebih penting bagi pembeli, di dekat Anda melalui jaringan yang sama bekerja penjahat: menurut data Google, dalam satu minggu Januari 2026, node keluar IPIDEA digunakan oleh lebih dari 550 kelompok.
Tabel ringkasan
| Model | Persetujuan pemilik IP | Stabilitas kumpulan | Risiko reputasi "kotor" alamat | Risiko pembersihan mendadak |
|---|---|---|---|---|
| Opt-in "dapatkan uang dari lalu lintas" | Jelas | Rata-rata | Di bawah rata-rata | Rendah |
| SDK dalam aplikasi | Dari jelas hingga formal | Tinggi, selama SDK belum diblokir | Rata-rata | Rata-rata–tinggi |
| VPN gratis, set-top box dengan pra-instalasi | Formal atau tidak ada | Rendah | Tinggi | Tinggi |
| Trojan, botnet | Tidak ada | Tidak terduga | Sangat tinggi | Sangat tinggi |
Penilaian di tiga kolom terakhir — adalah interpretasi kualitas kami berdasarkan kasus-kasus yang dijelaskan, bukan pengukuran. Kami telah membahas secara rinci bagaimana larangan SDK di platform mempengaruhi kumpulan, dalam artikel tentang larangan proxy-SDK di Smart TV dari LG.
Sepuluh persyaratan AppEsteem dan apa artinya bagi pembeli
Tes ini mengukur perilaku operator berdasarkan sepuluh poin dari whitepaper AppEsteem (RPR-002 — RPR-011). Bagi klien, mereka dibagi menjadi tiga kelompok.
Melindungi Anda dan pemilik alamat
- RPR-002 — alamat bersih. Operator harus tidak memberikan izin sebelumnya untuk menggunakan IP untuk spam, penipuan, dan manipulasi, dan tidak menyelesaikannya setelah fakta. Bagi Anda, ini berarti lebih sedikit alamat yang sudah ditandai dalam basis data anti-penipuan.
- RPR-003 — tidak ada lalu lintas ilegal, domain malware, situs kriminal, dan forum dengan data yang dicuri.
- RPR-005 — lalu lintas hanya keluar. Tidak boleh mengarahkan keluar ke jaringan rumah, ke router, ke loopback, serta membuka port email dan remote-desktop atau UDP-relay.
- RPR-010 — program terisolasi dari perangkat. Ia tidak membaca kata sandi, cookie, dan file pemilik, dan kredensial Anda tidak dibaca dalam perjalanan.
- RPR-011 — perangkat lunak diperbarui dan dilindungi secara merata di semua akses.
Blokir yang akan diperhatikan klien
- RPR-006 — kategori berbahaya ditutup secara default untuk pendaftaran anonim apa pun. Dalam rencana tes, kategori yang dicontohkan termasuk konten dewasa, perjudian, situs pemerintah, bank, kripto, streaming, permainan, tiket, dan email.
- RPR-007 — pemblokiran tidak dapat dihindari dengan mengedit alamat sedikit, "reflektor" atau port SOCKS5 milik operator.
- RPR-004 — hanya halaman publik. Untuk klien yang tidak terverifikasi, koneksi harus membaca apa yang ditampilkan situs kepada semua orang, dan tidak mentransfer login, cookie, dan token ke bagian tertutup. Tes memeriksa pada situs kontrol akses, pendaftaran, publikasi, dan substitusi kredensial.
Transparansi aturan
- RPR-008 dan RPR-009 — aturan yang dipublikasikan (AUP) dan daftar pengecualian dengan alasan. Operator dapat membuka akses ke kategori tertutup untuk klien yang terverifikasi, tetapi hanya jika pengecualian tersebut dipublikasikan, klien telah melewati pemeriksaan, dan pemilik alamat dapat melihat bagaimana koneksinya digunakan. Dalam rencana secara langsung dicatat: tanpa syarat ketiga, pemeriksaan identitas melindungi "dokumen operator, bukan konsumen".
Tes ini juga menangkap kesalahan sebaliknya — over-cautiousness. Jika operator memblokir situs biasa seperti berita atau ensiklopedia, itu dianggap sebagai kegagalan: berarti, pemblokiran mereka tidak memberikan informasi tentang kualitas perlindungan.
Apa yang akan berubah dalam tugas Anda
Jika industri mulai menyesuaikan diri dengan tes ini, operator "bertanggung jawab" dan "serba bisa" akan berperilaku berbeda tergantung pada skenario.
- Pengambilan data publik (harga, hasil, katalog, ulasan). Tidak ada yang rusak: RPR-004 secara langsung mengizinkan membaca apa yang ditampilkan situs kepada semua orang. Keuntungannya — alamat yang lebih bersih dan lebih sedikit captcha dari tetangga di kumpulan.
- Multi-akunting, SMM, bekerja di akun. Zona yang paling sensitif. Login, publikasi, dan cookie sesi — tepat apa yang RPR-004 larang untuk "klien dengan pemeriksaan paling sedikit". Artinya, operator yang bertanggung jawab akan mengalihkan skenario semacam itu ke tarif terverifikasi dengan KYC dan deskripsi tugas. Kami membandingkan siapa di antara penyedia besar yang sudah memperketat akses, dalam tinjauan KYC dan aturan penggunaan di penyedia proxy.
- Email, messenger dengan port non-standar, UDP. Port email dan UDP-relay dari jaringan rumah dianggap sebagai pelanggaran oleh tes. Untuk tugas semacam itu, lebih bijaksana untuk langsung mengambil proxy data center atau varian server, di mana tidak ada perangkat rumah yang dapat disusupi.
- Bank, situs pemerintah, tiket, streaming. Kategori ini dalam contoh pemblokiran default. Jika tugas Anda adalah pemeriksaan legal terhadap lokalisasi atau harga di niche ini, bersiaplah untuk diminta deskripsi kasus.
Bagaimana memeriksa penyedia sekarang juga
Hasil AppEsteem untuk operator tertentu belum dipublikasikan, tetapi pertanyaan dari metodologinya dapat diajukan kepada penjual mana pun:
- Dari mana alamatnya? Aplikasi opt-in, SDK, kemitraan dengan penyedia? Apakah ada halaman publik tentang persetujuan pemilik dan bagaimana mereka dapat mematikannya?
- Apakah ada AUP yang dipublikasikan dan daftar kategori yang diblokir? Jika tidak ada aturan sama sekali, itu bukan "kebebasan", tetapi sinyal bahwa siapa pun dapat bekerja di kumpulan Anda.
- Apakah HTTP dan SOCKS5 bekerja dengan cara yang sama? Periksa satu situs yang sama melalui kedua protokol: perbedaan dalam ketersediaan adalah tanda perlindungan yang ditambal.
- Seberapa bersih alamatnya? Jalankan 10–20 IP yang diberikan melalui pemeriksa reputasi dan bandingkan dengan koneksi yang tepercaya. Proporsi tinggi alamat dengan label "proxy/bot/penipuan" menunjukkan bagaimana kumpulan tersebut terisi.
- Apa yang akan terjadi saat pembersihan massal? Tanyakan, dari berapa banyak sumber kumpulan tersebut dibentuk. Satu SDK — satu hari hingga kehilangan sebagian besar alamat yang signifikan.
Untuk skenario di mana alamat rumah "hidup" penting — pengeluaran lokal, pemeriksaan iklan, harga geo — pilih proxy residensial dengan aturan yang jelas dan rotasi sesuai tugas, dan untuk bekerja di akun dengan login, tanyakan terlebih dahulu kepada penyedia apakah skenario semacam itu diizinkan.
Kesimpulan
Tes AppEsteem — upaya pertama untuk mengukur operator proxy seperti antivirus: berdasarkan metodologi publik, setiap bulan, dengan penilaian terpisah untuk pemilik alamat dan untuk klien. Untuk pengambilan data publik yang jujur, ini adalah kabar baik: lebih sedikit alamat kotor dan tetangga penjahat. Untuk multi-akunting dan bekerja dengan login — sinyal untuk bersiap-siap menghadapi KYC dan deskripsi tugas. Hasil publik pertama diharapkan pada bulan November; sampai saat itu, filter terbaik — adalah pertanyaan yang sama tentang asal-usul alamat dan aturan yang diajukan oleh tes itu sendiri.