كلودفلاري الرئيسية 18 نوفمبر انقطاع - ملخص

في 18 نوفمبر 2025، سقطت شريحة كبيرة من الإنترنت.
إذا فتحت ChatGPT أو X (تويتر) أو League of Legends أو Shopify أو Coinbase أو عدد لا يحصى من المواقع الأصغر، فقد تم استقبالك بصفحة خطأ 5xx تحمل علامة Cloudflare - أو لم يتم تحميل المواقع على الإطلاق. ما بدا للوهلة الأولى وكأنه لحظة كبيرة أخرى من لحظات "الإنترنت معطلة" اتضح أنه شيء أكثر دقة وأكثر إثارة للقلق من بعض النواحي: خطأ ذاتي في عمق البنية التحتية الخاصة ب Cloudflare.

فيما يلي عرض تفصيلي لما حدث في انقطاع خدمات Cloudflare بالأمس (18 نوفمبر 2025)، وسبب حدوثه، ومن تأثر به، والدروس التي يجب أن تستخلصها فرق البنية التحتية من هذا الانقطاع.

ماذا حدث بالفعل بالأمس؟

في يوم الثلاثاء، 18 نوفمبر 2025، في وقت متأخر من صباح يوم الثلاثاء 18 نوفمبر 2025، في وقت متأخر من الصباح بالتوقيت العالمي المنسق، بدأت Cloudflare في إعادة كميات كبيرة من أخطاء خادم HTTP 5xx لحركة المرور التي مرت عبر شبكتها. بالنسبة للمستخدمين النهائيين، كان ذلك يعني صفحات "خطأ داخلي في الخادم" أو "خطأ في البوابة" عند محاولة الوصول إلى العديد من المواقع الإلكترونية والتطبيقات الشائعة.

وفقاً لمدونة Cloudflare الخاصة بعد الحادث، فإن الانقطاع

• بدأ التأثير على حركة مرور HTTP للعملاء في الساعة 11:28 بالتوقيت العالمي المنسق

• شهدت أخطاء 5xx واسعة الانتشار عبر شبكة CDN الأساسية وخدمات الأمان

• تم اتخاذ خطوات تخفيف رئيسية حوالي الساعة 13:05 - 14:30 بالتوقيت العالمي المنسق

• عودة حجم الخطأ 5xx إلى خط الأساس بحلول الساعة 17:06 بالتوقيت العالمي المنسق مدونة Cloudflare

وصفته Cloudflare نفسها بأنه أسوأ انقطاع لها منذ عام 2019، لأنه لم يؤثر فقط على ميزة واحدة أو لوحة تحكم واحدة - بل عطل طبقة الوكيل الأساسية التي توجه غالبية حركة مرور العملاء عبر شبكتها. مدونة Cloudflare

دعمت مراقبة الجهات الخارجية هذا الأمر. لاحظت Cisco ThousandEyes انقطاعًا عالميًا أثّر على Cloudflare، مع وجود مهلات وأخطاء 5xx على خدمات مثل X وOpenAI (ChatGPT) وApenAI (ChatGPT) وAthropic، بينما بدت مسارات الشبكة نفسها سليمة. أشار ذلك بقوة إلى فشل في خدمة الواجهة الخلفية، وليس مشكلة على مستوى مزود خدمة الإنترنت أو التوجيه. ألف عين

من الذي تأثر؟

نظرًا لأن Cloudflare تقع أمام جزء كبير من الإنترنت (حوالي 20% من مواقع الويب تعتمد على Cloudflare للأداء والأمان)، كان نصف قطر الانفجار هائلًا. AP News+1

من بين الخدمات التي تم الإبلاغ عن تأثرها

• ChatGPT / OpenAI

• X (تويتر سابقًا)

• Canva، و Shopify، و Dropbox، و Coinbase

• League of Legends ومنصات الألعاب الأخرى

