Cloudflare'in 18 Kasım'daki Büyük Kesintisi - Özet

18 Kasım 2025'te internetin büyük bir bölümü çöktü.
ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase veya sayısız küçük siteyi açtığınızda Cloudflare markalı 5xx hata sayfasıyla karşılaştınız ya da siteler hiç yüklenmedi. İlk başta bir başka büyük "internet bozuldu" anı gibi görünen şeyin daha ince ve bazı açılardan daha endişe verici bir şey olduğu ortaya çıktı: Cloudflare'in kendi altyapısının derinliklerinde kendi kendine oluşan bir hata.

Aşağıda, dünkü Cloudflare kesintisinde (18 Kasım 2025) neler olduğu, neden yaşandığı, kimleri etkilediği ve altyapı ekiplerinin bundan ne gibi dersler çıkarması gerektiği ayrıntılı bir şekilde ele alınmaktadır.

Dün gerçekte ne oldu?

Cloudflare, 18 Kasım 2025 Salı günü, UTC'ye göre sabah geç saatlerde, ağından geçen trafik için büyük miktarlarda HTTP 5xx sunucu hatası döndürmeye başladı. Son kullanıcılar için bu, birçok popüler web sitesine ve uygulamaya erişmeye çalışırken "Dahili Sunucu Hatası" veya "Ağ Geçidi Hatası" sayfaları anlamına geliyordu.

Cloudflare'in olay sonrası kendi bloguna göre, kesinti:

• Müşteri HTTP trafiğini 11:28 UTC'de etkilemeye başladı

• Çekirdek CDN ve güvenlik hizmetlerinde yaygın 5xx hataları görüldü

• UTC ile 13:05-14:30 civarında önemli hafifletme adımları atıldı

• 17:06 UTC' ye kadar 5xx hata birimini ana hatta döndürdü The Cloudflare Blog

Cloudflare'in kendisi bunu 2019'dan bu yana en kötü kesintisi olarak tanımladı, çünkü sadece bir özelliği veya kontrol panelini etkilemedi - müşteri trafiğinin çoğunu ağı üzerinden yönlendiren çekirdek proxy katmanını bozdu. Cloudflare Blogu

Üçüncü taraf izleme bunu destekledi. Cisco ThousandEyes, X, OpenAI (ChatGPT) ve Anthropic gibi hizmetlerde zaman aşımları ve 5xx hataları ile Cloudflare'i etkileyen küresel bir kesinti görürken, ağ yollarının kendileri sağlıklı görünüyordu. Bu da İSS düzeyinde veya yönlendirme sorununa değil, arka uç hizmet arızasına işaret ediyor. ThousandEyes

Kimler etkilendi?

Cloudflare internetin büyük bir bölümünün önünde yer aldığından ( web sitelerinin yaklaşık %20 'si performans ve güvenlik için Cloudflare'e güveniyor), patlama yarıçapı çok büyüktü. AP Haberleri+1

Etkilendiği bildirilen hizmetler arasında:

• ChatGPT / OpenAI

