Cloudflare global network outage हुआ

 (cloudflarestatus.com)
1 पॉइंट द्वारा GN⁺ 2025-11-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare global network में internal service performance degradation हुआ, जिससे कई services बीच-बीच में प्रभावित हुईं
  • Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers जैसी प्रमुख services ने अस्थायी outage का सामना किया
  • Engineering team ने समस्या की पहचान की और fix पर काम शुरू किया, तथा WARP और Access services सबसे पहले बहाल हुईं
  • इसके बाद दुनिया भर में error rate और latency धीरे-धीरे सामान्य स्तर पर लौटे, और Dashboard service भी restore हो गई
  • फिलहाल सभी services सामान्य रूप से चल रही हैं, और incident पूरी तरह resolve हो चुका है

घटना का सारांश

  • Cloudflare को internal service performance degradation (Internal Service Degradation) का सामना करना पड़ा, जिससे कुछ services बीच-बीच में बाधित हुईं
    • प्रभावित services में Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers शामिल थीं
    • कंपनी ने तुरंत recovery work शुरू किया और समस्या समाधान की प्रगति पर लगातार updates दिए

समस्या की पहचान और शुरुआती प्रतिक्रिया

  • Cloudflare ने जांच जारी है (Investigating) चरण में internal service degradation की पुष्टि की
    • कुछ customers ने बीच-बीच में errors और latency का अनुभव किया
    • Engineering team ने root cause analysis और recovery work समानांतर रूप से किया
  • इसके बाद समस्या के कारण की पहचान (Identified) कर fix लागू करना शुरू किया गया
    • fix के दौरान London region में WARP access अस्थायी रूप से disable कर दिया गया, जिससे उस क्षेत्र के users को internet connection failure का सामना करना पड़ा

service recovery की प्रगति

  • fix के बाद Access और WARP services सबसे पहले restore हुईं और error rate incident से पहले के स्तर पर लौट आया
    • London region में WARP access फिर से enable किया गया
  • इसके बाद Application Services customers के लिए service restoration work जारी रहा
    • Dashboard service recovery के लिए changes deploy किए गए
    • कुछ customers को अब भी login या Dashboard इस्तेमाल करने में समस्या हुई, लेकिन अतिरिक्त fixes से यह हल हो गया

पूरे network की स्थिरता की बहाली

  • दुनिया भर में error rate और latency धीरे-धीरे कम हुए और सामान्य स्तर पर लौटे
    • Bot Management के bot scores अस्थायी रूप से प्रभावित हुए थे, लेकिन recovery process के दौरान सामान्य हो गए
    • Engineering team ने बाकी errors को हटाया और पूरे network की recovery को तेज किया
  • इसके बाद सभी services सामान्य रूप से काम करने लगीं, और error rate व latency पूरी तरह सामान्य हो गए

घटना का समापन और आगे की कार्रवाई

  • Cloudflare ने पुष्टि की कि सभी services सामान्य रूप से चल रही हैं और incident को बंद कर दिया
    • फिलहाल कोई अतिरिक्त configuration changes नहीं किए गए हैं, और platform की बारीकी से monitoring की जा रही है
    • incident के कारण पर post-incident investigation जारी है, और उसका परिणाम बाद में साझा किया जाएगा
  • यह outage global network के व्यापक हिस्से को प्रभावित करने वाली घटना के रूप में दर्ज किया गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-11-19