• العديد من مواقع النقل العام والمواقع الحكومية، بما في ذلك نيوجيرسي ترانزيت وأنظمة السكك الحديدية الرقمية الفرنسية SNCF AP News+1

سجلت أدوات تعقب انقطاع الخدمة مثل Downdetetector آلاف التقارير المتزامنة عن المشاكل في ذروتها. وأبلغت رويترز عن حوالي 5,000 مستخدم متأثرين ب X وحده في مرحلة ما، قبل أن ينخفض العدد مع بدء الإصلاحات. رويترز

من وجهة نظر المستخدم، تجلّى ذلك على النحو التالي:

• عدم تحميل المواقع على الإطلاق

• تعطل تدفقات تسجيل الدخول أو فشلها (خاصةً عند استخدام Cloudflare Access أو Turnstile)

• استجابة واجهات برمجة التطبيقات بشكل متقطع أو مع وجود أخطاء 5xx

• توقفت لوحات التحكم ولوحات الإدارة عن العمل

بعبارة أخرى: أجزاء كبيرة من الإنترنت "تعطلت"، على الرغم من أن السبب الجذري كان يتركز في الأنظمة الداخلية لمزود واحد.

كيف تعمل Cloudflare عادةً (بعبارات بسيطة)

لفهم سبب شدة هذا الانقطاع، من المفيد معرفة المسار التقريبي للطلب عبر شبكة Cloudflare.

تعمل Cloudflare كشبكة CDN بروكسي عكسي وطبقة أمان:

1. يتصل متصفحك أو تطبيقك بـ Cloudflare بدلاً من الاتصال مباشرةً بالموقع الأصلي.

2. تقوم Cloudflare بإنهاء TLS و HTTP على حافتها.

3. تتدفق الطلبات إلى نظام الوكيل الأساسي لـ Cloudflare، المسمى FL ("الخط الأمامي") والجيل الأحدث FL2.

4. هذا الوكيل الأساسي

   • يطبق قواعد WAF (جدار حماية تطبيقات الويب)

   • يدير نماذج إدارة الروبوتات

   • يتعامل مع حماية DDoS، والتخزين المؤقت، والخروج إلى الأصل

   • يوجّه حركة المرور إلى منتجات داخلية أخرى مثل Workers و R2 و Access، إلخ. مدونة Cloudflare

في التشغيل العادي، تكون هذه البنية مرنة للغاية: إذا واجه أحد مراكز البيانات مشكلة، يتم توجيه حركة المرور عبر مراكز أخرى؛ يتم نشر تغييرات التكوين بعناية؛ يجب أن تفشل الميزات الفردية بطرق مضمنة.

كان انقطاع يوم أمس سيئًا على وجه التحديد لأن الفشل كان داخل مسار الوكيل المشترك نفسه، وكان مقترنًا بإحكام بملف تهيئة يتم دفعه في جميع أنحاء العالم بشكل متكرر وتلقائي.

السبب الجذري: ملف خاصية إدارة الروبوتات الذي أصبح مارقاً

يشير التفسير الرسمي لـ Cloudflare إلى سبب رئيسي واحد
ملف تكوين ميزة يستخدمه نظام إدارة البوتات الخاص بهم. مدونة Cloudflare

إليك سلسلة الأحداث بلغة واضحة:

1. تستخدم إدارة الروبوتات "ملف ميزة"

   • يعتمد نموذج Cloudflare لاكتشاف الروبوتات على مجموعة من "الميزات" - إشارات حول كل طلب يُستخدم لتحديد ما إذا كان الطلب بشريًا أو روبوتًا.

   • يتم تجميع هذه الميزات في ملف تهيئة يتم إنشاؤه كل بضع دقائق ويتم نشره على مستوى العالم، حتى تتمكن Cloudflare من التكيف بسرعة مع أنماط الهجوم الجديدة. مدونة Cloudflare