• X (eski adıyla Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends ve diğer oyun platformları

• New Jersey Transit ve Fransa'nın SNCF demiryolu dijital sistemleri de dahil olmak üzere çeşitli toplu taşıma ve hükümet siteleri AP News+1

Downdetector gibi kesinti takipçileri en yoğun dönemde binlerce eş zamanlı sorun raporu kaydetti. Reuters, bir noktada yalnızca X için yaklaşık 5.000 etkilenen kullanıcı bildirmiş, düzeltmeler yayınlandıkça sayılar azalmıştır. Reuters

Bir kullanıcının bakış açısından bu durum şu şekilde ortaya çıktı:

• Siteler hiç yüklenmiyor

• Oturum açma akışlarının takılması veya başarısız olması (özellikle Cloudflare Access veya Turnike'nin dahil olduğu durumlarda)

• API'lerin aralıklı olarak veya 5xx hatalarıyla yanıt vermesi

• Gösterge tabloları ve yönetici panelleri zaman aşımına uğruyor

Başka bir deyişle: temel neden tek bir sağlayıcının dahili sistemlerinde yoğunlaşmış olsa da, internetin büyük bir kısmı "çöktü".

Cloudflare normalde nasıl çalışır (basit terimlerle)

Bu kesintinin neden bu kadar şiddetli olduğunu anlamak için, Cloudflare'in ağından geçen bir isteğin kaba yolunu bilmek yardımcı olur.

Cloudflare bir ters proxy CDN ve güvenlik katmanı olarak görev yapar:

1. Tarayıcınız veya uygulamanız doğrudan kaynak site yerine Cloudflare'e bağlanır.

2. Cloudflare, TLS ve HTTP'yi kendi ucunda sonlandırır.

3. İstekler Cloudflare'in FL ("Frontline") ve daha yeni nesil FL2 adı verilen çekirdek proxy sistemine akar.

4. Bu çekirdek proxy:

   • WAF (web uygulaması güvenlik duvarı) kurallarını uygular

   • Bot Yönetimi modellerini çalıştırır

   • DDoS koruması, önbelleğe alma, kaynağa çıkış işlemlerini gerçekleştirir

   • Trafiği Workers, R2, Access vb. gibi diğer dahili ürünlere yönlendirir. Cloudflare Blogu

Normal işleyişte bu mimari son derece dayanıklıdır: bir veri merkezinde sorun olması halinde trafik diğerleri üzerinden yönlendirilir; yapılandırma değişiklikleri dikkatle uygulanır; münferit özelliklerin farklı şekillerde arızalanması gerekir.

Dünkü kesinti tam olarak kötüydü çünkü arıza ortak proxy yolunun içindeydi ve dünya çapında sık sık ve otomatik olarak itilen bir yapılandırma dosyasıyla sıkı sıkıya bağlıydı.

Temel neden: hileli bir bot yönetim özelliği dosyası

Cloudflare'in resmi açıklaması önemli bir suçluya işaret ediyor:
Bot Yönetim sistemi tarafından kullanılan bir özellik yapılandırma dosyası. Cloudflare Blogu

İşte sade bir dille olaylar zinciri:

1. Bot Yönetimi bir "özellik dosyası" kullanır

   • Cloudflare'in bot tespit modeli bir dizi "özelliğe" dayanır - insan mı yoksa bot mu olduğuna karar vermek için kullanılan her istekle ilgili sinyaller.

   • Bu özellikler, birkaç dakikada bir yeniden oluşturulan ve küresel olarak kullanıma sunulan bir yapılandırma dosyasında bir araya getirilmiştir, böylece Cloudflare yeni saldırı modellerine hızla uyum sağlayabilir. Cloudflare Blog

2. ClickHouse sorgu davranışında bir değişiklik

   • Özellik dosyası, bir ClickHouse veritabanına karşı sorgular tarafından oluşturulur.

   • Cloudflare, dağıtılmış sorgular için güvenlik ve izinleri iyileştirmek amacıyla UTC saatiyle 11:05 civarında bir değişiklik yaptı ve kullanıcıların meta verileri yalnızca varsayılan bir şemadan değil, aynı zamanda temel r0 tablolarından da görmelerine olanak tanıdı. Cloudflare Blogu

   • Özellik listesini oluşturan sorgu veritabanı adına göre filtreleme yapmadı; aniden hem varsayılan hem de r0'dan yinelenen sütunlar almaya başladı ve özellik satırlarının sayısını etkili bir şekilde iki katına çıkardı.

3. Özellik dosyası boyut olarak patladı

   • Bot Yönetimi modülünün kabul edeceği özellik sayısı konusunda katı bir sınırı vardır (200 olarak ayarlanmıştır, normalde kullanımda olan ~60'ın çok üzerindedir).

   • Yeni oluşturulan dosya bu sınırı aştığında, bir hata değeri üzerinde Result::unwrap() kullanan Rust kodundaki işlenmemiş bir hata nedeniyle modül sınıra çarptı ve panikledi. Cloudflare Blog

4. Çekirdek proxy hizmetleri 5xx hataları döndürmeye başladı

   • Bot Yönetimi çekirdek proxy yoluna entegre edildiğinden, panik bu modüle bağlı olan tüm trafikler için HTTP 5xx yanıtları olarak ortaya çıktı.

   • Yeni FL2 motorunda müşteriler açık 5xx hataları gördü.

   • Eski FL motorunda, bot puanları sessizce sıfıra iniyordu ve bu da bot engelleme kurallarında yanlış pozitiflere neden olabiliyordu. Cloudflare Blog

5. İşin kötü tarafı: dosya sürekli "iyi" ve "kötü" arasında gidip geliyordu

   • ClickHouse kümesi kademeli olarak güncelleniyordu ve özellik dosyası her beş dakikada bir yeniden oluşturuluyordu.

   • Sorgu bazen güncellenmiş düğümlerde (kötü bir dosya üreterek), bazen de güncellenmemiş düğümlerde (iyi bir dosya üreterek) çalışıyordu.

   • Bu, dosyanın farklı sürümleri yayıldıkça Cloudflare ağının bir süre normal çalışma ile arıza arasında gidip gelmesi anlamına geliyordu. Cloudflare Blogu

Bu salınım, durumu şirket içinde son derece kafa karıştırıcı hale getirdi. İlk başta Cloudflare ekipleri büyük bir DDoS saldırısından şüphelendi çünkü hata modeli basit bir yazılım çökmesine benzemiyordu. Kendi altyapıları dışında barındırılan Cloudflare durum sayfası bile kısa bir süre hata gösterdi - bu da harici bir saldırı şüphesini daha da artıran bir tesadüf oldu. Cloudflare Blogu+1

Ancak ortak faktörün bot özellik dosyası olduğunu fark ettiklerinde resim netleşti.

Olayın zaman çizelgesi

Cloudflare'in postmortem ve üçüncü taraf raporlarına dayanarak, 18 Kasım 2025 için kabaca bir zaman çizelgesi oluşturabiliriz: Cloudflare Blog+2ThousandEyes+2

• 11:05 UTC - ClickHouse'da bir veritabanı erişim kontrolü değişikliği dağıtıldı.

• 11:20-11:30 UTC - Bot Yönetimi özellik dosyasının kötü sürümleri oluşturulmaya ve yayılmaya başladı.

• 11:28 UTC - İlk müşteri etkisi: müşteri trafiğinde yüksek HTTP 5xx hataları görüldü.

• 11:30-11:32 UTC - Harici izleme araçları ve otomatik testler aralıklı arızaları tespit etmeye başlar.

• 11:35 UTC - Cloudflare dahili bir olay çağrısı açar; soruşturma başlar.

• ~11:48 UTC - Cloudflare bir olayı doğrulayan bir durum güncellemesi yayınladı. Yeniden gönder

• 11:30-13:05 UTC - Ekipler, bozulmuş görünen İşçi KV davranışına odaklanır ve birden fazla olası nedeni araştırır (saldırı senaryoları dahil).

• 13:05 UTC - Önemli hafifletme: İşçiler KV ve Cloudflare Access, çekirdek proxy'yi atlamak için kaydırıldı; etki azaltıldı. Cloudflare Blogu

• 14:30 UTC - Kök neden belirlendi; kötü özellik dosyalarının oluşturulması ve yayılması durduruldu. Bilinen iyi bir yapılandırma dosyası manuel olarak eklenir ve çekirdek proxy yeniden başlatılır. Çekirdek trafiğin çoğu normale döndü. Cloudflare Blogu

• 14:40-15:30 UTC - Turnike ve kimlik doğrulama girişimlerinin birikmesi ikincil yük artışları yaratırken gösterge tablosu ve oturum açma sorunları devam ediyor. Cloudflare Blogu

• 17:06 UTC - Hata oranları başlangıç seviyesine döndü; Cloudflare sistemleri tamamen normal ilan etti. Cloudflare Blogu

Kullanıcı açısından bakıldığında, kesinti en çok sabah geç saatlerden öğleden sonra UTC'ye kadar hissedildi, ancak kesin etki pencereleri bölgeye ve her hizmetin hangi Cloudflare ürünlerine bağlı olduğuna göre değişiyordu.

Bu kesinti neden bu kadar önemli?

Merkezileşme riski

Cloudflare, büyük bulut platformları (AWS, Azure, GCP) ve diğer büyük CDN'lerin yanı sıra küçük bir dizi merkezi internet altyapı sağlayıcısının bir parçasıdır. Bu oyunculardan biri arızalandığında, etki geniş ve genellikle açık değildir.

Bu kesinti:

• BGP yönlendirme hatasından ya da İSS kablo kesintisinden kaynaklanmadı.

• Kötü niyetli bir saldırıdan kaynaklanmadı (ilk şüphelere rağmen).

• Tek bir yapılandırma ve dahili bir bileşendeki sınır hatasından kaynaklandı.

Bu önemli çünkü karmaşık, birbirine sıkı sıkıya bağlı sistemlerin dış müdahale olmadan bile nasıl feci bir şekilde başarısız olabileceğini gösteriyor. Birçok kuruluş aynı sağlayıcı üzerine inşa edildiğinde, bu sağlayıcı internetin fiili olarak sistemik açıdan önemli bir parçası haline gelir.

"Yumuşak" bağımlılıklar da zarar verir

Etkilenen hizmetlerden bazıları Cloudflare'i sadece aptal bir CDN olarak kullanmıyordu. Kullanıyorlardı:

• Kimlik doğrulama ve sıfır güven erişimi için Cloudflare Access 'i kullanmak.

• Workers KV' yi dahili kontrol düzlemlerinin bir parçası olarak kullanmak.

• Botlara dayanıklı girişler için Turnike 'ye güvenmek. Cloudflare Blog+1

Bu ürünler çöktüğünde, çöken yalnızca web sitesi içeriği değildi; oturum açma işlemleri, yönetici işlevleri ve dahili API' ler de çöktü. Bu da kurtarmayı daha karmaşık hale getirir: durum sayfanız, olay araçlarınız veya yönetici kullanıcı arayüzünüz de az önce başarısız olan sağlayıcıya bağlı olabilir.

Cloudflare neyi değiştireceğini söylüyor

Cloudflare'in blogu, şirketin benzer bir şeyin tekrarlanma riskini azaltmak için halihazırda attığı birkaç düzeltme adımını özetliyor: Cloudflare Blog

1. Otomatik oluşturulan yapılandırma dosyalarının alımını güçlendirin
   Dahili olarak oluşturulan yapılandırmalara, kullanıma sunmadan önce sıkı şema ve boyut denetimi de dahil olmak üzere, kullanıcı tarafından sağlanan girdilerle aynı şüphecilik ve doğrulama ile muamele edin.

2. Daha fazla global kill switch
   Ağ genelinde sorunlu dahili modülleri (Bot Yönetimi gibi) hızlı bir şekilde devre dışı bırakmayı kolaylaştırın, böylece tüm proxy yolunu paniklemek yerine açık kalırlar.

3. Sistem kaynaklarını hata fırtınalarından koruyun
   Hatalar artmaya başladığında çekirdek dökümlerinin, hata ayıklama meta verilerinin ve gözlemlenebilirlik araçlarının CPU ve belleği boğmamasını sağlayın.

4. Çekirdek proxy modüllerindeki hata modlarını gözden geçirin
   Her bir dahili modülün beklenmedik girdi veya yapılandırma altında nasıl davrandığını sistematik olarak denetleyin ve küresel arıza yerine zarif bozulma sağlayın.

5. Sunumları ve izolasyonu iyileştirin
   Çok ayrıntılı olarak açıklanmamış olsa da, olay Cloudflare'in tek bir kötü değişikliğin tüm filoyu etkileme olasılığını azaltmak için yeni yapılandırmaların ve DB davranışlarının nasıl yayıldığını daha da bölümlere ayıracağını gösteriyor.

Ayrıca, olayı esneklik beklentilerinin mutlak bir başarısızlığı olarak çerçevelediler, "kabul edilemez" olarak nitelendirdiler ve hem müşterilere hem de sıradan internet kullanıcılarına neden olduğu acıyı açıkça kabul ettiler. Cloudflare Blog

Altyapı ve SRE ekipleri için dersler

Cloudflare kadar büyük bir şey çalıştırmıyor olsanız bile, bu kesintide bazı çok pratik tasarım ve operasyonel dersler vardır:

Dahili yapılandırmaya güvenilmeyen girdi gibi davranın

"Kendi" oluşturduğumuz yapılandırmanın her zaman doğru olduğunu varsaymak kolaydır. Dün bunun neden tehlikeli olduğunu gösterdi:

• Uygulamadan önce yapılandırma dosyalarının boyutunu, şeklini ve sınırlarını her zaman doğrulayın.

• Yapılandırmayı önce küçük bir trafik veya düğüm alt kümesine, anormalliklerde otomatik geri alma ile kanarya uygulamasını düşünün.

• Özellik sayıları, bellek ön tahsisi ve CPU kullanımı etrafında katı üst sınırlar ve devre kesiciler bulundurun.

Zararsız kısmi arıza için tasarım

Bot Yönetimi modülündeki bir hata, tüm proxy yolunu panikleyememelidir:

• Alternatif tam kesinti olduğunda bazı güvenlik katmanlarında fail-open ve fail-closed varsayılsın.

• Çekirdek olmayan özellikler için net, test edilmiş kill switch 'ler oluşturun.

• Kritik alt sistemlerin (kimlik doğrulama, durum sayfası, olay araçları) bozulmuş modda veya alternatif rotalar üzerinden çalışabilmesini sağlayın.

Doğru sinyalleri gözlemleyin

Her beş dakikada bir "iyi yapılandırma" ve "kötü yapılandırma" arasındaki salınım, sinyalin saldırı trafiği veya gürültülü dış davranış gibi görünmesine neden oldu:

• Gözlemlenebilirlik işlem hattınızda sürüm başına veya yapılandırma başına korelasyon olduğundan emin olun.

• Yapılandırma değişikliklerini hata grafiklerinin üzerinde görsel olarak belirgin hale getiren gösterge tabloları oluşturun.

• Harici bir bakış açısından güçlü sentetik testler ekleyin, böylece dahili arızayı ağ / yol sorunlarından hızlı bir şekilde ayırt edebilirsiniz.

Tüm yumurtalarınızı tek bir altyapı sepetine koymayın

Cloudflare kullanan kuruluşlar için:

• Gerçekten görev açısından kritik özellikler için çokluCDN kurulumlarını düşünün.

• Durum sayfanızı tamamen birincil yığınınızla aynı sağlayıcıya bağımlı hale getirmekten kaçının (Cloudflare bunu yapıyor, ancak dün durum sayfası barındırıcısıyla ilgili tesadüfi bir sorun yaşandı ve bu da işleri daha da karıştırdı). Cloudflare Blog+1

• Kimlik doğrulama, API kontrol düzlemleri ve ön uç dağıtımınızı yedek yollar olmadan aynı satıcıya sıkıca bağlamadan önce iki kez düşünün.

Büyük resim

Sadece son birkaç ay içinde Microsoft Azure, Amazon Web Services ve şimdi de Cloudflare'de büyük kesintiler yaşandı ve bunların hepsi tüketici ve kurumsal hizmetlerin büyük bir bölümünü geçici olarak devre dışı bıraktı. AP Haberleri+2TheWashington Post+2

Durum gayet açık:

• İnternet giderek bir avuç dev altyapı sağlayıcısına bağımlı hale geliyor.

• Kesintiler genellikle dış saldırılardan ziyade karmaşık iç değişikliklerden kaynaklanıyor.

• Birinci sınıf SRE uygulamalarına sahip sağlayıcılar bile yapılandırma, veritabanı davranışı ve sabit kodlu sınırlar arasındaki beklenmedik etkileşimler nedeniyle takılıp kalabiliyor.

Dün yaşanan Cloudflare olayı, "bulutun" sihirli bir şey olmadığına dair çarpıcı bir hatırlatmadır. En temelde, hala insanlar tarafından yazılmış bir yazılımdır ve diğer uygulamalarla aynı hata sınıflarına tabidir - sadece ona bağlı olan çok daha fazla insan vardır.

Kullanıcılar için bu olay çoğunlukla "X ve ChatGPT'nin yüklenmediği o sabah" olarak hatırlanacaktır.
Mühendisler içinse bu olay, çekirdek dağıtık bir sistemdeki ince yapılandırma hatalarının nasıl küresel bir internet olayına dönüşebileceğinin ders kitabı niteliğinde bir örneği olarak incelenecektir.