89,6% Situs Eropa Menggunakan CDN — Mengapa Cloudflare Berisiko dalam Monokultur Filter

Pada 7 September 2026, peneliti CipherCue menerbitkan pengukuran yang harus dibaca oleh semua orang yang mengakses web Eropa secara otomatis: dari 44.143 perusahaan Eropa yang berhasil mendeteksi CDN, 89,6% menggunakan Cloudflare. Bukan "pemimpin pasar dengan selisih besar" — tetapi hampir seluruh pasar secara keseluruhan. Untuk pengikisan, multi-akun, dan otomatisasi apa pun, ini berarti satu hal sederhana: akses ke sembilan situs dari sepuluh di UE dikelola oleh algoritma yang sama, berdasarkan kriteria yang sama, dalam satu detik yang sama.

Apa yang dihitung

Sampling — perusahaan dari Jerman, Inggris, Belanda, Polandia, Prancis, Italia, Spanyol, dan Irlandia, yang memiliki setidaknya satu komponen CDN di situs mereka. Deteksi dilakukan melalui respons HTTP dan jejak server: header cf-ray dan server: cloudflare untuk Cloudflare, x-served-by dengan cache marker untuk Fastly, x-amz-cf-id untuk CloudFront. Tanggal pengamatan — 7 September 2026.

Pembagian berdasarkan penyedia:

• Cloudflare — 39.547 perusahaan (89,6%)
• Amazon CloudFront — 3.112
• Fastly — 1.299
• Akamai — 396

Menurut negara, distribusinya cukup mencolok, tetapi batasnya tinggi di mana-mana:

• Belanda — 95,6% (7.587 dari 7.939)
• Inggris — 93,2% (15.846 dari 17.007)
• Polandia — 92,6% (2.682 dari 2.896)
• Prancis — 86,2% (3.456 dari 4.008)
• Italia — 85,4% (3.126 dari 3.661)
• Jerman — 81,4% (4.650 dari 5.715)
• Spanyol dan Irlandia — masing-masing 78,8%

Para penulis sendiri mencatat keterbatasan, dan itu jujur: satu perusahaan bisa terdaftar di beberapa penyedia sekaligus (penghitungan ganda), dan sampling ini condong ke arah bisnis kecil dan menengah — segmen di mana tarif gratis Cloudflare paling kuat. Jadi 89,6% — ini adalah proporsi dari perusahaan dengan CDN yang terdeteksi, bukan dari semua entitas hukum Eropa.

Pemeriksaan independen tentang urutan besaran ada: menurut data W3Techs pada September 2026, Cloudflare digunakan oleh 84,7% situs yang diketahui menggunakan reverse proxy, — ini adalah 25,2% dari semua situs dalam indeks mereka. Metodologi yang berbeda, sampling yang berbeda, tetapi kesimpulannya satu: di depan seperempat web dan di depan sebagian besar instalasi CDN yang dikenali, ada satu perantara.

Mengapa untuk otomatisasi ini bukan "hanya pangsa pasar"

Ketika ada banyak filter, kesalahan dalam satu jejak berarti akses ke satu situs. Ketika filter sebenarnya hanya satu, kesalahan berarti akses ke seluruh segmen sekaligus — dan ini mengubah ekonomi kerja.

Cloudflare memberikan permintaan bot score dari 1 hingga 99: semakin rendah, semakin tinggi keyakinan bahwa di depan situs adalah otomatisasi. Model yang menghitung skor ini, menurut deskripsi perusahaan itu sendiri, memproses lebih dari 46 juta permintaan HTTP per detik dan mempertimbangkan tidak hanya permintaan spesifik Anda, tetapi juga statistik global di seluruh jaringan: reputasi IP, ASN, dan jenis alamat (data center / residensial / mobile), konsistensi header, jejak TLS, tanda-tanda perilaku. Deteksi bersifat berlapis — heuristik ditambah ML, dan sebagian besar keputusan berasal dari pembelajaran mesin.

Konsekuensi praktis: kumpulan dan jejak Anda dinilai bukan oleh situs, tetapi oleh jaringan. Jika terdeteksi di satu sumber — sinyal reputasi sudah diperhitungkan pada permintaan berikutnya ke yang lain. Di dunia di mana sembilan dari sepuluh situs Eropa berada di jaringan ini, "beralih ke target lain dan menunggu" tidak lagi menjadi strategi.

IP residensial tidak lagi menjadi jaminan

Logika lama "mengambil alamat residensial — lewat seperti manusia" terhambat oleh fakta bahwa penyedia filter telah lama menangkap trik ini. Cloudflare secara publik menggambarkan model terpisah untuk bot yang menggunakan proxy residensial: awalnya mencoba tanda jaringan (hop tambahan, latensi), tetapi menolak karena false positives pada internet satelit, dan beralih ke analisis perilaku — lonjakan aktivitas yang khas pada alamat IP. Dalam publikasi mereka juga disajikan skala fenomena yang mereka lihat: sekitar 17 juta IP unik per jam, yang terlibat dalam serangan melalui proxy residensial, 45 ribu ASN dan 237 negara dan wilayah (angka ini berlaku untuk Maret 2024, perusahaan tidak memberikan angka yang lebih baru). Akurasi yang dinyatakan untuk klasifikasi serangan terdistribusi terhadap salah satu klien — 95%, peningkatan deteksi bot dari jaringan cloud — 20%.