2. تغيير في سلوك استعلام ClickHouse

   • يتم إنشاء ملف الميزة عن طريق الاستعلامات ضد قاعدة بيانات ClickHouse.

   • أجرت Cloudflare تغييرًا في حوالي الساعة 11:05 بالتوقيت العالمي المنسق لتحسين الأمان والأذونات للاستعلامات الموزعة - مما يسمح للمستخدمين برؤية البيانات الوصفية ليس فقط من المخطط الافتراضي ولكن أيضًا من جداول r0 الأساسية. مدونة Cloudflare

   • لم يقم الاستعلام الذي ينشئ قائمة الميزات بالتصفية حسب اسم قاعدة البيانات؛ وفجأةً بدأ في الحصول على أعمدة مكررة من كل من المخطط الافتراضي و r0، مما ضاعف عدد صفوف الميزات بشكل فعال.

3. انفجر ملف الميزة في الحجم

   • تحتوي وحدة إدارة الروبوتات على حد صارم لعدد الميزات التي ستقبلها (تم تعيينه إلى 200، وهو أعلى بكثير من 60 ميزة تقريبًا المستخدمة عادةً).

   • عندما تجاوز الملف الذي تم إنشاؤه حديثًا هذا الحد، اصطدمت الوحدة بالحد الأقصى وأصيبت بالذعر، بسبب خطأ لم تتم معالجته في شيفرة Rust التي استخدمت Result::unrap() على قيمة خطأ. مدونة Cloudflare

4. بدأت خدمات الوكيل الأساسية في إرجاع أخطاء 5xx

   • نظرًا لأن إدارة الروبوتات مدمجة في مسار الوكيل الأساسي، فقد ظهر الذعر على شكل ردود HTTP 5xx لأي حركة مرور تعتمد على تلك الوحدة.

   • على محرك FL2 الجديد، رأى العملاء أخطاء 5xx صريحة.

   • أما على محرك FL القديم، فقد انخفضت نتائج الروبوتات بصمت إلى الصفر، مما قد يتسبب في نتائج إيجابية خاطئة في قواعد حظر الروبوتات. مدونة Cloudflare

5. الجزء السيء حقًا: ظل الملف يتقلب بين "جيد" و"سيء"

   • كان يجري تحديث مجموعة ClickHouse تدريجيًا، وكان ملف الميزة يُعاد إنشاؤه كل خمس دقائق.

   • في بعض الأحيان كان الاستعلام يعمل على العُقد المحدّثة (ينتج ملفاً سيئاً)، وأحياناً على العُقد غير المحدّثة (ينتج ملفاً جيداً).

   • هذا يعني أنه لفترة من الوقت، تأرجحت شبكة Cloudflare بين التشغيل العادي والفشل حيث تم نشر إصدارات مختلفة من الملف. مدونة Cloudflare

هذا التذبذب جعل الوضع مربكاً للغاية داخلياً. في البداية، اشتبهت فرق كلاودفلير في هجوم DDoS واسع النطاق لأن نمط الخطأ لم يبدو وكأنه عطل بسيط في البرنامج. حتى أن صفحة حالة Cloudflare، التي يتم استضافتها خارج بنيتها التحتية، أظهرت أخطاءً لفترة وجيزة - وهي مصادفة زادت من الشك في وجود هجوم خارجي. مدونة Cloudflare+1

لم تتضح الصورة إلا بعد أن أدركوا أن العامل المشترك هو ملف خاصية الروبوت.

الجدول الزمني للحادثة

استنادًا إلى تقرير ما بعد الوفاة الخاص بـ Cloudflare وتقارير الطرف الثالث، يمكننا تجميع جدول زمني تقريبي لـ 18 نوفمبر 2025: مدونة Cloudflare+مدونةCloudflare+2ThousandEyes+2

• 11:05 بالتوقيت العالمي المنسق - تم نشر تغيير التحكم في الوصول إلى قاعدة البيانات في ClickHouse.

• 11:20 - 11:11:30 بالتوقيت العالمي المنسق - بدء إنشاء إصدارات سيئة من ملف ميزة إدارة الروبوتات ونشرها.

