Cloaking server-side adalah filter yang mengambil keputusan di server situs Anda: permintaan pengunjung tiba di hosting, kode PHP bertanya kepada layanan filter siapa yang datang, dan baru setelah ada jawaban mengirim ke browser offer atau halaman netral. Cloaker di browser bekerja berbeda: halaman sudah mulai dimuat, lalu tag JS di <head> menyembunyikan isinya, memeriksa kunjungan, dan menampilkan varian yang tepat.
Kedua skema menyelesaikan tugas yang sama — menyaring bot, scanner, spy tool, dan trafik tidak tertarget — tetapi melihat kunjungan dari sisi berbeda dan rusak dengan cara berbeda. Pemasangan langkah demi langkah dibahas di artikel cara memasang cloaker di website; di sini kita membahas arsitekturnya: apa yang terjadi di dalam, di mana kekuatan dan kelemahan masing-masing cara.
Cloaking server-side: bagaimana permintaan berjalan
Jalur kunjungan pada skema server-side:
- Pengunjung mengklik iklan, browser meminta
situs-anda.com. - Permintaan sampai di server Anda, dan yang pertama menjawab adalah file PHP, bukan landing page.
- File meneruskan data permintaan ke layanan: IP, header, parameter tautan.
- Layanan memeriksa kunjungan dan mengembalikan keputusan.
- Server mengirim ke browser offer atau White Page. Sampai saat itu browser belum menerima satu byte pun dari halaman.
Sifat kuncinya — halaman tidak dikirim ke pengunjung sebelum ada keputusan. Bot tidak punya apa pun untuk disimpan, ad blocker tidak punya apa pun untuk dipotong, internet lambat tidak punya apa pun untuk ditampilkan lebih awal.
Cloaker di browser: cara kerja tag JS
Pada skema browser, urutannya terbalik:
- Browser meminta halaman, hosting Anda mengirimkannya sama untuk semua orang.
- Di baris pertama
<head>ada tag — ia dimuat lebih dulu dari apa pun dan menyembunyikan halaman. - Tag mengumpulkan sinyal browser dan mengirimkannya ke layanan.
- Jika keputusannya "offer", halaman ditampilkan. Jika "White Page" atau tidak ada keputusan, pengunjung diarahkan ke halaman netral.
Kelebihan skema ini adalah kesederhanaan: tag bisa disisipkan ke halaman mana pun yang <head>-nya bisa Anda akses, bahkan di website builder tanpa server sendiri. Kekurangannya, HTML landing page secara fisik sudah ada di browser. Tag menyembunyikannya, tetapi tidak bisa "tidak mengirimkannya".
Apa yang dilihat masing-masing cloaker tentang kunjungan
Perbedaan utama arsitektur adalah kumpulan sinyalnya.
| Sinyal | Server | Browser |
|---|---|---|
| IP, provider, jaringan, negara dari alamat | Ya | Ya, melalui layanan |
| User-Agent, bahasa, referer, header permintaan | Ya | Ya |
| Parameter tautan: fbclid, gclid, ttclid, UTM | Ya | Ya |
| Apakah klien menjalankan JavaScript | Tidak | Ya |
| Zona waktu dan bahasa browser | Tidak | Ya |
| Tanda otomatisasi (webdriver, headless) | Sebagian, dari header | Ya |
| Layar, platform, properti browser | Tidak | Ya |
| Gerakan mouse dan sentuhan | Tidak | Ya |
| Waktu yang dihabiskan di halaman | Tidak | Ya |
Server melihat permintaannya, browser melihat lingkungan tempat permintaan itu dijalankan. Bot sederhana dari data center akan tertangkap oleh keduanya. Browser otomatis di proxy rumahan dengan User-Agent yang benar tidak bisa dibedakan server dari manusia hanya dari satu permintaan — yang membongkarnya adalah perilaku JavaScript: zona waktu tidak cocok dengan negara alamat, jejak otomatisasi, tidak ada gerakan. Tentang tanda-tanda ini ada di artikel browser headless dan fingerprint dan deteksi VPN, proxy, dan IP data center.
Hibrida: keputusan server ditambah halaman pemeriksaan
Karena itu skema server-side murni dalam praktik lebih jarang dari yang dikira. Filter server memutuskan langsung jika semuanya jelas dari permintaan, dan pada kasus meragukan mengirim halaman pemeriksaan singkat: halaman itu menjalankan JavaScript, mengumpulkan sinyal browser, lalu meminta keputusan ulang. Bagi manusia ini sepersekian detik menunggu, bagi bot sederhana — jalan buntu.
Di ArtisanClo file PHP bekerja persis seperti itu: jika aturan flow mensyaratkan JavaScript atau waktu minimal di halaman, pengunjung melihat halaman tunggu dan diperiksa ulang. Sebaliknya, saat terhubung lewat filter untuk Keitaro atau gateway untuk Binom, halaman pemeriksaan tidak ada — keputusan diambil hanya dari jaringan dan tanda-tanda permintaan, sehingga pemeriksaan JavaScript dan waktu di halaman tidak berlaku di sana.
Kecepatan: di mana milidetik hilang
Setiap filter menambah waktu muat untuk mengambil keputusan. Bedanya ada di mana tepatnya.
- Skema server-side menambah permintaan dari hosting Anda ke layanan sebelum byte pertama dikirim. Kecepatannya tergantung konektivitas jaringan hosting: server yang bagus di data center menjawab cepat, shared hosting yang kelebihan beban memperlambat landing page sekaligus pemeriksaannya.
- Skema browser menambah pemuatan script dan permintaan dari browser pengunjung. Di internet seluler ini lebih terasa, tetapi halaman sudah dimuat secara paralel — setelah keputusan, ia tidak perlu diunduh ulang.
- Halaman pemeriksaan sengaja menambah waktu tunggu. Aktifkan di tempat ketegasan memang dibenarkan oleh sumber trafik, bukan di mana-mana secara default.
Dalam praktik, landing page dengan selusin script analitik dan gambar berat kehilangan waktu lebih banyak daripada cara filter mana pun. Optimasi halaman biasanya memberi hasil lebih besar daripada pilihan arsitektur.
Keandalan: bagaimana cloaker berperilaku saat gangguan
Toleransi terhadap gangguan adalah tempat arsitektur paling berbeda.
Jika tag JS tidak termuat
Tag adalah script eksternal. Jika ia tidak diloloskan jaringan, filter korporat, atau blocker di server, halaman tidak tersembunyi, dan semua orang melihatnya, termasuk bot dan spy tool. Kegagalan di sini bersifat "terbuka". Jika tag termuat tetapi tidak ada keputusan, ia mengarahkan pengunjung ke White Page — ini kegagalan "tertutup".
Jika layanan tidak menjawab server
Cara server-side menunggu jawaban dalam waktu terbatas. Di ArtisanClo file PHP menunggu hingga 4 detik, dan jika koneksi putus, selama satu hari melayani kunjungan berdasarkan jawaban terakhir yang diterima: pengunjung dengan penanda klik iklan diarahkan ke offer, lainnya ke White Page. Kunjungan yang datang sebelum jawaban pertama sama sekali akan mendapat error 503. Pada filter untuk Keitaro dan gateway untuk Binom batasnya 3 detik, setelah itu kunjungan diarahkan ke White Page.
Jika hosting rusak
Di sini kedua skema setara: landing page ada di tempat Anda, dan filter tidak bisa menghidupkan server yang mati. Layanan bertanggung jawab atas keputusan, Anda atas ketersediaan halaman dan sertifikat.
| Situasi | Tag JS | File PHP |
|---|---|---|
| Script diblokir di tengah jalan | Halaman dilihat semua orang | Tidak relevan |
| Layanan tidak menjawab | White Page | Bekerja dengan jawaban terakhir hingga satu hari |
| Hosting tidak mengizinkan koneksi keluar | Tidak berpengaruh | Error 503, pemuatan lama |
| Filter keamanan hosting (WAF) | Biasanya tidak berpengaruh | Bisa memblokir permintaan pemeriksaan |
Cache, CDN, dan proxy: musuh diam cloaking server-side
Skema server-side mengandalkan setiap permintaan sampai ke file PHP. Tiga hal menghalanginya.
- Cache halaman. Plugin cache, cache hosting, atau CDN mengirim salinan tersimpan tanpa meminta keputusan. Akibatnya semua orang melihat halaman yang sama — yang kebetulan masuk cache. Landing page dengan filter harus dikecualikan dari cache. Cache HTML lebih sedikit mengganggu tag: script di dalam salinan tetap dijalankan di browser, asalkan salinan dibuat setelah tag dipasang.
- Proxy di depan situs. Jika hosting memasang proxy sendiri di depan server, file PHP melihat alamat proxy, bukan alamat pengunjung, dan filter menilai server Anda, bukan orang. Tandanya — semua kunjungan di log punya IP yang sama. Solusinya meneruskan alamat asli (pengaturan real IP) atau proxy melalui Cloudflare, yang header-nya dipahami file.
- Cache keputusan di browser. Agar tidak bertanya ke layanan setiap kali halaman dimuat ulang, keputusan untuk satu pengunjung bisa disimpan sebentar. Di ArtisanClo dengan file PHP — hingga satu menit, jadi setelah mengubah flow periksa di jendela incognito baru.
Pembahasan masalah ini dan lainnya ada di artikel cloaker tidak bekerja dan cara memperbaikinya.
Apa yang hanya bisa dilakukan skema server-side
Ada kemampuan yang secara fisik tidak tersedia bagi kode di browser.
- Kode respons alih-alih halaman. Server bisa menjawab 403 atau 404, seperti alamat tertutup. Tag tidak bisa mengubah kode respons — di tempatnya hanya tersisa halaman kosong.
- Shadow mode. Semua pengunjung diarahkan ke offer, sedangkan log menunjukkan siapa yang akan dipotong filter. Dengan cara ini aturan baru diuji tanpa kehilangan trafik.
- Mode «Tracker». Filter tidak memotong siapa pun, hanya menghitung klik, konversi, dan uang, serta menandai bot di laporan. Cocok untuk trafik yang butuh pencatatan, bukan penyaringan — selengkapnya di artikel apa itu tracker affiliate.
Di ArtisanClo «Shadow mode» dan mode «Tracker» bekerja saat terhubung lewat file PHP, filter Keitaro, atau gateway Binom; dengan tag JS flow menyaring seperti cloaker biasa.
Pembaruan dan pemeliharaan
Satu perbedaan lagi yang tidak langsung diingat — siapa yang bertanggung jawab atas kode yang mutakhir di situs.
- Tag JS dimuat dari layanan pada setiap kunjungan. Ketika layanan menyempurnakan pemeriksaan browser, semua situs dengan tag otomatis mendapat versi baru — di sisi Anda tidak ada yang perlu diubah.
- File PHP berada di hosting Anda dan tidak memperbarui dirinya sendiri. Logika pemeriksaan dan database bot ada di sisi layanan, jadi pekerjaan utama filter tetap membaik tanpa Anda, tetapi kemampuan baru dari file itu sendiri memerlukan penggantian. Di ArtisanClo hal ini diberitahukan lewat pemberitahuan «Anda menjalankan file versi lama» beserta daftar apa yang belum bisa dilakukan versi Anda.
Dalam kedua kasus, pengaturan flow disimpan di dashboard, bukan di kode situs. Mengubah negara, ketegasan, atau White Page — perubahan berlaku sejak kunjungan berikutnya, tidak perlu mengunggah ulang file atau menyisipkan tag lagi.
Ingat juga soal hak akses. File PHP dijalankan di server Anda, jadi ambil hanya dari dashboard layanan dan jangan diubah manual: file "modifikasi" dari grup chat atau forum bisa melakukan apa saja di hosting Anda.
Cloaker PHP atau tag JS: mana yang dipilih
| Situasi Anda | Yang cocok |
|---|---|
| Website builder tanpa akses ke server | Tag JS |
| Hosting sendiri dengan PHP | File PHP |
| WordPress | Plugin yang memasang cara server-side yang sama |
| Butuh pencatatan tanpa penyaringan atau uji aturan bayangan | File PHP |
| Trafik sudah lewat Keitaro atau Binom | Filter atau gateway tracker — lihat integrasi Keitaro dan cloaker |
| Hosting melarang koneksi keluar | Tag JS |
Singkatnya: tag lebih cepat dipasang, cara server-side lebih andal dan memberi lebih banyak mode. Pengaturan penyaringan tidak tergantung arsitektur — semuanya disimpan di flow, dan cara koneksi bisa diganti tanpa mengubah aturan. Perbandingan dengan script buatan sendiri, yang juga sering disebut "cloaker PHP", ada di materi cloaker cloud atau script PHP.
Tips. Skema mana pun yang Anda pilih, setelah pemasangan buka tautan iklan di incognito dan cari kunjungan Anda di log klik. Alasan keputusan langsung menunjukkan apakah filter melihat IP asli, apakah pemeriksaan bekerja, dan apakah cache tidak mengirim salinan lama.
Penyaringan server-side dan kebijakan platform
Arsitektur tidak mengubah sisi hukumnya. Platform iklan melarang menampilkan kepada sistem pemeriksaan iklan sesuatu yang berbeda dari yang dilihat pengguna — tidak peduli apakah yang memutuskan server atau browser. Manfaat jujur dari skema mana pun adalah penyaringan bot, klik palsu, spy tool, dan geo tidak tertarget, statistik bersih, serta pencatatan uang. Selengkapnya di artikel cloaking untuk affiliate marketing.
Kesimpulan
- Cloaking server-side memutuskan sebelum halaman dikirim: tidak tergantung ad blocker, bisa mengirim kode respons, punya «Shadow mode» dan mode «Tracker», tetapi butuh PHP, koneksi keluar, dan kehati-hatian dengan cache dan proxy.
- Cloaker di browser bisa dipasang di
<head>mana pun dan melihat sinyal yang tidak tersedia bagi server, tetapi HTML halaman sudah ada di browser, dan script yang gagal dimuat tidak menyembunyikan apa pun. - Yang terbaik dari dua dunia diberikan oleh keputusan server dengan halaman pemeriksaan: jaringan dan permintaan dilihat server, perilaku dan lingkungan dilihat JavaScript singkat di browser.
- Syarat, fitur, dan isi paket ada di halaman fitur dan harga.
