لم يكن يوم الثلاثاء، الثامن عشر من نوفمبر 2025، يوماً عادياً في سجل المنصات الرقمية. فمع تعثر بسيط في منظومة Cloudflare، أحد أكبر مزودي البنى التحتية للإنترنت في العالم، بدا وكأن حرارة العالم الرقمي ارتفعت فجأة، إذ تعطلت أجزاء واسعة من الشبكة العالمية لقرابة ثلاث ساعات، منذ الساعة 11:20 بتوقيت UTC (2:20 بعد الظهر بتوقيت المملكة العربية السعودية) وحتى قرابة 14:30 بالتوقيت ذاته (17:30 عصراً بتوقيت المملكة).
فعندما “تتعثر” Cloudflare، تُصاب أجزاء من الإنترنت بما يشبه “نزلة برد حادة”. وقد ظهر ذلك جلياً حين توقفت أو تباطأت شبكات التواصل، ومنصات الذكاء الاصطناعي، وخدمات الألعاب، والمتاجر الإلكترونية، والمصارف، وحتى بعض شبكات السكك الحديدية، لتعرض أمام المستخدمين صفحات خطأ تلقي باللوم على مزود الخدمة الشهير.
ما الذي تعطل داخل Cloudflare بالضبط؟
في البداية، أشارت الشركة إلى أن مهندسيها رصدوا “ارتفاعاً غير معتاد” في حركة المرور الموجهة إلى أحد خدماتها منذ لحظة بدء الانقطاع. وبعد دقائق معدودة، بدأت “صفحة الحالة” الخاصة بالشركة تعرض تحذيرات عن “تدهور داخلي” يمس عدداً من العملاء حول العالم.
ومع تقدم التحقيقات، تبلورت الصورة: ملف واحد فقط كان وراء هذه الفوضى.
- الملف يُنشأ تلقائياً، ويُستخدم لإدارة ما يُعرف بـ “حركة المرور المريبة” أو threat traffic، أي مجموعة القواعد التي تطبقها Cloudflare على الطلبات المشبوهة أو ذات الطابع المحتمل للضرر.
- هذا الملف، وفي حادثة غير متوقعة، نما حجمه إلى مستوى هائل يفوق ما اعتاد عليه المهندسون.
- تضخم الملف أدى إلى انهيار أحد البرامج الأساسية التي تقف في “المسار الحرج” لعدة خدمات، ما تسبب في انقطاع أو تراجع مستوى المرور الرقمي المار عبر هذه الخدمات.
حول ذلك، يشير الخبير الأمني Rob Lee من معهد SANS إلى أن مثل هذا الملف يمثل أساساً لقواعد جدار ناري، ويؤثر كذلك في سياسات التوجيه، وقرارات موازنة الأحمال، وآليات توزيع حركة المرور على شبكة Cloudflare العالمية. ولذلك، فإن أي تضخم مفاجئ في هذا النوع من الملفات يمكن أن يسبب بطئاً في تحليل البيانات أو ضغطاً على الذاكرة أو فشلاً في المنطق التشغيلي، ومع حجم Cloudflare الهائل، يمكن لأي تأخير طفيف أن يتفاقم إلى توقف شبه كامل في حركة المرور.
ومع ذلك، أكدت الشركة بشكل واضح أن ما حدث لم يكن هجوماً إلكترونياً، وليس هناك ما يدل على أي نشاط خبيث، بل كان خطأً برمجياً/تكوينياً نتج من أتمتة روتينية لا علاقة لها بأي جهات خارجية.
وبحلول الساعة 14:30 UTC، كانت الشركة قد أنهت معالجة جذور المشكلة، وأعلنت في تحديث لاحق أنها بدأت عملية مراقبة دقيقة لأي آثار جانبية بينها بطء تسجيل الدخول أو تراجع مؤقت في أداء بعض خدمات “الحافة” (Edge Services) مع عودة حركة الإنترنت إلى طبيعتها بشكل تدريجي.
انطفاء منصات تمثل “صورة مصغرة” للإنترنت الحديث
لأن Cloudflare تقف أمام ملايين المواقع كطبقة وسيطة، فقد بدا “سجل الانقطاعات” يوم الثلاثاء وكأنه خريطة لأسلوب الحياة الرقمية الحديثة:
- وسائل التواصل والاتصال: تعرضت خدمات مثل X، ومنصات الذكاء الاصطناعي بما فيها ChatGPT وغيرها، وفي بعض المناطق Microsoft Teams وZoom، إلى تباطؤ شديد أو انقطاع كامل.
- الذكاء الاصطناعي وأدوات المطورين: كان الوصول إلى ChatGPT شبه مستحيل لفترة طويلة، كما ظهرت رسائل خطأ مرتبطة بخدمات Cloudflare لدى منصات Claude التابعة لـ Anthropic وPerplexity.
- الترفيه والبث والإعلام: واجه Spotify، ولعبة League of Legends، وعدد من المواقع الإخبارية بما فيها Axios وPolitico، مشاكل في التحميل أو توقفاً كاملاً.
- التجارة الإلكترونية: تعطلت مواقع وتطبيقات IKEA، وDoorDash، وShopify وغيرهم، ووصل الأمر إلى تعطيل بث مخصص لإعلان نتائج “Home Depot” الربعية.
- المال والعملات الرقمية: شهدت خدمات Visa في بريطانيا، ومنصات مثل Coinbase، ونظم تقييم المخاطر لدى Moody’s، اضطرابات تؤكد اعتماد البنى المالية الحديثة على طبقات البنية التحتية السحابية المشتركة.
- الخدمات العامة والنقل: شملت الأعطال موقع وتطبيق New Jersey Transit، وأجزاء من شبكة SNCF الفرنسية، ومواقع Metropolitan Transportation Authority في نيويورك، دون تسجيل تأثيرات على السلامة العامة.
- الجهات الحكومية والرقابية: تأثرت خدمات كل من Financial Conduct Authority وMI5 في المملكة المتحدة.
- منصات المجتمع والخدمات المتخصصة: تعطلت مواقع مثل Archive of Our Own، وDepop، وGrindr، بل وحتى موقع Downdetector نفسه الذي يتابع الأعطال.
كما وقد واجه المستخدمون رسائل خطأ من نوع HTTP 500، أو صفحات “internal server error” الخاصة بخدمات Cloudflare، أو رسائل مربكة مثل: “Please unblock challenges.cloudflare.com to proceed.” وهي رسالة تظهر عادة عندما لا يمكن تحميل النظام المخصص لتحديات الأمن، إلا أن السبب هذه المرة كان مرتبطاً بانهيار البرنامج المسؤول عن المعالجة الأساسية لحركة المرور.
في حين سجل Downdetector أكثر من 11,000 بلاغ في ذروة الأزمة قبل أن ينخفض العدد إلى حوالي 2,800 مع تحسن الوضع تدريجياً، مع الإشارة إلى أن هذه الأرقام تقريبية لأنها تعتمد على بلاغات المستخدمين.
لماذا يمكن ليوم سيئ لدى شركة واحدة أن يجمد خمس الإنترنت؟
على الرغم من أن اسم Cloudflare قد لا يبدو مألوفاً لعامة المستخدمين، إلا أنه يشكل إحدى الركائز “غير المرئية” للبنية التحتية للشبكة الحديثة. فالشركة، ومقرها سان فرانسيسكو، تشغل شبكة عالمية لتوصيل المحتوى والحماية تشمل:
- العمل كطبقة وسيطة (Reverse Proxy) بين المواقع وزوارها.
- تصفية حركة المرور المشبوهة.
- تسريع الحركة الشرعية عبر التخزين المؤقت (Caching) وخطوطها الخاصة.
- توفير خدمات DNS وأمن “الوصول الصفري الثقة” (Zero Trust) وغيرها.
تؤكد الشركة أنها تخدم عشرات ملايين الطلبات HTTP في الثانية من أكثر من 330 مدينة حول العالم، في حين تضعها التقديرات المستقلة عند مستوى خدمة خمس مواقع الإنترنت تقريباً، واعتماد نحو 35% من شركات Fortune 500 على منصتها.
بمثل هذا الحجم، تصبح صورة الإنترنت أقرب إلى “باب واحد مشترك” يمر منه الجميع. فإذا تعطل هذا الباب ولو قليلاً، وجد المستخدمون أنفسهم خارج الخدمات، ولو كانت خوادم تلك الخدمات نفسها تعمل بشكل مثالي.
لم يكن غريباً أن تهبط أسهم Cloudflare في التداولات اللاحقة، مع إدراك المستثمرين من جديد أن حتى كبرى شركات البنية التحتية قد تتعرض لفشل واسع وعلني بهذا الشكل.
نمط مقلق يتكرر: من AWS وAzure وCrowdStrike… إلى Cloudflare
لم يكن “اليوم السيئ” لخدمات Cloudflare حادثة منفصلة عن سياق عام، بل جاء تتويجاً لشهر قاسٍ على عالم الحوسبة السحابية والبنى التحتية الرقمية، شهد سلسلة انقطاعات واسعة:
- 20 أكتوبر Amazon Web Services (AWS):
تعرضت AWS لانقطاع ضخم مرتبط بمشكلات في حل أسماء النطاقات (DNS) في منطقة US-EAST-1، ما أدى إلى تعطل أكثر من ألف خدمة وموقع حول العالم، من Reddit و Snapchat إلى Zoom ومنصات مصرفية متعددة. وقد نسبت تقارير ما بعد الحادثة السبب إلى “شرط سباق” (Race Condition) وعيب كامن في نظام إدارة DNS الآلي الخاص بخدمة DynamoDB، وهو ما تسبب في سلسلة من الأعطال امتدت إلى خدمات أخرى مترابطة. - 29 أكتوبر Microsoft Azure:
بعد أقل من أسبوع، تعرضت سحابة Microsoft Azure وحزمة Microsoft 365 لانقطاع عالمي، أرجعته الشركة إلى “تغيير تهيئة غير مقصود” في خدمة Azure Front Door، وهي طبقة CDN الطرفية (Edge CDN) لدى Microsoft. هذا الخلل في الإعدادات أدى إلى أعطال في DNS ومشكلات اتصال، تسببت في تعطيل خدمات مثل Xbox، وMinecraft، وبوابات شركات، بل وحتى بعض شبكات السكك الحديدية الوطنية، قبل أن تعود Microsoft إلى تهيئة مستقرة سابقة. - حوادث سابقة أخرى:
خلال العامين الماضيين، سجلت Cloudflare نفسها عدداً من الانقطاعات في خدمات محددة؛ بدءاً من تعطل في خدمة تخزين الكائنات R2 في شهر فبراير، مروراً بسوء تهيئة في مفسر DNS في يوليو، ووصولاً إلى انقطاع في لوحة التحكم وواجهة البرمجة (Dashboard/API) في سبتمبر، وجميعها موثقة في تقارير “ما بعد الحادثة” على مدونة الشركة. وفي عام 2024، تسبب تحديث خاطئ من شركة الأمن السيبراني CrowdStrike في موجة عالمية من أعطال أنظمة Windows، أدت إلى وقف رحلات جوية وتعطيل أعمال شركات عديدة، في تذكير صارخ بمدى هشاشة مكونات برمجية مشتركة واسعة الانتشار.
القاسم المشترك بين هذه الحوادث نمط واحد؛ أنظمة معقدة، عالية الاعتماد على الأتمتة، يمكن لخطأ تهيئة واحد أو عيب برمجي بسيط فيها أن يتردد صداه عبر سلسلة من الاعتمادات المتشابكة.
وكما عبر Mehdi Daoudi، الرئيس التنفيذي لشركة المراقبة Catchpoint، فإن انقطاع Cloudflare يجب أن يكون “جرس إنذار” للعملاء الذين وضعوا عملياً “كل البيض في سلة واحدة”، عبر الاعتماد على مزود واحد من دون بديل حقيقي.
“لقد خذلنا عملاءنا” … اعتراف واضح من Cloudflare
جاءت ردة فعل قيادة Cloudflare هذه المرة شديدة الصراحة حيال أثر الانقطاع.
فقد قدم كبير مسؤولي التقنية Dane Knecht اعتذاراً علنياً، مؤكداً أن الشركة “خذلت عملاءها والإنترنت الأوسع” عندما أدى خلل في شبكتها إلى تعطيل كميات كبيرة من حركة المرور التي تعتمد على خدماتها. ووصف مدة وتأثير الحادثة بأنهما “غير مقبولين”، مشيراً إلى أن العمل جارٍ بالفعل لمنع تكرار ما حدث.
وفي بيان عبر البريد الإلكتروني لوسائل الإعلام، أوضحت Cloudflare النقاط التالية:
- الانقطاع مس “عديداً” من خدماتها بين الساعة 11:20 و14:30 بتوقيت UTC.
- السبب الجذري كان ملف تهيئة يُنشأ آلياً لإدارة “حركة المرور المريبة” (threat traffic)، تضخم حجمه إلى ما يفوق الحدود المتوقعة.
- قام المهندسون بتنفيذ إصلاح للمشكلة، ويواصلون مراقبة أي آثار متبقية مع عودة حركة المرور إلى مستوياتها الطبيعية.
- لا توجد أي مؤشرات على أن الحادثة نجمت عن هجوم أو نشاط خبيث.
- ستنشر الشركة تقريراً تفصيلياً (post-mortem) على مدونتها يشرح ملابسات الحادثة.
في إطار جهود التخفيف من الضغط أثناء عملية الاستعادة، أقدمت Cloudflare لفترة وجيزة على تعطيل أو تقييد بعض الخدمات، بما فيها شبكة VPN الاستهلاكية WARP ومنتج الوصول صفري الثقة Access في لندن، وذلك لتقليل الأحمال ريثما تستقر معدلات الأخطاء، قبل إعادة تفعيلها تدريجياً.
بطبيعة الحال، تقدم السردية الزمنية التي نشرتها Cloudflare بعد الحادثة صورة أوضح لمسار الانهيار ثم التعافي (بالإمكان الاطلاع عليها من هنا).
خارط إصلاحات مقبلة
لم يكن الاعتذار وحده محور رسالة وتقرير الشركة؛ إذ عرضت Cloudflare مجموعة من الخطوات التصحيحية الملموسة، من بينها:
- تشديد آليات التعامل مع ملفات التهيئة الداخلية: التعامل مع ملفات التكوين التي تُنشئها Cloudflare ذاتياً بقدر من الشك والتحقق لا يقل عن ذاك المخصص لمدخلات المستخدمين، بما يعني إضافة طبقات أوسع من التحقق والضبط قبل قبول هذه الملفات والعمل بها على نطاق الشبكة.
- إضافة المزيد من مفاتيح الإيقاف السريع (Kill Switches) :توسيع قدرات الشبكة على إيقاف ميزات أو وحدات محددة بصورة فورية على مستوى العالم عند الاشتباه في تسببها بمشكلة، وذلك من دون الاضطرار إلى تعطيل الوكيل بالكامل أو شل الخدمات الأخرى التي تعمل بسلاسة.
- منع أدوات التصحيح من تفاقم الأعطال: ضمان ألا تتمكن أدوات التنقيح (Debugging)، وأنظمة التقارير عن الأخطاء، وملفات التفريغ (Core Dumps)، وأدوات الرصد (Observability Tooling)، من استهلاك حصص كبيرة من المعالج (CPU) أو الذاكرة على نحو يزيد الوضع سوءاً أثناء الانقطاع.
- مراجعة أنماط الفشل في وحدات الوكيل الأساسية: إجراء مراجعة منهجية لكيفية تعامل وحدات الوكيل الأساسية مع المدخلات غير المتوقعة، وتحديد المواضع التي قد تفشل فيها بشدة (Fail Hard) بدلاً من الانحدار التدريجي (Graceful Degradation)، تمهيداً لإعادة تصميم نقاط الضعف المحتملة.
مشكلة “نقطة الفشل الواحدة” في هيكل الإنترنت
إن الأداء السريع والسجل الأمني القوي لشركة Cloudflare هما بالذات ما جعل الشركة الخيار الافتراضي لعدد هائل من المؤسسات. لكن، كما أشارت Meredith Whittaker رئيسة Signal عقب انقطاع AWS الأخير، هناك “ثلاثة إلى أربعة لاعبين” فقط يسيطرون عملياً على طبقة السحابة الحديثة، ما يترك حتى التطبيقات المهتمة بالخصوصية أمام خيارات محدودة للغاية غير العمل فوق إحدى هذه المنصات الكبرى.
كما ويشرح الخبير في الأمن السيبراني Graeme Stewart من شركة Check Point Software أن كثيراً من المؤسسات ما زالت “تشغل كل شيء عبر مسار واحد دون وجود نسخة احتياطية ذات معنى”؛ وهو تصميم يعمل على نحو رائع… إلى أن يتوقف. فإذا تعطل ذلك المسار، لا تكون هناك خطة بديلة حقيقية.
من جانبه، يطرح Daoudi سؤالاً مباشراً للعملاء: “حالات الانقطاع ستستمر. ونطاق الضرر سيتسع. فهل ستكتفون بالشكوى كلما أصيبت Cloudflare بـ’عطسة‘… أم ستبنون حلولكم مع وضع ذلك في الحسبان؟”
أما بالنسبة للمواقع والخدمات الكبرى، فإن “البناء مع وضع ذلك في الحسبان” يمكن أن يشمل:
- استخدام أكثر من مزود CDN أو DNS مع آليات تحويل تلقائي عند الفشل (Automatic Failover).
- تصميم التطبيقات بحيث تستمر بعض الوظائف الحرجة في العمل حتى خلال انقطاع المزود، مثل القدرة على صعود القطار بتذكرة رقمية (QR) مخزنة مسبقاً على هاتف المستخدم.
- اختبار خطط التعافي من الكوارث بانتظام، بدلاً من افتراض أن خدمات السحابة ستكون متاحة دائماً.
هذه الترتيبات ليست سهلة ولا رخيصة، لكنها، كما أظهرت حادثة يوم الثلاثاء، وغيرها من انقطاعات AWS وAzure مؤخراً، تمثل تكلفة وقائية أقل بكثير من الثمن المدفوع عندما يكون ملف واحد متضخم في خادم طرفي بعيد كافياً لإيقاف روبوتات الذكاء الاصطناعي، والقطارات، وبطاقات الائتمان، وسلات التسوق الإلكترونية في وقت واحد.
بالنسبة لمعظم المستخدمين، سيبقى يوم 18 نوفمبر في الذاكرة باعتباره صباحاً بدا فيه الإنترنت “معطلاً” ومضطرباً على نحو غريب. أما بالنسبة للشركات التي تعتمد في الظل على خدمات Cloudflare وأقرانها، فيفترض أن يُحفظ ذلك اليوم في السجلات كشيء آخر؛ كتذكير إضافي بأن الصمود في عصر السحابة مسألة قرار بالدرجة الأولى.