• 11:28 بالتوقيت العالمي المنسق - أول تأثير على العميل: شوهدت أخطاء HTTP 5xx مرتفعة في حركة مرور العملاء.

• 11:30 - 11:30 - 11:32 بالتوقيت العالمي المنسق - بدأت أدوات المراقبة الخارجية والاختبارات الآلية في اكتشاف الأعطال المتقطعة.

• 11:35 بالتوقيت العالمي المنسق - كلاودفلير تفتح مكالمة داخلية بشأن الحادث؛ يبدأ التحقيق.

• ~11:48:48 بالتوقيت العالمي المنسق - كلاود فلير تنشر تحديثًا للحالة يؤكد وقوع حادث. إعادة إرسال

• 11:30 - 13:05 بالتوقيت العالمي المنسق - تركز الفرق على ما يبدو أنه تدهور في سلوك العاملين KV والتحقيق في الأسباب المحتملة المتعددة (بما في ذلك سيناريوهات الهجوم).

• 13:05 بالتوقيت العالمي المنسق - التخفيف الرئيسي: يتم تحويل Workers KV و Cloudflare Access لتجاوز الوكيل الأساسي؛ يتم تقليل التأثير. مدونة Cloudflare

• 14:30 بالتوقيت العالمي المنسق - تم تحديد السبب الجذري؛ تم إيقاف توليد ونشر ملفات الميزات السيئة. يتم إدراج ملف تكوين معروف جيد يدويًا وإعادة تشغيل الوكيل الأساسي. تعود معظم حركة المرور الأساسية إلى طبيعتها. مدونة Cloudflare

• 14:40 - 15:30 بالتوقيت العالمي المنسق - تستمر مشاكل لوحة التحكم وتسجيل الدخول مع استمرار مشاكل الباب الدوار وتراكم محاولات المصادقة مما يؤدي إلى ارتفاعات ثانوية في التحميل. مدونة كلاودفلير

• 17:06 بالتوقيت العالمي المنسق - عودة معدلات الخطأ إلى خط الأساس؛ كلاودفلير تعلن أن الأنظمة طبيعية تمامًا. مدونة كلاودفلير

من وجهة نظر المستخدم، بدا الانقطاع أسوأ ما يكون في وقت متأخر من الصباح الباكر إلى وقت مبكر بعد الظهر بالتوقيت العالمي المنسق، على الرغم من أن نوافذ التأثير الدقيقة تختلف حسب المنطقة ومنتجات Cloudflare التي تعتمد عليها كل خدمة من منتجات Cloudflare.

لماذا هذا الانقطاع مهم جداً

مخاطر المركزية

تعد Cloudflare جزءًا من مجموعة صغيرة من مزودي البنية التحتية المركزية للإنترنت، إلى جانب المنصات السحابية الرئيسية (AWS، Azure، GCP) وشبكات CDN الكبيرة الأخرى. عندما يفشل أحد هؤلاء اللاعبين، يكون التأثير واسعاً وغالباً ما يكون غير واضح.

هذا الانقطاع:

• لم يأتِ من عطل في توجيه BGP أو انقطاع كابل مزود خدمة الإنترنت.

• لم يأتِ من هجوم خبيث (على الرغم من الشكوك الأولية).

• جاء من تكوين واحد وحدود خطأ في مكون داخلي.

هذا أمر مهم لأنه يوضح كيف يمكن أن تفشل الأنظمة المعقدة والمترابطة بإحكام بشكل كارثي حتى بدون تدخل خارجي. عندما تبني العديد من المؤسسات على نفس الموفر، يصبح هذا الموفر جزءًا مهمًا من الإنترنت بحكم الأمر الواقع.

التبعيات "الناعمة" تضررت أيضاً

بعض الخدمات المتأثرة لم تكن تستخدم Cloudflare فقط كشبكة CDN غبية. بل كانوا

• استخدام Cloudflare Access للمصادقة والوصول بدون ثقة.

