Panel pemantauan berwarna hijau, uptime 99.9%, tetapi dukungan menerima keluhan "situs tidak terbuka" atau "halaman diblokir di wilayah saya". Ini bukan bug pemantauan — ini adalah fitur arsitektur: bot layanan uptime memeriksa situs dari IP pusat data, sementara pengunjung nyata mengakses dari internet rumah, jaringan seluler, atau melalui penyedia tertentu yang diblokir secara terpisah. Kami membahas mengapa ini terjadi dan pemeriksaan 5 yang perlu ditambahkan untuk melihat pemblokiran lebih awal dari pelanggan.
Mengapa pemantauan uptime biasa menipu
Layanan seperti UptimeRobot, Pingdom, StatusCake, dan sebagian besar solusi self-hosted di Zabbix atau Grafana mengirimkan permintaan dari server yang terletak di pusat data AWS, Hetzner, DigitalOcean, dan sejenisnya. Server-server ini memiliki IP statis yang dimiliki oleh ASN penyedia hosting — dan ini adalah masalah utama. Setiap sistem perlindungan (anti-fraud Facebook, geo-filter Wildberries, aturan Cloudflare, pemblokiran di tingkat Roskomnadzor atau operator lokal) membedakan lalu lintas berdasarkan asal IP, bukan berdasarkan ketersediaan kode HTTP.
Akibatnya, muncul zona buta klasik: bot dengan IP pusat data menerima 200 OK, karena ia tidak terfilter — ia bahkan tidak terlihat seperti "pengguna biasa" yang ingin diblokir oleh sistem. Sementara itu, orang nyata dengan internet seluler, Wi-Fi rumah di negara lain, atau melalui penyedia tertentu menerima 403, pengalihan ke halaman "tidak tersedia di wilayah Anda", atau captcha tanpa akhir. Pemantauan tidak melihat ini, karena secara teknis situs merespons — hanya saja tidak kepada orang yang seharusnya.
Masalah ini sangat kritis bagi tiga kelompok: para arbitrase, di mana platform iklan dan sistem anti-fraud memblokir landing page berdasarkan IP hosting; penjual di marketplace, di mana konten dan harga ditampilkan berbeda tergantung pada wilayah; dan SMM/pemasar yang menguji iklan untuk berbagai negara dan tidak menyadari bahwa audiens di geo target secara fisik tidak melihat halaman.
Pemeriksaan 1: pemblokiran geo berdasarkan negara dan wilayah
Penyebab paling umum ketidaksesuaian antara laporan pemantauan dan kenyataan adalah pemblokiran berdasarkan geolokasi IP. Situs mungkin sepenuhnya tersedia dari AS, tetapi diblokir untuk pengunjung dari Jerman karena persyaratan GDPR, atau sebaliknya — diblokir untuk negara-negara CIS karena batasan sanksi dari platform iklan. Bot uptime klasik dijalankan dari satu titik (biasanya AS atau Eropa) dan secara fisik tidak dapat melihat apa yang terjadi di negara lain.
Solusinya adalah menjalankan pemeriksaan secara bersamaan dari 5-10 negara menggunakan proxy residensial, yang memiliki IP pengguna rumah nyata di wilayah yang diperlukan. Berbeda dengan alamat pusat data, IP residensial melewati semua geo-filter yang sama seperti pengunjung biasa, sehingga hasil pemeriksaan sangat mendekati apa yang dilihat oleh pelanggan.
Dalam praktiknya, ini terlihat seperti ini: Anda mengambil daftar geo target (misalnya, Rusia, Kazakhstan, Jerman, Brasil, India), mengatur skrip atau layanan pemantauan untuk rotasi IP berdasarkan setiap negara dan membandingkan status HTTP dan konten halaman. Jika setidaknya di satu wilayah respons berbeda dari yang standar — ini adalah sinyal pemblokiran geo yang tidak akan pernah ditunjukkan oleh pemantau uptime biasa.
Pemeriksaan 2: ketersediaan dari operator seluler
Zona buta kedua adalah lalu lintas seluler. Banyak platform iklan dan sistem anti-fraud (terutama di Facebook Ads dan TikTok Ads) menerapkan aturan yang lebih ketat untuk jaringan seluler, karena dari sanalah sebagian besar lalu lintas pengguna "hidup" berasal. Jika landing page diblokir oleh operator tertentu (MTS, Beeline, MegaFon, T-Mobile, Vodafone) karena keluhan atau penyaringan otomatis, pemantauan desktop dari pusat data tidak akan menunjukkan hal ini sama sekali — di sana tidak ada konsep "operator".
Untuk pemeriksaan ini, diperlukan proxy seluler, yang memberikan IP dari jaringan 4G/5G nyata dari operator. Para arbitrase menggunakannya tidak hanya untuk membuat akun, tetapi juga untuk mengontrol ketersediaan tawaran mereka khususnya dalam lalu lintas seluler, karena sebagian besar klik pada iklan di Facebook Ads dan TikTok Ads berasal dari ponsel.
Skema praktis: atur pemeriksaan ketersediaan landing page setiap jam melalui IP seluler dari 3-4 operator terbesar di geo target Anda. Jika status kode berubah menjadi 403 atau pengalihan terjadi hanya pada proxy seluler dengan respons yang tidak berubah pada pusat data — Anda telah menemukan pemblokiran yang tidak akan ditunjukkan oleh pemantauan biasa dalam pengaturan apa pun.
Pemeriksaan 3: pemblokiran oleh penyedia internet tertentu
Terkadang, situs dapat diakses dari negara secara keseluruhan, tetapi diblokir oleh penyedia tertentu karena penyaringan DNS, pendaftaran, atau aturan lokal. Ini sangat relevan untuk Rusia dan CIS, di mana pemblokiran sering diterapkan secara selektif: satu operator menyaring sumber daya, yang lain tidak. Pemantauan uptime dari satu IP pusat data hanya melihat satu "jalur" ke situs dan tidak dapat menangkap ketidakmerataan seperti itu.
Untuk menutup pemeriksaan ini, Anda perlu menguji ketersediaan melalui proxy residensial dari beberapa penyedia di satu wilayah — misalnya, Rostelecom, MTS, Beeline untuk Rusia. Jika setidaknya satu penyedia menunjukkan penolakan, sementara yang lain membuka halaman dengan normal — ini adalah pemblokiran titik pada tingkat DNS atau penyaringan IP yang perlu diatasi secara terpisah, bukan dengan solusi massal.
Untuk penjual di Wildberries, Ozon, dan Avito, ini sangat penting: terkadang kartu produk atau seluruh akun pribadi menjadi tidak tersedia hanya untuk pengguna dari satu penyedia karena kesalahan teknis di pihak marketplace, sementara layanan dukungan menjawab "semuanya berfungsi", karena memeriksa dari saluran komunikasi yang berbeda.
Pemeriksaan 4: perilaku CDN dan WAF (Cloudflare, Qrator)
Sistem perlindungan dari DDoS dan filter bot, seperti Cloudflare, Qrator, StormWall, secara aktif menggunakan reputasi alamat IP untuk memutuskan apakah akan menampilkan captcha atau memblokir permintaan. Rentang pusat data AWS, Google Cloud, dan DigitalOcean sudah lama dikenal oleh sistem ini dan sering mendapatkan akses yang disederhanakan untuk bot tepercaya (termasuk pemantauan uptime), karena penyedia WAF sendiri mendukung daftar putih untuk layanan semacam itu.
Pengguna biasa dengan IP residensial atau seluler tidak memiliki privilese ini dan dapat menghadapi tantangan JS, captcha, atau pemblokiran sementara jika situs memiliki aturan perlindungan yang agresif. Ini menciptakan paradoks: semakin baik WAF bekerja melawan bot, semakin buruk pemantauan uptime melihat gambaran nyata, yang juga menggunakan lalu lintas mirip bot dari IP tepercaya.
Pemeriksaan di sini sederhana — jalankan permintaan ke situs melalui proxy pusat data dan melalui proxy residensial secara bersamaan, bandingkan kode respons dan adanya halaman tantangan JS. Jika IP pusat data menerima 200 instan, sementara residensial menerima halaman pemeriksaan browser, berarti WAF diatur sedemikian rupa sehingga pengguna nyata kehilangan waktu atau bahkan terputus pada langkah ini, dan pemantauan standar tidak akan pernah menunjukkan ini.
Pemeriksaan 5: rendering dengan jejak digital nyata di browser anti-deteksi
Pemeriksaan terakhir dan paling halus adalah bukan hanya IP, tetapi jejak digital lengkap dari browser: User-Agent, resolusi layar, zona waktu, font, rendering WebGL. Banyak sistem anti-fraud (terutama di Facebook Ads, TikTok Ads, dan layanan perbankan) membuat keputusan tentang pemblokiran berdasarkan kombinasi IP dan jejak digital, bukan satu parameter saja. Permintaan HTTP sederhana dari skrip pemantauan tidak mereproduksi kombinasi ini, sehingga tidak melihat pemblokiran yang hanya aktif di browser dengan rendering halaman yang nyata.
Untuk pemeriksaan semacam ini, diperlukan browser anti-deteksi yang lengkap — Dolphin Anty, AdsPower, Multilogin, GoLogin, atau Octo Browser — yang diatur pada IP residensial atau seluler dari wilayah target. Anda membuat profil dengan jejak digital yang realistis, menghubungkan proxy, dan membuka situs seperti yang dilakukan pengunjung biasa. Jika halaman dimuat dengan normal melalui permintaan HTTP biasa, tetapi menunjukkan pemblokiran atau pengalihan di browser anti-deteksi dengan IP residensial — masalahnya terletak pada kombinasi jejak digital dan anti-fraud, dan harus diselesaikan di tingkat akun iklan atau perlindungan situs, bukan hosting.
Cara mengatur pemantauan dengan IP residensial dan seluler
Untuk menutup semua lima zona buta, tidak perlu menulis kode yang rumit — cukup dengan skema langkah demi langkah yang dapat diulang di layanan pemantauan mana pun atau bahkan secara manual dengan jumlah pemeriksaan yang sedikit.
Langkah 1. Tentukan daftar geo dan penyedia kritis — biasanya ini adalah 3-5 negara di mana Anda mendapatkan lalu lintas atau iklan utama, dan 2-3 operator seluler terbesar di setiap negara.
Langkah 2. Hubungkan kumpulan proxy residensial dan seluler dengan rotasi berdasarkan negara yang diperlukan. Untuk pemantauan otomatis yang teratur, proxy residensial yang terikat pada kota atau operator tertentu cocok — ini memungkinkan Anda untuk mengulangi pemeriksaan dari titik yang sama dan melihat dinamika, bukan hanya snapshot sekali.
Langkah 3. Atur skrip atau layanan siap pakai (tugas cron, Zapier, pemantauan sendiri berbasis curl atau requests) sehingga permintaan ke situs dikirim secara bergiliran melalui setiap proxy dari kumpulan, dengan interval 15-30 menit. Simpan kode HTTP, waktu respons, dan jika memungkinkan, tangkapan layar halaman untuk pemeriksaan visual.
Langkah 4. Untuk memeriksa pemblokiran yang bergantung pada jejak digital, tambahkan lapisan terpisah — membuka halaman di browser anti-deteksi sesuai jadwal, setidaknya sekali sehari untuk setiap geo kritis. Ini dapat diotomatisasi melalui API bawaan Dolphin Anty atau AdsPower, yang memungkinkan Anda menjalankan profil sesuai jadwal tanpa keterlibatan manusia yang terus-menerus.
Langkah 5. Atur peringatan tidak hanya untuk HTTP 5xx, tetapi juga untuk perubahan konten halaman (misalnya, munculnya kata "tidak tersedia", "pemblokiran", "terbatas wilayah") dan untuk peningkatan waktu respons, yang sering menandakan tantangan JS dari WAF.
Kasus nyata: arbitrase, e-commerce, SMM
Seorang arbitrase menjalankan kampanye di Facebook Ads untuk landing page yang dihosting di VPS biasa. Pemantauan uptime standar menunjukkan 100% ketersediaan, tetapi CTR untuk iklan tiba-tiba turun di satu geo. Pemeriksaan melalui proxy seluler dari wilayah ini menunjukkan bahwa Facebook memblokir lalu lintas seluler pada rentang IP hosting ini — pengguna desktop melihat halaman, sementara audiens utama dari ponsel mendapatkan halaman kosong. Solusinya adalah memindahkan landing page ke rentang IP lain dan terus memantau melalui proxy seluler dari operator target.
Seorang penjual di Wildberries mengatur pemantauan untuk akun pribadi dan kartu produk, untuk segera mendeteksi kesalahan teknis. Pemantau uptime biasa dari pusat data menunjukkan bahwa situs berfungsi, tetapi pembeli dari beberapa wilayah melaporkan bahwa kartu produk tidak terbuka. Pemeriksaan melalui proxy residensial dari berbagai kota menunjukkan bahwa masalah ada pada node CDN tertentu yang hanya melayani sebagian negara — setelah beralih ke node cadangan, masalah hilang.
Agensi SMM menjalankan iklan untuk klien di TikTok Ads untuk landing page dengan formulir aplikasi. Formulir secara teknis berfungsi, kode HTTP 200 stabil di pemantauan biasa. Namun, saat diperiksa di browser anti-deteksi Dolphin Anty dengan IP residensial dari negara target, formulir tidak terkirim — anti-fraud TikTok menganggapnya sebagai bot karena ketidakcocokan jejak digital dengan pola perangkat yang diharapkan. Setelah mengatur parameter profil yang benar dan melakukan pemeriksaan ulang dengan IP seluler yang nyata, formulir mulai menerima aplikasi tanpa kesalahan.
Tabel: jenis IP untuk pemeriksaan apa
| Jenis pemeriksaan | Jenis IP yang direkomendasikan | Apa yang ditunjukkan |
|---|---|---|
| Pemblokiran geo berdasarkan negara | Proxy residensial | Ketersediaan di wilayah tertentu, seperti pengguna nyata |
| Pemblokiran jaringan seluler | Proxy seluler | Ketersediaan untuk audiens Facebook Ads / TikTok Ads di ponsel |
| Penyaringan oleh penyedia tertentu | Proxy residensial yang terikat pada ASN penyedia | Pemblokiran DNS titik pada penyedia tertentu |
| Perilaku CDN/WAF | Perbandingan IP pusat data dan residensial | Perbedaan reaksi perlindungan terhadap lalu lintas tepercaya dan biasa |
| Pemblokiran jejak digital | IP residensial/seluler + browser anti-deteksi | Reaksi anti-fraud terhadap kombinasi IP dan jejak digital |
Daftar periksa sebelum memulai pemantauan
Sebelum menganggap pemantauan dapat diandalkan, ikuti daftar ini:
- Pemeriksaan dijalankan dari minimal 3-5 negara audiens target, bukan hanya dari lokasi layanan pemantauan.
- Ada lapisan pemeriksaan terpisah melalui IP seluler dari setidaknya dua operator di setiap geo kunci.
- Ketersediaan diuji melalui proxy residensial dari berbagai penyedia di dalam satu negara.
- Dibandingkan respons dari IP pusat data dan residensial untuk menilai perilaku WAF/CDN.
- Setidaknya sekali sehari dilakukan pemeriksaan melalui browser anti-deteksi dengan jejak digital yang realistis.
- Peringatan diatur tidak hanya untuk kode respons, tetapi juga untuk perubahan konten dan waktu pemuatan halaman.
- Hasil pemeriksaan dicatat dengan kaitan ke negara, operator, dan jenis IP untuk analisis selanjutnya.
Kesimpulan
Pemantauan uptime klasik menyelesaikan tugas sempit — memeriksa apakah server merespons sama sekali. Namun, tidak menjawab pertanyaan utama bisnis: apakah pengguna nyata dari negara yang tepat, dengan operator yang tepat, dan perangkat yang tepat melihat apa yang seharusnya mereka lihat. Lima pemeriksaan — berdasarkan geo, jaringan seluler, penyedia tertentu, perilaku CDN/WAF, dan jejak digital di browser anti-deteksi — menutup kesenjangan ini dan menunjukkan gambaran yang sedekat mungkin dengan kenyataan.
Jika Anda menjalankan iklan melalui Facebook Ads, TikTok Ads, atau Google Ads, mengelola kartu di Wildberries dan Ozon, atau hanya ingin melihat situs seperti yang dilihat pelanggan di berbagai negara, sebaiknya tambahkan pemeriksaan melalui proxy residensial untuk tes geo dan proxy seluler untuk mengontrol ketersediaan di jaringan seluler. Ini tidak menggantikan pemantau uptime standar, tetapi menutup zona buta mereka — dan memungkinkan Anda mengetahui tentang pemblokiran lebih awal sebelum pelanggan melaporkannya.