Cloudflare 5 Aralık 2025 Kesintisi

 (blog.cloudflare.com)
1 puan yazan GN⁺ 2025-12-06 | 1 yorum | WhatsApp'ta paylaş
  • 2025-12-05 08:47 UTC'de Cloudflare ağının bir kısmı ciddi bir arıza yaşadı ve yaklaşık 25 dakika sonra, saat 09:12'de tamamen düzeltildi
  • Toplam HTTP trafiğinin yaklaşık %28'i etkilendi ve yalnızca belirli koşulları karşılayan müşteriler arıza yaşadı
  • Neden, React Server Components açığı (CVE-2025-55182) için yapılan WAF(gövde ayrıştırma mantığı) değişikliğiydi; olayın bir siber saldırı veya kötü niyetli eylemle ilgisi yoktu
  • FL1 proxy'deki bir kod hatası nedeniyle HTTP 500 hatası üretildi; yeni Rust tabanlı FL2 proxy'sinde aynı hata oluşmadı
  • Cloudflare, Kasım 18 arızasından sonra da benzer bir sorunun tekrarlandığını kabul ederek, dağıtım güvenliği ve dayanıklılık artırma projesini en yüksek öncelik olarak yürütüyor

Arıza özeti

  • 2025-12-05 saat 08:47 UTC'de Cloudflare ağının bir bölümünde arıza meydana geldi
    • 09:12'de tüm servisler geri yüklendi; toplam etki süresi 25 dakika oldu
    • Toplam HTTP trafiğinin yaklaşık %28'i etkilendi
  • Arıza, siber saldırı veya kötü niyetli bir eylemle ilgisi olmaksızın iç bir ayar değişikliği sırasında meydana geldi
  • React Server Components için yeni güvenlik açığına yanıt olarak yapılan WAF gövde ayrıştırma mantığı değişikliği tetikleyiciydi

Arıza nedeni ve teknik arka plan

  • Cloudflare WAF, zararlı yükleri tespit etmek için HTTP istek gövdesini bellekte tamponlar
    • Mevcut tampon boyutu 128 KB'den 1 MB'a çıkarılıyordu
  • Yeni tampon boyutunu desteklemeyen iç test aracı nedeniyle test aracını devre dışı bırakmaya yönelik ikinci bir değişiklik yapıldı
    • Bu değişiklik, küresel yapılandırma sistemi aracılığıyla anında tüm sunuculara yayıldı
    Reklam
  • FL1 proxy'de bu değişiklik hata durumuna yol açarak HTTP 500 yanıtları üretti
    • Hata iletisi: attempt to index field 'execute' (a nil value)
  • Sorun hemen tespit edilip 09:12'de değişiklik geri alındı

Etki alanı

  • FL1 proxy kullanan ve Cloudflare Managed Ruleset'i etkinleştiren yalnızca müşteriler etkilendi
    • Bu etkilenen alanlardaki tüm istekler HTTP 500 hatası döndürdü
    • /cdn-cgi/trace gibi bazı test uç noktaları istisna oldu
  • Çin ağı ve farklı konfigürasyonlu müşteriler etkilenmedi

Çalışma zamanı hatası ayrıntıları

  • Cloudflare'in kurallar kümeleri (rulesets) sistemi her istek için kuralları değerlendirir
    • Kurallar filtre ve eylemlerden oluşur; execute eylemi başka bir kurallar kümesini çağırır
    Reklam
  • İç loglama sistemi, test kurallarını değerlendirmek için execute kullanır
  • killswitch sistemi, hatalı davranan kuralları devre dışı bırakacak şekilde tasarlanmıştır, ancak
    • execute eylemi içeren kurallarda killswitch uygulaması bu ilk olaya denk geldi
  • execute nesnesi mevcut değilken buna erişilmeye çalışılmasıyla Lua hatası oluştu
  • Bu hata, yıllardır var olan basit bir kod hatasıydı
    • Rust ile yazılmış FL2 proxy'de aynı hata ortaya çıkmadı