• استخدام العمال KV كجزء من طائرات التحكم الداخلية.

• الاعتماد على Turnstile لتسجيل الدخول المقاوم للبوتات. مدونة Cloudflare+1

عندما تعطلت هذه المنتجات، لم يكن محتوى الموقع الإلكتروني هو الذي تعطل فحسب، بل تعطلت عمليات تسجيل الدخول ووظائف الإدارة وواجهات برمجة التطبيقات الداخلية أيضًا. وهذا يجعل الاسترداد أكثر تعقيدًا: قد تعتمد صفحة الحالة أو أدوات الحوادث أو واجهة مستخدم المشرف أيضًا على الموفر نفسه الذي فشل للتو.

ما تقول Cloudflare أنها ستغيره

توضح مدونة Cloudflare العديد من خطوات الإصلاح التي تتخذها الشركة بالفعل لتقليل مخاطر تكرار أي شيء مماثل: مدونة كلاودفلير

1. تشديد استيعاب ملفات التكوين التي يتم إنشاؤها تلقائيًا
   التعامل مع التكوينات التي تم إنشاؤها داخليًا بنفس الشكوك والتحقق من صحتها مثل المدخلات التي يوفرها المستخدم، بما في ذلك التحقق الصارم من المخطط والحجم قبل الطرح.

2. المزيد من مفاتيح الإيقاف العام
   تسهيل تعطيل الوحدات النمطية الداخلية الإشكالية بسرعة (مثل إدارة الروبوتات) عبر الشبكة، بحيث تفشل في الفتح بدلاً من إثارة الذعر في مسار الوكيل بأكمله.

3. حماية موارد النظام من عواصف الأخطاء
   تأكد من أن عمليات تفريغ البيانات الأساسية والبيانات الوصفية للتصحيح وأدوات المراقبة لا يمكن أن تطغى على وحدة المعالجة المركزية والذاكرة عندما تبدأ الأخطاء في الارتفاع.

4. مراجعة أوضاع الفشل عبر وحدات الوكيل الأساسية
   قم بمراجعة منهجية لكيفية تصرف كل وحدة نمطية داخلية في ظل المدخلات أو التكوينات غير المتوقعة، وتأكد من التدهور الرشيق بدلاً من الفشل العام.

5. صقل عمليات الطرح والعزل
   على الرغم من عدم توضيحها بتفاصيل ضخمة، إلا أن الحادثة تشير إلى أن Cloudflare ستعمل على الأرجح على تقسيم كيفية انتشار التكوينات الجديدة وسلوكيات قاعدة البيانات لتقليل فرصة تأثير تغيير واحد سيء على الأسطول بأكمله.

كما أنهم صاغوا الحادث على أنه فشل مطلق لتوقعات المرونة الخاصة بهم، واصفين إياه بـ "غير مقبول" ومعترفين صراحةً بالألم الذي سببه لكل من العملاء ومستخدمي الإنترنت العاديين. مدونة Cloudflare

الدروس المستفادة لفرق البنية التحتية وفرق SRE

حتى لو لم تكن تدير شيئًا ضخمًا مثل Cloudflare، فهناك بعض الدروس العملية في التصميم والدروس التشغيلية في هذا الانقطاع:

تعامل مع التكوين الداخلي كمدخلات غير موثوق بها

من السهل أن نفترض أن التهيئة التي تم إنشاؤها "الخاصة بنا" صحيحة دائماً. يوضح يوم أمس لماذا هذا أمر خطير:

• تحقق دائمًا من صحة حجم وشكل وحدود ملفات التكوين قبل تطبيقها.

• ضع في اعتبارك تطبيق التهيئة الكاناري على مجموعة فرعية صغيرة من حركة المرور أو العقد أولاً، مع التراجع التلقائي عند حدوث حالات شاذة.

• احتفظ بحدود عليا صارمة وقواطع دوائر حول عدد الميزات والتخصيص المسبق للذاكرة واستخدام وحدة المعالجة المركزية.

