Penjelasan Cloudflare Down 18 Sept 2025 Sederhana & Teknis

“Bukan serangan hacker canggih, ternyata lumpuhnya ribuan website besar kemarin disebabkan oleh satu kesalahan internal yang sepele namun mematikan. Inilah penjelasan lengkap kenapa ‘satpam’ internet dunia bisa tumbang seketika.”

Kemarin siang, tepatnya tanggal 18 November 2025, kita dipaksa ‘puasa’ internet sebentar gara-gara layanan raksasa sekelas ChatGPT, X (Twitter), dan game online mendadak tidak bisa diakses. Banyak yang mengira ini ulah hacker canggih, padahal fakta di lapangannya jauh dari itu. Di artikel ini, saya akan meluruskan apa yang sebenarnya terjadi pada Cloudflare, menjelaskan kronologinya dengan bahasa yang mudah dimengerti, serta mengupas sisi teknis kenapa ‘satpam’ internet dunia ini bisa tumbang hanya gara-gara satu file yang salah.

🥺 Gara-gara Apa Sih? (Bukan Di-Hack Kok!)

Tenang, ini bukan serangan hacker atau orang jahat ya. Ini murni kesalahan teknis dari tim Cloudflare-nya sendiri. Ceritanya gini:

Salah Setting: Tim Cloudflare lagi ngerubah settingan izin di database mereka. Niatnya baik mau update biasa.
File Jadi “Gendut”: Gara-gara perubahan itu, ada satu sistem yang tugasnya ngatur “Bot” (biar website gak diserang robot) jadi error. Sistem ini malah bikin satu file konfigurasi yang isinya dobel-dobel dan jadi gede banget.
Sistem Kaget: Nah, karena filenya kegedean (melebihi batas yang bisa ditampung), sistem utamanya Cloudflare jadi keberatan, “keselek”, terus akhirnya crash (mati) deh.
Efek Domino: Karena sistem utamanya mati, semua website yang “nitip” dijagain sama Cloudflare jadi ikutan nggak bisa diakses.

🛠️ Terus Solusinya Gimana?

Pas mereka sadar ini bukan serangan hacker tapi karena file yang “gendut” tadi:

Mereka stop penyebaran file yang error itu.
Mereka balikin (rollback) ke file versi lama yang masih sehat.
Terus mereka restart sistemnya.

Secara teknis, insiden Cloudflare tanggal 18 November 2025 ini adalah kegagalan pada Control Plane yang berdampak fatal ke Data Plane.

Berikut rincian teknis bedah kasusnya:

1. Root Cause: Masalah Validasi Skema Konfigurasi

Masalah bermula dari deployment aturan baru pada sistem Bot Management. Engineer melakukan perubahan pada aturan firewall.

Logic Error: Kode yang seharusnya membuat satu aturan sederhana, mengalami bug dalam logikanya yang menyebabkan rekursi atau duplikasi berulang.
Payload Size: Akibatnya, file konfigurasi (biasanya dalam format JSON atau Protocol Buffers) yang harusnya berukuran sekian kilobyte, membengkak secara eksponensial menjadi ukuran megabyte yang sangat besar.

2. Mekanisme Propagasi: Quicksilver

Cloudflare menggunakan sistem database key-value terdistribusi yang sangat cepat bernama Quicksilver. Sistem ini tugasnya menyebarkan perubahan setting ke seluruh dunia dalam hitungan milidetik.

The Incident: Karena Quicksilver sangat efisien, file konfigurasi yang “rusak” dan berukuran raksasa tadi tersebar ke ribuan server (edge nodes) di seluruh dunia hampir secara instan. Tidak ada canary deployment (penyebaran bertahap) yang menahan ini di tahap awal.

3. Failure State: Buffer Overflow & Daemon Crash

Ketika file konfigurasi raksasa ini sampai di server lokal (Edge):

Parsing Failure: Daemon (proses latar belakang) yang bertugas membaca konfigurasi ini mencoba memuat file tersebut ke dalam memori (RAM).
OOM / Panic: Karena ukurannya melebihi batas buffer yang dialokasikan atau melebihi batas waktu pemrosesan (timeout), proses tersebut mengalami Panic (istilah di bahasa Go/Rust saat program crash) atau Out of Memory (OOM).
Looping: Sistem watchdog (penjaga) mencoba me-restart proses yang mati. Tapi begitu hidup, proses itu membaca file konfigurasi yang rusak lagi, lalu crash lagi. Terjadilah Boot Loop.

4. Dampak ke Traffic (BGP Withdrawal)

Karena proses utamanya crash terus-menerus, server-server Cloudflare dianggap “mati” secara kesehatan jaringan (health check failed).

Secara otomatis, router akan menarik rute BGP (Border Gateway Protocol).
Akibatnya, request dari user (kita) tidak menemukan jalan ke server tujuan, sehingga muncul error timeout atau 502 Bad Gateway.

5. Remediation (Perbaikan)

Tim Site Reliability Engineering (SRE) melakukan langkah berikut:

Kill Switch: Mematikan mekanisme propagasi Quicksilver agar file rusak tidak terus dikirim.
Revert/Rollback: Mengembalikan state konfigurasi ke versi terakhir yang stabil (Last Known Good Configuration).
Cold Restart: Memaksa daemon di seluruh dunia untuk membuang cache konfigurasi lokal dan mengambil konfigurasi lama yang sudah bersih.

Kesimpulan Teknisnya: Ini adalah klasik kasus “Bad Config Push”. Secanggih apa pun infrastrukturnya, kalau input konfigurasinya merusak parser, seluruh infrastruktur global bisa lumpuh (Single Point of Failure pada mekanisme distribusi konfigurasi).