18 Kasım arızasından sonraki geliştirme durumu

  • 18 Kasım'da da benzer bir küresel dağıtım kaynaklı geniş kapsamlı arıza yaşanmıştı
  • O dönemde yüzlerce müşteriyle doğrudan iletişime geçilerek tek bir güncellemenin tüm ağda yayılmasının önlenmesi planı paylaşılmıştı
  • Bu geliştirme çalışması henüz tamamlanmadığı için bu arıza etkilenmiş oldu
  • Cloudflare bunu organizasyon çapında en yüksek öncelik olarak tanımladı

Devam eden dayanıklılık artırma projeleri

  • Gelişmiş Dağıtım ve Sürümleme (Enhanced Rollouts & Versioning)
    • Tehdit yanıtı için veri ve yapılandırma değişikliklerine aşamalı dağıtım, sağlık doğrulaması ve hızlı geri alma özellikleri uygulanacak
    Reklam
  • Hızlı Müdahale (Streamlined Break Glass) Kabiliyetleri
    • İç servisler ve kontrol düzlemi etkileşimlerinde de acil durumda müdahale edilebilirlik sağlanacak
  • Fail-Open hata işleme
    • Yapılandırma dosyası hatalarında istekleri engellemek yerine varsayılan güvenli duruma dönme veya trafiği geçirme davranışı uygulanacak
    • Bazı hizmetlerde fail-open/fail-closed seçim seçeneği sunulacak
  • Bir sonraki hafta içinde tüm dayanıklılık projelerinin ayrıntıları açıklanacak
  • O zamana kadar ağ değişiklikleri tamamen durdurulmuş (lockdown) durumda tutulacak

Zaman Çizelgesi (UTC)

  • 08:47 – yapılandırma değişikliği dağıtıldı ve ağ yayılımı başladı
  • 08:48 – tüm etki oluştu
  • 08:50 – otomatik uyarı ile olay ilan edildi
  • 09:11 – değişiklik geri alınmaya başladı
  • 09:12 – toparlanma tamamlandı, tüm trafik normalleşti