تصميم لفشل جزئي رشيق

لا ينبغي أن يؤدي خطأ واحد في وحدة إدارة الروبوتات إلى إثارة الذعر في مسار الوكيل بأكمله:

• افتراضي للفشل المفتوح مقابل الفشل المغلق في بعض طبقات الأمان عندما يكون البديل هو الانقطاع الكامل.

• بناء مفاتيح إيقاف واضحة ومختبرة للميزات غير الأساسية.

• تأكد من إمكانية تشغيل الأنظمة الفرعية الحرجة (المصادقة، صفحة الحالة، أدوات الحوادث) في الوضع المتدهور أو عبر مسارات بديلة.

مراقبة الإشارات الصحيحة

إن التذبذب بين "التهيئة الجيدة" و"التهيئة السيئة" كل خمس دقائق جعل الإشارة تبدو وكأنها حركة مرور هجومية أو سلوك خارجي صاخب:

• تأكد من وجود ارتباط لكل إصدار أو لكل تهيئة في خط أنابيب المراقبة لديك.

• أنشئ لوحات معلومات تجعل تغييرات التكوين واضحة بصرياً فوق الرسوم البيانية للأخطاء.

• قم بتضمين اختبارات تركيبية قوية من وجهة نظر خارجية، حتى تتمكن من التمييز بسرعة بين الفشل الداخلي ومشاكل الشبكة/المسار.

لا تضع كل بيضك في سلة واحدة من المعلومات

للمؤسسات التي تستخدم Cloudflare:

• ضع في اعتبارك إعدادات متعددة لشبكات CDN لخصائص المهام الحرجة حقًا.

• تجنب جعل صفحة الحالة الخاصة بك معتمدة كليًا على نفس المزود الذي يعتمد على نفس المكدس الأساسي (Cloudflare يفعل ذلك، ولكن كانت هناك مشكلة مصادفة مع مضيف صفحة الحالة بالأمس مما زاد من إرباك الأمور). مدونة Cloudflare+1

• فكّر مرتين قبل ربط المصادقة وطائرات التحكم في واجهة برمجة التطبيقات وتسليم الواجهة الأمامية بإحكام إلى نفس المزود دون مسارات احتياطية.

الصورة الأكبر

في الأشهر القليلة الماضية وحدها، شهدنا انقطاعات كبيرة في مايكروسوفت أزور وأمازون لخدمات الويب والآن Cloudflare، وكلها أدت إلى انقطاع مؤقت لخدمات المستهلكين والمؤسسات. أخبارأسوشيتدبرس+2واشنطن بوست+2

النمط واضح:

• يعتمد الإنترنت بشكل متزايد على عدد قليل من مزودي البنية التحتية العملاقة.

• وغالبًا ما تكون الانقطاعات ذاتية التسبب، حيث تأتي من تغييرات داخلية معقدة وليس من هجمات خارجية.

• حتى مقدمي الخدمات الذين يتبعون ممارسات SRE ذات المستوى العالمي يمكن أن يتعثروا بسبب التفاعلات غير المتوقعة بين التكوين وسلوك قاعدة البيانات والحدود المشفرة.

حادثة Cloudflare بالأمس هي تذكير صارخ بأن "السحابة" ليست سحراً. في الأسفل، لا تزال برمجيات مكتوبة من قبل البشر، وتخضع لنفس فئات الأخطاء مثل أي تطبيق آخر - فقط مع وجود عدد أكبر من الأشخاص الذين يعتمدون عليها.

بالنسبة للمستخدمين، سيتم تذكر الحادث في الغالب على أنه "في ذلك الصباح عندما لم يتم تحميل X و ChatGPT."
أما بالنسبة للمهندسين، فمن المرجح أن تتم دراستها كمثال مدرسي على كيفية انتشار أخطاء التكوين الخفية في نظام موزع أساسي إلى حدث عالمي على الإنترنت.