Cloudflare 's Mayor November 18 / Ringkasan

Pada tanggal 18 November 2025, sebagian besar internet tumbang.
Jika Anda membuka ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase, atau situs-situs kecil lainnya yang tak terhitung jumlahnya, Anda akan disambut dengan halaman kesalahan 5xx bermerek Cloudflare-atau situs-situs tersebut tidak dapat dimuat sama sekali. Apa yang pada awalnya terlihat seperti momen besar "internet rusak" ternyata adalah sesuatu yang lebih halus dan, dalam beberapa hal, lebih mengkhawatirkan: bug yang ditimbulkan sendiri di dalam infrastruktur Cloudflare.

Di bawah ini adalah penelusuran mendetail tentang apa yang terjadi pada pemadaman Cloudflare kemarin (18 November 2025), mengapa hal itu terjadi, siapa saja yang terdampak, dan pelajaran apa yang dapat diambil oleh tim infrastruktur darinya.

Apa yang sebenarnya terjadi kemarin?

Pada hari Selasa, 18 November 2025, sekitar pagi hari UTC, Cloudflare mulai mengembalikan kesalahan server HTTP 5xx dalam jumlah besar untuk lalu lintas yang melewati jaringannya. Bagi pengguna akhir, hal itu berarti halaman "Internal Server Error" atau "Gateway Error" saat mencoba mengakses banyak situs web dan aplikasi populer.

Menurut blog Cloudflare sendiri setelah kejadian tersebut, pemadaman tersebut:

• Mulai berdampak pada lalu lintas HTTP pelanggan pada pukul 11:28 UTC

• Terjadi kesalahan 5xx yang meluas di seluruh CDN inti dan layanan keamanan

• Melakukan langkah mitigasi utama sekitar pukul 13:05-14:30 UTC

• Mengembalikan volume kesalahan 5xx ke garis dasar pada pukul 17:06 UTC Blog Cloudflare

Cloudflare sendiri menggambarkannya sebagai pemadaman terburuk sejak 2019, karena tidak hanya memengaruhi satu fitur atau dasbor - ini mengganggu lapisan proxy inti yang merutekan sebagian besar lalu lintas pelanggan melalui jaringannya. Blog Cloudflare

Pemantauan pihak ketiga mendukung hal ini. Cisco ThousandEyes melihat pemadaman global yang memengaruhi Cloudflare, dengan waktu habis dan kesalahan 5xx pada layanan seperti X, OpenAI (ChatGPT), dan Anthropic, sementara jalur jaringan itu sendiri terlihat sehat. Hal ini menunjukkan dengan jelas adanya kegagalan layanan backend, bukan masalah pada tingkat ISP atau perutean. ThousandEyes

Siapa saja yang terkena dampaknya?

Karena Cloudflare berada di depan sebagian besar internet (sekitar 20% situs web mengandalkan Cloudflare untuk kinerja dan keamanan), radius ledakan sangat besar. AP News+1

Di antara layanan yang dilaporkan terkena dampak:

• ChatGPT / OpenAI