Sonuç

  • Cloudflare, ardışık iki arızanın ciddiyetini kabul ederek müşterilerine ve internet ekosistemine özür diledi
  • Gelecekte benzer olayları önlemek için dağıtım güvenliği, hata toleransı ve dayanıklılığı güçlendirme planlarını ilerletecek

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-06
Hacker News yorumları

  • Bu Cloudflare kesintisi, basit bir Lua hatası değil; daha temel bir mimari sorunu ortaya çıkaran bir olay.
    Başlangıçtaki dağıtık web yapısı, bu tür küresel kesintilere çok daha dayanıklıydı. Buna karşılık Cloudflare gibi homojen ve merkezi sistemler, tek bir hatayla dünya genelindeki hizmetleri aynı anda durdurabiliyor. Rust ile yazılsa bile insanlar hata yapar. Sonuçta önemli olan sağlam tasarım.

    • Sonuç olarak Cloudflare ya da AWS gibi dev sağlayıcılara ne kadar bağımlı olunursa, webin istikrarı da o kadar düşüyor demek.
    • “1.000 eşekarısı vs 1 köpek” benzetmesindeki gibi, ister küresel ister bölgesel kesinti olsun, sadece acının biçimi değişiyor. Cloudflare durursa yüzlerce mühendis anında müdahale eder; benim sunucum durursa sorumlu kişi dağ evinde de olabilir.
    • Tekelin kötü olduğu tartışmasını bir kenara bırakırsak, Cloudflare’in uzun vadeli çalışma süresine bakınca bunun tek tek sitelerin altyapıyı kendilerinin işletmesinden daha iyi olduğunu düşünüyorum. Tüm hizmetlerin aynı anda 1 saat durması, kullanıcı açısından her birinin ayrı ayrı 1’er saat durmasından daha iyi olabilir. Ama Cloudflare’in istikrarı ortalamanın altına düşerse bu değer ortadan kalkar.
    • Saniyede 80 milyon isteği işleyen bir ölçekte, en başta tek bir ürünün bu kadar büyüyebildiği yapının kendisinin sorun olduğunu düşünüyorum.
    • Cloudflare hâlâ dünyanın herhangi bir yerinde küresel altyapıyı en hızlı toparlayan şirketlerden biri. Bu olayda da %28 ağ kesintisini 25 dakikada çözdü ve diğer bulut sağlayıcılarına kıyasla nesnel olarak daha az kesinti süresi var.

  • Dün gece birkaç sitede Cloudflare 500 hatası gördüm. Ama durum sayfasında buna dair hiçbir şey yoktu, sadece planlı bakım duyurusu vardı.

    • Çoğu durum sayfasında olduğu gibi, gerçek sorunu fark edip güncellemeleri yayınlamak zaman alıyor. Tam otomatik hale gelene kadar Cloudflare de istisna değil. Asıl daha kaygı verici olan, son dönemde AWS, Azure ve Cloudflare’in peş peşe çökmesi. İçgüdüm bana LLM kullanımındaki artışın, personel eksikliğinin, pandemi artçılarının ve siyasi istikrarsızlığın birlikte etkili olduğunu söylüyor.
    • Bu tür durum sayfası sorunları ancak kamuya açık eleştiri ile düzelecek gibi görünüyor. “Cloudflare kesintiyi düzgün tespit bile edemiyor” yönündeki geri bildirimlerin artması lazım.

  • Cloudflare’in kalite mühendisliği, üretim hızına yetişemiyor gibi görünüyor. Eskiden savunma sanayiinde kalite ekibinin her zaman daha tecrübeli olduğunu duyardım; yazılım sektöründe ise sanki tam tersi.

    • Savunma sanayiinde bile bellek sızıntısını bilip “kullanım süresi içinde sorun yaratmaz” diyerek görmezden geldikleri hikâyeler aklıma geliyor.
    • Bu bir ayda iki kez yaşandıysa, bu “övgüye değer” bir şey değil. Tekrar eden durumda mazeret olmaz.

  • İnternetin paket anahtarlama yapısı, aslında bu tür küresel kesintilere dayanacak şekilde tasarlanmıştı.
    Soğuk Savaş dönemindeki DARPA ağı, nükleer saldırı altında bile komuta zincirini koruma amacı taşıyordu.
    Şimdi internetin local-first paradigmasına dönme zamanı gelmiş olabilir.

  • Son zamanlarda Cloudflare’in interneti daha yavaş ve kullanışsız hale getirdiğini hissediyorum. “İnsan olduğunuzu kanıtlayın” gibi adımlar arttı ve sayfa yüklemeleri de gecikiyor.
    Bu da site korumasından çok AI crawling için ücretlendirme politikası yüzünden gibi duruyor (Pay-per-crawl tanıtımı).

    • Bu tür insan doğrulama adımları eski tarayıcılarla uyumlu olmadığından, artık tamamen erişilemeyen siteler de var.
    • Ama yapay zekanın içerikleri izinsiz kazıması da sorun. Cloudflare burada site sahiplerine içerik koruma seçeneği sunuyor; istemezlerse kapatabilirler.
    • “Artık bizi gizlice gözetleyemiyorlar bile” şeklinde alaycı yorumlar da var.

  • Cloudflare’in küresel yapılandırma sistemi, kademeli rollout olmadan birkaç saniye içinde tüm ağa yayıldığı için riskli.
    Yapılandırma değişiklikleri hata çıkardığında, bununla anında ilişki kurulmasını sağlayacak bir sistem gerekli.

    • Sorun, uyarıların çok geç gelmiş olması. Bildirim 2 dakika içinde geldi ama bunun saniyeler içinde tespit edilmesi gerekirdi.
      Dağıtımdan sorumlu kişi gerçek zamanlı metriklere bakıp anında rollback düğmesine basmalıydı.
      Günlüğe hangi kod satırı olduğu bile açıkça düşmüşken, dağıtım ekibi ile kodu anlayan ekip arasında bir kopukluk varmış gibi görünüyor.
    • Uyarı işaretlerini görüp rollback denemişler ama o sürecin kendisi soruna yol açmış gibi görünüyor.
    • İç araçlar çoğu zaman çok fazla yanlış pozitif üretir ve bazen kendileri de bozuk olur.
    • “Motor arıza lambası sürekli yandığı için ampulü söktüm” şakası gibi geliyor.

  • Cloudflare’in çalışma süresi %99,9’un altına düştü. Evimdeki PC’den bile kötü seviyede.

    • AWS için de aynı şey geçerli. Bulutun varlık nedeni “daha yüksek erişilebilirlik” ise, pahalı ve güvensiz olduğunda kendi kendine barındırma için yeterince sebep var.
    • Ama kendi kendine barındırmada donanım arızası ya da yedekleme hatası olursa geri dönüş günler sürebilir.
    • Bölgesel elektrik kesintilerinin sık olduğu yerlerde dizüstü bilgisayar ve pille ayakta kalmak da zor. Bazen kendi kendine yeten altyapılar hayal ediyorum.
    • Cloudflare’in güncel ve doğru uptime istatistiklerini tam olarak nereden görebileceğimizi merak ediyorum.
    • Yine de kişisel PC ile Cloudflare’i doğrudan karşılaştırmak anlamsız bir benzetme.

  • Cloudflare ölçeğinde mutlaka bir test ortamı olmalı.
    Her değişiklik, izole edilmiş bir model ortamında simüle edildikten sonra kademeli olarak dağıtılmalı.
    Güçlü tip sisteminden daha önemli olan şey süreçsel güvenlik önlemleri.

    • Bizim şirkette üç aşamalı dağıtım sistemi var: geliştirme → iç entegrasyon → prodüksiyon.
      Hata yapmaya yatkın ekipler yavaşlatılıyor, güvenilirliği yüksek ekipler daha hızlı ilerliyor.
      Sonuçta teknik hız bir tercih meselesi. SLA riske giriyorsa hız düşürülmeli ve testler güçlendirilmeli.
    • Ücretsiz kullanıcıları bir test yatağı olarak kullanıp, ücretli müşterilere daha kararlı sürümler vermek de bir yöntem olabilir.
    • “Güçlü tip sistemi seni kurtarmaz” sözü, süreçsel başarısızlık karşısında dilin tek başına etkisiz kaldığı anlamına geliyor.

  • Cloudflare’in yazılım kalitesi sarsılıyor gibi.
    Kurumsal müşterilere özel bir özelliğin erişim doğrulamasının yalnızca son aşamada yapıldığı bir hata da vardı.

    • Ben de Cloudflare API’de geri alınamayan bir ayarla karşılaştım.
      Sadece destek ekibi üzerinden değiştirilebiliyordu ve düzeltilmesi günler sürdü.
      İlgili vaka bağlantısı
    • Bunun gibi hataların AI tarafından yazılmış koddan kaynaklanmış olabileceğini düşünenler de var.
    • “Sadece son aşamada kontrol ediliyor” derken ne kastedildiğini daha somut duymak isterim.

  • Cloudflare’in operasyon kültürünü merak ediyorum.
    Güvenlik sorununa müdahale sırasında hata olmuş ama rollback yerine bir kez daha küresel dağıtım yapılmış; bu tehlikeli bir karar.
    Bu, “şüphe varsa geri al” gibi temel ilkenin ihlali sayılır.

    • Ama bu olay, React Server RCE açığına müdahale gibi acil bir durumdu.
      Dağıtım gecikirse müşteriler gerçekten saldırıya uğrayabilirdi; yani burada hız doğrudan güvenlik anlamına geliyordu.
    • Rollback her zaman doğru cevap değil. Sürece yeterince alışık değilseniz, rollback’in kendisi de risk yaratabilir.
    • Aslında iki dağıtım da farklı bileşenler içindi.
      İlk düzeltme, ikincideki gizli hatayı görünür hale getirmiş olabilir; bu yüzden bazen roll forward, rollback’ten daha gerçekçi olur.
    • Cloudflare muhtemelen hızlı büyüme sürecinde ciddi teknik borç biriktirdi.
      Son dönemdeki sık kesintiler de bu borcun artık görünür hale geldiğinin işareti olabilir.