Hacker News राय

  • Cloudflare API token रखने वाला कोई भी व्यक्ति CF proxy को disable करने वाला command साझा कर रहा था
    curl command से zone ID और DNS record लाए जा सकते हैं, और PATCH request में "proxied": false सेट करना होता है
    हालांकि SSL certificate खोने, security/performance में गिरावट, और backend IP उजागर होने का जोखिम है, इसलिए सावधानी ज़रूरी है

    • अगर आपके पास सिर्फ पुरानी Global API Key है, तो X-Auth-Email और X-Auth-Key header इस्तेमाल किए जा सकते हैं
      और जिन्होंने सिर्फ Cloudflare traffic को allow किया हुआ है, उन्हें वह rule थोड़ी देर के लिए बंद करना होगा
    • सोचा था अगली बार यह तरीका इस्तेमाल करूंगा, लेकिन API token पहले से बनाया नहीं था इसलिए इंतज़ार करना पड़ा
      अच्छी बात है कि अब सब फिर से online हो गया है
    • मैंने इसे Terraform provider से संभाला, लेकिन जिन लोगों को dashboard access नहीं मिल रहा था, उनके लिए यह तरीका उपयोगी है
    • बढ़िया tip है। वैसे curl में GET request default होती है, इसलिए -X GET की ज़रूरत नहीं है
      -d option इस्तेमाल करने पर वह अपने-आप POST हो जाता है, और PATCH के लिए -X PATCH सही है
    • Cloudflare WARP चालू करने पर कुछ site फिर से काम करने लगती हैं। शायद 1.1.1.1 का भी ऐसा ही असर हो
      लेकिन tunneling के बाद भी कुछ site अब भी आंशिक रूप से down हैं

  • Cloudflare CTO के मुताबिक, bot blocking system में एक संभावित bug configuration change के बाद बेकाबू हो गया और पूरे network में outage का कारण बना
    source में बताया गया कि यह हमला नहीं, बल्कि आंतरिक समस्या थी

    • यह हैरानी की बात है कि बड़ी कंपनियां अब भी configuration changes को चरणबद्ध तरीके से deploy नहीं करतीं
      code हो या config, दोनों data ही हैं, और इन्हें दुनिया भर में एक साथ push करके बड़े outage की वही पुरानी गलती दोहराई जाती है
    • अच्छा होता अगर यह अहम जानकारी comments के ऊपर होती। cyber attack की अटकलों वाले comments के बीच इसे ढूंढना मुश्किल था
    • एक configuration change से CF का stock 4% गिर गया। ऐसे outage का पूरे industry पर आर्थिक असर कितना होता होगा, यह जानने की जिज्ञासा है

  • एक सहकर्मी अचानक भागते हुए आया और बोला कि Cloudflare config बदलने के तुरंत बाद site down हो गई, तो उसे लगा कि उसी से गड़बड़ हो गई
    यह पोस्ट देखकर उसे राहत मिली

    • मैंने मज़ाक किया, “उससे भी बुरा, तुमने पूरा Cloudflare ही down कर दिया”
    • फिर भी क्या सच में ऐसा नहीं हो सकता? पहले Fastly का बड़ा outage हो चुका है, इसलिए थोड़ा शक बना रहता है
    • सोच रहा हूं कि वह अजीब-सी राहत व्यक्त करने के लिए कोई सटीक शब्द है क्या, जब पता चले कि गलती किसी और की थी
    • हो सकता है वह सहकर्मी Cloudflare का कर्मचारी ही हो
    • मुझे भी clients से site न चलने के दर्जनों message आए, और मैंने कल ही config बदली थी, तो ठंडा पसीना छूट गया
      “Cloudflare down” message देखकर सच में राहत मिली

  • नीदरलैंड में जांचने पर लगभग सारी services down थीं
    Cloudflare dashboard भी नहीं खुल रहा था, और Betterstack dashboard का भी वही हाल था
    विडंबना यह थी कि status page चालू थी, इसलिए customers को notice तक नहीं दे पा रहे थे

    • मेरा भी यही अनुभव था। सिर्फ HN इसलिए ठीक चल रहा था क्योंकि वह Cloudflare इस्तेमाल नहीं करता
      मैंने “ज़रूरत न हो तो Cloudflare के पीछे मत रखो” पर एक blog post भी लिखी है
    • हर साल समझ आता है कि AWS या Cloudflare पर ज़रूरत से ज़्यादा निर्भर होना खतरनाक है, लेकिन विकल्प आसान नहीं हैं
      फिर भी ऐसे बड़े outage में customers उम्मीद से ज़्यादा समझदारी दिखा देते हैं
    • Cloudflare dashboard पूरी तरह मरी नहीं थी, बल्कि लगातार कोशिश करो तो proxy बंद किया जा सकता था
      कुछ मिनट लगे, लेकिन मैंने hcker.news को CF से अलग कर दिया
    • ऐसी स्थिति देखकर लगता है कि local VPS पर status page host करने वाली service बनाना एक business opportunity हो सकती है
    • मेरे side project Total Real Returns में
      नीचे external status page से जुड़ा real-time uptime widget लगा है
      status SVG और
      external status page देख सकते हैं

  • Cloudflare या AWS रुकने पर मेरी self-hosted service का सामान्य रूप से चलते रहना एक अलग ही संतोष देता है
    उनकी 99.999% availability से इस समय तो मैं ज़्यादा stable हूं

    • मेरी मामूली personal site भी AWS, Azure, Cloudflare outage के दौरान पूरी तरह चालू रही
      अब शायद एक uptime tracker लगा ही दूं
    • मेरी self-hosted site तो Cloudflare proxy की वजह से ही down हो गई। बड़ी विडंबना है
    • पारंपरिक कंपनियों में Oracle, SAP जैसी systems ठीक चल रही हैं, लेकिन नई cloud-based services ही बंद पड़ी हैं
      यह नए SaaS startups के लिए सीख है
    • बहुत लोग पूछ रहे हैं कि DNS कैसे handle करते हो। मैं भी Raspberry Pi पर host करता हूं, और DNS अभी-अभी Cloudflare पर shift किया था
      इसलिए मेरी छोटी-सी site का down होना मज़ेदार भी लगा और अजीब तरह से संतोषजनक भी

  • हाल के दिनों में बड़े infrastructure outage तेज़ी से बढ़े लगते हैं। AWS और Cloudflare दोनों ही SLA से काफ़ी नीचे दिख रहे हैं

    • यह उस दौर से मेल खाता है जब बड़ी कंपनियों ने mass layoffs के बाद AI से replacement की बात शुरू की
    • ऐसे outage से समझ आता है कि SLA में ‘9 की संख्या’ का कोई खास मतलब नहीं
      यह वास्तविक uptime नहीं, बल्कि कंपनी द्वारा मनमाने ढंग से परिभाषित किया गया आंकड़ा है
    • कुछ लोग इसे “vibe code theory” कहते हैं। मतलब जितना ज़्यादा अंदाज़े से लिखा code, उतने ज़्यादा bug और outage — थोड़ा मज़ाकिया सिद्धांत है
    • यह विश्लेषण भी है कि साल के अंत में deploy freeze और Q4 targets के दबाव के कारण जल्दी-जल्दी deploy करने की संस्कृति जिम्मेदार होती है
    • या फिर राष्ट्र-स्तरीय cyber attack होने की साज़िशनुमा थ्योरी भी सामने आती है

  • Cloudflare या AWS रुक जाएं तो web का आधा हिस्सा रुक जाना centralization की समस्या को गंभीर रूप से दिखाता है

    • users भी इसे ज़्यादा गंभीरता से नहीं लेते। “internet बंद है” वाली धारणा की वजह से अलग-अलग services जिम्मेदारी से बच निकलती हैं
      यही वजह है कि यह ढांचा बदलता नहीं
    • DDoS defense में economies of scale काम करती हैं। जितने ज़्यादा customers, उतनी ज़्यादा bandwidth और उतनी मज़बूत defense
      छोटे CDN के लिए मुकाबला कठिन हो जाता है, और अंततः natural monopoly जैसा ढांचा बनता है
      Cloudflare का free tier भी इसी network effect को पाने की रणनीति थी
    • single point of failure से भी ज़्यादा चिंता की बात यह है कि ऐसी centralization web standards और autonomous hosting के भविष्य को विकृत कर सकती है
      और सरकारों की censorship का केंद्रित target भी बन सकती है
    • Let's Encrypt भी एक संभावित जोखिम है।
      web के 2/3 हिस्से की निर्भरता उस पर है, certificate की उम्र लगातार घट रही है, और अगर hack या outage हो जाए तो पूरा web ठप पड़ सकता है
      अभी वह एक अच्छी संस्था है, लेकिन यह नहीं भूलना चाहिए कि कभी Google के बारे में भी ऐसा ही सोचा जाता था
    • AWS boom के बाद developers dedicated server के बजाय सिर्फ cloud पर निर्भर हो गए, यही समस्या है
      software level पर backup बहुत हैं, लेकिन infrastructure level पर multi-hosting की सामान्य समझ लगभग गायब हो गई है

  • विडंबना यह रही कि DownDetector भी Cloudflare Turnstile इस्तेमाल कर रहा था, इसलिए वह भी साथ में down हो गया

    • AWS outage reports भी बहुत बढ़ गईं, लेकिन संभव है कि उनमें से ज़्यादातर false positives हों
    • मैंने भी वह स्थिति देखी

  • Cloudflare का “Your browser: Working / Host: Working / Cloudflare: Error” वाला दृश्यात्मक माफ़ीनामा काफ़ी प्रभावशाली लगा

    • ऐसा screen मैंने पहली बार देखा। हालांकि मेरे मामले में “Host” भी Cloudflare Pages था, इसलिए उसका मतलब थोड़ा अस्पष्ट लगा
    • “Cloudflare” पर click करने पर अब भी customer server की समस्या बताना थोड़ा हास्यास्पद है
    • ईमानदार message अच्छा लगा, लेकिन users की प्रतिक्रिया बस “Wi‑Fi ठीक कर दो” जैसी ही थी
    • फिर भी स्थिति साफ़ समझ आ गई और उसके अनुसार कार्रवाई की जा सकी। ज़रूरत पड़े तो proxy disable करके service impact कम किया जा सकता है
    • मैं भी एक घंटे तक logs खंगालता रहा, फिर समझ आया कि समस्या मेरे server में नहीं थी

  • Cloudflare Challenge (“I’m not a robot”) इस्तेमाल करने वाली sites भी HTTP 500 error देने लगीं और रुक गईं
    “challenges.cloudflare.com को unblock करें” जैसा message दिख रहा था

    • आजकल error handling का स्तर बहुत खराब है। कंपनियां जिम्मेदारी से बचने के लिए users को दोष देती हैं
      या infinite loading screen दिखाती रहती हैं। जबकि backend साफ़ error लौटाता है, frontend उसे छिपा देता है
      हाल में मैंने ऐसा case भी देखा जहां password बहुत लंबा होने की error को “email पहले से इस्तेमाल हो रहा है” बनाकर दिखाया गया
    • इस outage से chat.bing.com की AI search (GPT5) भी रुक गई
      विडंबना यह हो गई कि AI को इंसान होने का सबूत देना पड़ रहा था
    • कुछ sites (जैसे pinkbike) “you have been blocked” message दिखा रही थीं
    • यानी सिर्फ robots नहीं, असली इंसान भी block हो रहे थे /s
    • लगता है frontend यह मान रहा था कि user ने DNS या extension से domain को block किया है
      Cloudflare Captcha कभी down नहीं हो सकता — इस तरह का /s वाला व्यंग्यात्मक इनकार काफ़ी मज़ेदार था