• X (sebelumnya Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends dan platform game lainnya

• Berbagai situs angkutan umum dan pemerintah, termasuk New Jersey Transit dan sistem digital kereta api SNCF Prancis AP News+1

Pelacak pemadaman seperti Downdetector mencatat ribuan laporan masalah yang terjadi secara bersamaan pada saat puncaknya. Reuters melaporkan sekitar 5.000 pengguna yang terkena dampak untuk X saja pada satu titik, sebelum jumlah tersebut menurun seiring dengan perbaikan yang diluncurkan. Reuters

Dari sudut pandang pengguna, hal ini terlihat sebagai:

• Situs tidak dapat dimuat sama sekali

• Alur masuk yang macet atau gagal (terutama jika melibatkan Cloudflare Access atau Turnstile)

• API merespons sesekali atau dengan kesalahan 5xx

• Dasbor dan panel admin mengalami waktu habis

Dengan kata lain: sebagian besar internet "terasa down", meskipun akar penyebabnya terkonsentrasi pada sistem internal penyedia tunggal.

Cara kerja Cloudflare secara normal (secara sederhana)

Untuk memahami mengapa pemadaman ini begitu parah, ada baiknya kita mengetahui jalur kasar permintaan melalui jaringan Cloudflare.

Cloudflare bertindak sebagai CDN proxy terbalik dan lapisan keamanan:

1. Peramban atau aplikasi Anda terhubung ke Cloudflare, bukan langsung ke situs asal.

2. Cloudflare menghentikan TLS dan HTTP di ujungnya.

3. Permintaan mengalir ke sistem proksi inti Cloudflare, yang disebut FL ("Frontline") dan generasi terbarunya FL2.

4. Proksi inti itu:

   • Menerapkan aturan WAF (firewall aplikasi web)

   • Menjalankan model Manajemen Bot

   • Menangani perlindungan DDoS, caching, jalan keluar ke asal

   • Merutekan lalu lintas ke produk internal lainnya seperti Workers, R2, Access, dll. Blog Cloudflare

Dalam operasi normal, arsitektur ini sangat tangguh: jika satu pusat data mengalami masalah, lalu lintas dialihkan melalui pusat data lainnya; perubahan konfigurasi dilakukan dengan hati-hati; masing-masing fitur harus gagal dengan cara yang terkendali.

Pemadaman kemarin sangat buruk karena kegagalan berada di dalam jalur proxy umum itu sendiri, dan digabungkan dengan file konfigurasi yang sering didorong ke seluruh dunia dan secara otomatis.

Akar penyebabnya: berkas fitur manajemen bot yang rusak

Penjelasan resmi Cloudflare menunjuk pada satu penyebab utama:
file konfigurasi fitur yang digunakan oleh sistem Manajemen Bot mereka. Blog Cloudflare

Inilah rangkaian kejadiannya dalam bahasa yang sederhana:

1. Manajemen Bot menggunakan "file fitur"

   • Model deteksi bot Cloudflare bergantung pada sekumpulan "fitur" - sinyal tentang setiap permintaan yang digunakan untuk memutuskan apakah permintaan tersebut berasal dari manusia atau bot.

   • Fitur-fitur ini digabungkan ke dalam file konfigurasi yang dibuat ulang setiap beberapa menit dan diluncurkan secara global, sehingga Cloudflare dapat beradaptasi dengan cepat terhadap pola serangan baru. Blog Cloudflare

2. Perubahan dalam perilaku kueri ClickHouse

   • File fitur dihasilkan oleh kueri terhadap basis data ClickHouse.

   • Cloudflare melakukan perubahan sekitar pukul 11:05 UTC untuk meningkatkan keamanan dan izin untuk kueri terdistribusi - memungkinkan pengguna untuk melihat metadata tidak hanya dari skema default tetapi juga dari tabel r0 yang mendasarinya. Blog Cloudflare

   • Kueri yang membangun daftar fitur tidak memfilter berdasarkan nama basis data; tiba-tiba kueri tersebut mulai mendapatkan kolom duplikat dari tabel default dan r0, yang secara efektif menggandakan jumlah baris fitur.

3. File fitur meledak dalam ukuran

   • Modul Manajemen Bot memiliki batas yang tegas tentang berapa banyak fitur yang akan diterima (diatur ke 200, jauh di atas ~60 fitur yang biasanya digunakan).

   • Ketika file yang baru dibuat melebihi batas tersebut, modul akan mencapai batas tersebut dan panik, karena kesalahan yang tidak tertangani dalam kode Rust yang menggunakan Result::unwrap() pada nilai kesalahan. Blog Cloudflare

4. Layanan proxy inti mulai mengembalikan kesalahan 5xx

   • Karena Bot Management terintegrasi ke dalam jalur proxy inti, kepanikan muncul sebagai respons HTTP 5xx untuk setiap lalu lintas yang bergantung pada modul tersebut.

   • Pada mesin FL2 yang baru, pelanggan melihat kesalahan 5xx secara eksplisit.

   • Pada mesin FL yang lebih lama, skor bot secara diam-diam menjadi nol, yang dapat menyebabkan positif palsu dalam aturan pemblokiran bot. Blog Cloudflare

5. Bagian yang sangat buruk: file terus beralih antara "baik" dan "buruk"

   • Cluster ClickHouse diperbarui secara bertahap, dan file fitur dibuat ulang setiap lima menit.

   • Terkadang kueri berjalan pada node yang diperbarui (menghasilkan file yang buruk), terkadang pada node yang tidak diperbarui (menghasilkan file yang baik).

   • Itu berarti untuk sementara waktu, jaringan Cloudflare terombang-ambing antara operasi normal dan kegagalan karena versi file yang berbeda disebarkan. Blog Cloudflare

Osilasi ini membuat situasi menjadi sangat membingungkan secara internal. Pada awalnya, tim Cloudflare menduga adanya serangan DDoS besar-besaran karena pola kesalahannya tidak terlihat seperti kerusakan perangkat lunak yang sederhana. Bahkan halaman status Cloudflare, yang dihosting di luar infrastruktur mereka sendiri, sempat menunjukkan kesalahan - sebuah kebetulan yang semakin memicu kecurigaan akan adanya serangan eksternal. Blog Cloudflare+1

Hanya setelah mereka menyadari bahwa faktor penyebabnya adalah file fitur bot, barulah gambarannya menjadi jelas.

Garis waktu kejadian

Berdasarkan laporan postmortem Cloudflare dan laporan pihak ketiga, kami dapat menyusun garis waktu kasar untuk tanggal 18 November 2025: BlogCloudflare + 2RibuMata + 2

• 11:05 UTC - Perubahan kontrol akses basis data diterapkan di ClickHouse.

• 11:20-11:30 UTC - Versi buruk dari file fitur Manajemen Bot mulai dibuat dan disebarkan.

• 11:28 UTC - Dampak pada pelanggan pertama: peningkatan kesalahan HTTP 5xx yang terlihat pada lalu lintas pelanggan.

• 11:30-11:32 UTC - Alat pemantauan eksternal dan pengujian otomatis mulai mendeteksi kegagalan yang terputus-putus.

• 11:35 UTC - Cloudflare membuka panggilan insiden internal; investigasi dimulai.

• ~11:48 UTC - Cloudflare menerbitkan pembaruan status yang mengonfirmasi adanya insiden. Kirim ulang

• 11:30-13:05 UTC - Tim fokus pada apa yang tampak sebagai perilaku Workers KV yang terdegradasi dan menyelidiki berbagai kemungkinan penyebabnya (termasuk skenario serangan).

• 13:05 UTC - Mitigasi utama: Workers KV dan Cloudflare Access dialihkan untuk mem-bypass proxy inti; dampaknya berkurang. Blog Cloudflare

• 14:30 UTC - Akar penyebab teridentifikasi; pembuatan dan penyebaran file fitur yang buruk dihentikan. File konfigurasi yang dikenal baik dimasukkan secara manual dan proxy inti dimulai ulang. Sebagian besar lalu lintas inti kembali normal. Blog Cloudflare

• 14:40-15:30 UTC - Masalah dasbor dan login tetap ada karena Turnstile dan penumpukan upaya otentikasi menciptakan lonjakan beban sekunder. Blog Cloudflare

• 17:06 UTC - Tingkat kesalahan kembali ke titik awal; Cloudflare menyatakan sistem sepenuhnya normal. Blog Cloudflare

Dari sudut pandang pengguna, pemadaman terasa paling parah pada pagi hingga sore hari UTC, meskipun waktu dampak yang tepat berbeda-beda menurut wilayah dan produk Cloudflare yang digunakan oleh setiap layanan.

Mengapa pemadaman ini sangat penting

Risiko sentralisasi

Cloudflare adalah bagian dari sekumpulan kecil penyedia infrastruktur internet pusat, di samping platform cloud utama (AWS, Azure, GCP) dan CDN besar lainnya. Ketika salah satu dari pemain ini gagal, dampaknya sangat luas dan sering kali tidak terlihat.

Pemadaman ini:

• Tidak berasal dari kesalahan perutean BGP atau terputusnya kabel ISP.

• Bukan berasal dari serangan jahat (meskipun ada kecurigaan awal).

• Berasal dari satu konfigurasi dan bug batasan dalam komponen internal.

Hal ini penting karena menunjukkan bagaimana sistem yang kompleks dan terkoneksi dengan baik dapat gagal secara besar-besaran bahkan tanpa gangguan eksternal. Ketika banyak organisasi membangun di atas penyedia yang sama, penyedia tersebut secara de-facto menjadi bagian penting secara sistemik dari internet.

Ketergantungan "lunak" juga merugikan

Beberapa layanan yang terkena dampak tidak hanya menggunakan Cloudflare sebagai CDN yang bodoh. Mereka memang menggunakan Cloudflare:

• Menggunakan Cloudflare Access untuk autentikasi dan akses tanpa kepercayaan.

• Menggunakan Workers KV sebagai bagian dari pesawat kontrol internal.

• Mengandalkan Turnstile untuk login yang tahan terhadap bot. Blog Cloudflare+1

Ketika produk-produk tersebut gagal, bukan hanya konten situs web yang mengalami kegagalan - login, fungsi admin, dan API internal juga rusak. Hal ini membuat pemulihan menjadi lebih kompleks: halaman status, peralatan insiden, atau UI admin Anda mungkin juga bergantung pada penyedia yang baru saja gagal.

Apa yang dikatakan Cloudflare akan berubah

Blog Cloudflare menguraikan beberapa langkah remediasi yang telah dilakukan perusahaan untuk mengurangi risiko terulangnya hal serupa: Blog Cloudflare

1. Memperkuat konsumsi file konfigurasi yang dibuat secara otomatis
   Perlakukan konfigurasi yang dibuat secara internal dengan skeptisisme dan validasi yang sama dengan input yang disediakan pengguna, termasuk skema yang ketat dan pengecekan ukuran sebelum peluncuran.

2. Tombol pemutus yang lebih global
   Memudahkan penonaktifan modul internal yang bermasalah dengan cepat (seperti Manajemen Bot) di seluruh jaringan, sehingga modul tersebut gagal dibuka alih-alih membuat panik seluruh jalur proxy.

3. Melindungi sumber daya sistem dari badai kesalahan
   Pastikan bahwa core dump, metadata debug, dan alat bantu pengamatan tidak dapat membebani CPU dan memori ketika kesalahan mulai melonjak.

4. Tinjau mode kegagalan di seluruh modul proxy inti
   Audit secara sistematis bagaimana setiap modul internal berperilaku di bawah input atau konfigurasi yang tidak terduga, dan pastikan degradasi yang lembut, bukan kegagalan global.

5. Sempurnakan peluncuran dan isolasi
   Meskipun tidak dijelaskan secara mendetail, insiden ini menunjukkan bahwa Cloudflare kemungkinan akan mengelompokkan lebih lanjut bagaimana konfigurasi baru dan perilaku DB menyebar, untuk mengurangi kemungkinan satu perubahan buruk memengaruhi seluruh armada.

Mereka juga membingkai insiden tersebut sebagai kegagalan mutlak dari ekspektasi ketahanan mereka, menyebutnya "tidak dapat diterima" dan secara eksplisit mengakui rasa sakit yang ditimbulkannya pada pelanggan dan pengguna internet biasa. Blog Cloudflare

Pelajaran untuk tim infrastruktur & SRE

Meskipun Anda tidak menjalankan sesuatu yang besar seperti Cloudflare, ada beberapa pelajaran desain dan operasional yang sangat praktis dalam pemadaman ini:

Perlakukan konfigurasi internal seperti masukan yang tidak terpercaya

Sangat mudah untuk mengasumsikan bahwa konfigurasi yang dibuat "kita sendiri" selalu benar. Kemarin menunjukkan mengapa hal itu berbahaya:

• Selalu memvalidasi ukuran, bentuk, dan batas file konfigurasi sebelum menerapkannya.

• Pertimbangkan penerapan konfigurasi kenari ke sebagian kecil lalu lintas atau node terlebih dahulu, dengan rollback otomatis pada anomali.

• Pertahankan batas atas yang ketat dan pemutus arus di sekitar jumlah fitur, pra-alokasi memori, dan penggunaan CPU.

Desain untuk kegagalan parsial yang anggun

Satu bug dalam modul Manajemen Bot seharusnya tidak dapat membuat panik seluruh jalur proksi:

• Setel secara default ke gagal-terbuka vs gagal-tertutup pada beberapa lapisan keamanan ketika alternatifnya adalah pemadaman total.

• Buatlah tombol pemutus yang jelas dan teruji untuk fitur-fitur non-inti.

• Pastikan sub-sistem yang penting (auth, halaman status, perkakas insiden) bisa beroperasi dalam mode terdegradasi atau melalui rute alternatif.

Amati sinyal yang tepat

Osilasi antara "konfigurasi yang baik" dan "konfigurasi yang buruk" setiap lima menit membuat sinyal terlihat seperti lalu lintas serangan atau perilaku eksternal yang berisik:

• Pastikan Anda memiliki korelasi per-versi atau per-konfigurasi dalam pipeline pengamatan Anda.

• Buat dasbor yang membuat perubahan konfigurasi terlihat jelas secara visual di atas grafik kesalahan.

• Sertakan pengujian sintetis yang kuat dari sudut pandang eksternal, sehingga Anda dapat dengan cepat membedakan kegagalan internal dari masalah jaringan/jalur.

Jangan menaruh semua telur Anda dalam satu keranjang infra

Untuk organisasi yang menggunakan Cloudflare:

• Pertimbangkan pengaturan multi-CDN untuk properti yang benar-benar penting.

• Hindari membuat halaman status Anda sepenuhnya bergantung pada penyedia yang sama dengan tumpukan utama Anda (Cloudflare melakukan ini, tetapi ada masalah kebetulan dengan host halaman status mereka kemarin yang membingungkan lebih lanjut). Blog Cloudflare+1

• Pikirkan dua kali sebelum menggabungkan otentikasi, bidang kontrol API, dan pengiriman frontend Anda ke vendor yang sama tanpa jalur fallback.

Gambaran yang lebih besar

Dalam beberapa bulan terakhir ini, kita telah melihat pemadaman besar-besaran di Microsoft Azure, Amazon Web Services, dan sekarang Cloudflare, yang semuanya untuk sementara waktu membuat sebagian besar layanan konsumen dan perusahaan menjadi offline. AP News+ 2 TheWashington Post+ 2

Polanya sudah jelas:

• Internet semakin bergantung pada segelintir penyedia infrastruktur raksasa.

• Pemadaman sering kali terjadi dengan sendirinya, yang disebabkan oleh perubahan internal yang kompleks, bukan karena serangan eksternal.

• Bahkan penyedia dengan praktik SRE kelas dunia pun masih bisa tersandung oleh interaksi yang tidak terduga antara konfigurasi, perilaku basis data, dan batas-batas yang dikodekan.

Insiden Cloudflare kemarin adalah pengingat yang jelas bahwa "cloud" bukanlah sihir. Pada dasarnya, ini masih merupakan perangkat lunak yang ditulis oleh manusia, tunduk pada kelas bug yang sama dengan aplikasi lain - hanya saja dengan jumlah orang yang bergantung padanya jauh lebih banyak.

Bagi para pengguna, kejadian ini akan diingat sebagai "pagi itu ketika X dan ChatGPT tidak bisa dimuat."
Bagi para insinyur, kejadian ini mungkin akan dipelajari sebagai contoh buku teks tentang bagaimana bug konfigurasi yang tidak kentara dalam sistem terdistribusi inti dapat menyebar menjadi peristiwa internet global.