Detail penting dari sana: model secara sadar tidak dibangun di atas pemblokiran IP — agar tidak mengeluarkan pengguna yang sah dari jaringan yang sama. Ini adalah kabar baik untuk lalu lintas yang sah dari alamat residensial dan kabar buruk bagi mereka yang berharap bahwa "rumah" dengan sendirinya memberikan lampu hijau. Yang bekerja bukanlah jenis alamat, tetapi kombinasi "jenis alamat + perilaku + jejak". Analisis mendetail tentang perbedaan antara dinding telah kami lakukan dalam perbandingan sistem anti-bot Cloudflare, DataDome, Akamai, dan Kasada — sekarang saatnya untuk kembali dengan catatan bahwa bobot di baris pertama di Eropa telah menjadi tidak proporsional banyak.

Sisi lain: ketika satu jatuh — semuanya jatuh

Monokultur memiliki sisi kedua, bukan tentang pemblokiran, tetapi tentang ketersediaan. Satu setengah tahun terakhir memberikan tiga episode yang menunjukkan:

1. 18 November 2025 — kegagalan global yang diperkirakan mempengaruhi sekitar setiap halaman web kelima dan sepertiga dari 10.000 situs dan layanan paling populer. Penyebab menurut analisis perusahaan itu sendiri: perubahan hak di kluster ClickHouse menyebabkan duplikasi baris dalam file fitur yang digunakan oleh model ML untuk penilaian bot. Ironisnya: mekanisme yang menentukan apakah Anda manusia atau tidak telah menyebabkan sebagian besar internet terhenti.
2. 5 Desember 2025 — kegagalan dari 8:47 UTC selama sekitar 25 menit, mempengaruhi subset klien yang mencakup sekitar 28% dari seluruh lalu lintas HTTP yang melewati jaringan.
3. 20 Februari 2026 — pada 17:48 UTC, sebagian klien yang menggunakan BYOIP (rentang IP mereka sendiri), rute ditarik kembali melalui BGP karena perubahan dalam proses onboarding alamat.

Frasa penulis penelitian di sini tepat: ketika satu penyedia berdiri di depan sebagian besar pasar, kesalahannya berhenti menjadi masalahnya dan menjadi masalah semua orang secara bersamaan. Untuk pipeline pengumpulan data, ini berarti bahwa "situs target jatuh" dan "seluruh wilayah jatuh" sekarang sulit dibedakan — dan peringatan yang disetel untuk domain tertentu menjadi tidak akurat.

Apa yang harus dilakukan secara praktis

Di bawah ini adalah apa yang benar-benar berubah dalam proses kerja, jika kita menganggap monokultur filter sebagai kenyataan.

1. Uji kombinasi tidak hanya di satu situs. Jika jejak Anda lolos di tiga sumber — Anda kemungkinan besar telah memeriksa filter yang sama tiga kali. Ambil sumber untuk CloudFront, untuk Fastly, untuk Akamai, dan tanpa CDN sama sekali, jika tidak, sampling tidak membuktikan apa-apa.
2. Pisahkan kumpulan berdasarkan proyek, bukan berdasarkan situs. Karena reputasi dinilai oleh jaringan, "kumpulan terpisah untuk setiap domain" tidak mengisolasi apa pun. Isolasi masuk akal pada tingkat proyek dan profil: satu proyek — kumpulan alamatnya sendiri, set jejaknya sendiri, tempo sendiri.
3. Perhatikan jenis dan asal alamat. ASN dan kategori alamat — pintu masuk langsung ke penilaian. Untuk tujuan sensitif, proxy residensial dan alamat mobile masuk akal; tugas teknis massal (memeriksa ketersediaan, API sendiri, bekerja dengan platform tanpa anti-bot yang ketat) lebih murah dan lebih jujur untuk ditangani dengan data center proxy, tanpa membuang lalu lintas mahal secara sia-sia.
4. Jangan bakar subnet. Model perilaku menangkap lonjakan aktivitas pada alamat. Tempo yang stabil pada kumpulan yang luas bertahan lebih baik dalam penilaian daripada serangan agresif pendek dari yang sempit.
5. Atur jejak secara keseluruhan. Jejak TLS, urutan dan komposisi header, versi HTTP, perilaku JS — dinilai bersama. IP residensial dengan jejak klien HTTP yang telanjang memberikan hasil yang lebih buruk daripada alamat data center yang rapi dengan tumpukan browser yang jujur.
6. Pisahkan "kami diblokir" dan "mereka mengalami kegagalan". Aturan sederhana: saat terjadi peningkatan kesalahan secara massal, pertama-tama periksa apakah semuanya jatuh sekaligus di beberapa tujuan yang tidak terkait dan apa yang ditunjukkan oleh halaman status penyedia. Retry pada saat kegagalan global — adalah cara untuk membakar kumpulan tanpa alasan.
7. Punya rencana B untuk hari ketika filter jatuh. Antrian tugas yang dapat menunggu dan mengambil yang terlewat lebih mahal dalam pengembangan, tetapi dapat bertahan 25 menit ketidaktersediaan tanpa kehilangan data.

Kesimpulan

Angka 89,6% — bukan tentang bahwa Cloudflare buruk, dan bukan tentang bahwa web Eropa telah menutup diri. Ini tentang bahwa keragaman tujuan tidak lagi berarti keragaman hambatan. Satu penilaian, satu model, satu basis reputasi — dan, sebagai konsekuensi, satu mode kegagalan umum: baik ketika Anda dianggap sebagai bot, maupun ketika penyedia sendiri menjatuhkan rute.

Kesimpulan untuk praktiknya membosankan, tetapi fungsional: berhenti mengoptimalkan penghindaran "untuk situs" dan mulai mengoptimalkan perilaku — kualitas alamat, tempo yang stabil, jejak yang konsisten, diagnosis kegagalan yang jujur. Ini adalah satu-satunya hal yang bekerja dengan baik baik di sisi 89,6%, maupun di sisi ini.