موقعك يعمل… فلماذا لا يصل إليه أحد؟

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

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

كيف تجتمع الصورتان؟

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

من هذه الخدمات كلاود فلير — Cloudflare. وفي 18 نوفمبر 2025، كشف عطل واسع فيها جانبًا من هذه العلاقات الخفية.

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

الشركة التي قد تمر بها دون أن تقصدها

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

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

تخيّل مجمّعًا له بوابات استقبال تفحص الدخول وتدلّ الزوار على وجهاتهم، وتقدّم بعض الخدمات السريعة عند المدخل. وجودها يخفف العبء عن المباني الداخلية ويحسّن تنظيم الوصول إليها.

لكن إذا تعثّرت آلية العمل في البوابات، فقد تبقى المكاتب مضاءة والموظفون حاضرون، بينما يعجز الزوار عن الوصول.

التشبيه يشرح وظيفة الوسيط، ولا يعني أن الإنترنت كله يمر من بوابة واحدة أو أن كل مستخدمي كلاود فلير لديهم البنية نفسها.

خدمات متجاورة، ووظائف مختلفة

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

الطبقة	ما الذي تفعله؟	ما الذي ينبغي ألّا نخلطه بها؟
DNS	يقدّم معلومات تساعد على الوصول إلى عنوان الخدمة	ليس هو الخادم الذي يعرض صفحات الموقع
الوكيل العكسي وشبكة توصيل المحتوى	يستقبلان طلبات الويب، وقد يقدّمان محتوى مخزّنًا قرب الزائر	لا يعني استخدامهما انتقال جميع ملفات الموقع من استضافته الأصلية
الحماية	تفحص الطلبات وتطبّق قواعد للحد من التهديدات	لا تمنح ضمانًا ضد كل هجوم أو عطل
الاستضافة والحوسبة	تخزّنان محتوى أو تشغّلان شيفرة بحسب المنتج المستخدم	قد تكونان لدى المزوّد نفسه أو لدى جهة أخرى

وتوضّح وثائق كلاود فلير أن تفعيل الوساطة لسجل مناسب يوجّه حركة HTTP وHTTPS عبر شبكتها، بينما يختلف المسار عندما يكون السجل مخصصًا لـDNS فقط.[3]

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

ماذا حدث في 18 نوفمبر 2025؟

بحسب تقرير الشركة، بدأت الإخفاقات عند 11:20 بالتوقيت العالمي. تغيير في صلاحيات قاعدة بيانات جعل استعلامًا ينتج سجلات مكررة ضمن ملف يستخدمه نظام إدارة الروبوتات. تضخّم الملف، وانتشر عبر الشبكة، وتجاوز حدًا برمجيًا في المكوّن الذي يقرأه، فتسبّب في فشله.[1]

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

المرحلة	التوقيت العالمي	توقيت مكة
بداية التأثير	11:20	14:20
عودة الحركة الأساسية إلى وضع شبه طبيعي	14:30	17:30
إعلان عودة جميع الأنظمة إلى العمل الطبيعي	17:06	20:06

تأثرت خدمات أساسية لتوصيل المحتوى والحماية، وظهرت أخطاء من فئة 5xx، كما تأثرت خدمات أخرى، منها Turnstile. وأوضحت الشركة أن تعذّر تحميل Turnstile أثّر في دخول مستخدمين إلى لوحة التحكم.[1]

هذه مراحل تعافٍ عامة في تقرير المزوّد؛ لا تعني أن كل موقع تعطّل طوال الفترة نفسها، ولا أن سلامة الخادم الأصلي لكل موقع قد فُحصت.

خادم سليم لا يعني رحلة سليمة

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

صورة توضيحية رمزية، وليست رسمًا لبنية كلاود فلير الفعلية أو توثيقًا بصريًا للحادثة.

وهذا يغيّر طريقة مراقبة الموقع. اختبار الخدمة من داخل الخادم يجيب عن سؤال، وفتح الصفحة من شبكة خارجية يجيب عن سؤال آخر. كلاهما مهم، لكن نجاح الأول لا يضمن نجاح الثاني.

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

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

لماذا لم تمنع الشبكة الموزعة انتشار المشكلة؟

التوزيع الجغرافي مفيد عندما يتعطّل موقع أو يتضرر مسار اتصال. لكنه لا يجعل البرمجيات والإعدادات المشتركة مستقلة تلقائيًا.

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

هذا ما نسمّيه هنا الفشل المشترك: موارد تبدو متفرقة، لكنها تعتمد على عنصر قد يعطلها معًا.

والدرس الهندسي الذي نستخلصه هو أن عدد المواقع والخوادم لا يكفي للحكم على الموثوقية. علينا أن نسأل أيضًا: ما الذي تشترك فيه؟ كيف تُنشر التغييرات؟ وهل يمكن حصر أثر التغيير إذا أخطأ؟

وفي خطة مرونة لاحقة بعنوان «Fail Small»، عرضت كلاود فلير توجهًا لتقليل نطاق تأثير الأعطال، وتناولت الحاجة إلى التعامل مع فشل المكونات والواجهات دون تحويله إلى أثر أوسع.[4]

الفكرة نافعة لأي فريق تقني: صمّم النظام على أساس أن خطأ سيحدث، ثم اختبر قدرة بقية الأجزاء على الاستمرار.

لماذا تعتمد المواقع على وسيط أصلًا؟

قد يبدو السؤال طبيعيًا بعد الحادثة: لماذا نضيف طبقة قد تتعطّل؟

لأن تشغيل موقع بسرعة وحماية جيدتين يتطلب أكثر من وضع الملفات على خادم. التخزين المؤقت قرب الزائر يمكن أن يقلّل زمن الوصول والضغط على المصدر، وخدمات الحماية تساعد على فرز الحركة والتعامل مع التهديدات. ويتيح جمع هذه الوظائف لدى مزوّد متخصص الاستفادة من بنية يصعب على موقع صغير بناؤها وحده.[2]

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

لهذا لا أرى الحادثة حجة كافية للهروب من الخدمة، كما لا أرى نجاح الخدمة المعتاد مبررًا لاعتبارها معصومة. القرار الجيد يوازن المنافع والاعتماد والتكلفة.

الخطة البديلة ليست زرًا سحريًا

عبارة «إذا تعطّلت الخدمة، نتجاوزها» تبدو سهلة، إلى أن نسأل عن التفاصيل.

هل الخادم الأصلي مهيأ لاستقبال الزوار مباشرة؟ هل يملك شهادة مناسبة وسعة كافية؟ هل تسمح قواعد الوصول بذلك؟ وهل سيخسر الموقع طبقات حماية يعتمد عليها؟ وماذا عن المحتوى أو الشيفرة المستضافة لدى المزوّد نفسه؟

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

لهذا يجب أن تكون الخطة البديلة مجرّبة ومناسبة للبنية. لا أن نبتكرها أثناء العطل، أو نكشف الخادم الأصلي للعامة دون مراجعة.

وتعدد المزوّدين ليس وصفة مجانية أيضًا. يحتاج إلى مزامنة واختبارات وإدارة للشهادات والإعدادات والبيانات. وقد يضيف تعقيدًا يفوق قدرة فريق صغير على تشغيله جيدًا.

ما الذي يمكن لصاحب موقع صغير فعله؟

لا تحتاج كل مدونة إلى هندسة منصة مالية. البداية العملية هي فهم الاعتماد، ثم اختيار إجراءات تناسب حجم الضرر المحتمل:

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

وموقعنا الذي بُني باستخدام Astro ويُنشر عبر Cloudflare Pages مثال قريب: احتفاظنا بمصدره في GitHub يساعد على قابلية إعادة البناء والنشر، لكنه لا يشكّل وحده تحويلًا تلقائيًا إلى استضافة أخرى. يلزم إعداد الوجهة البديلة والتحقق من أي وظائف تعتمد على منصة بعينها.

لا نحتاج إلى أسطورة جديدة عن «مالك الإنترنت»

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

مواقع مختلفة قد تشترك في مزوّد مهم، وتتأثر بخدمة محددة لديه. هذا اعتماد يستحق الدراسة، لكنه لا يعني أن جميع الشبكات والمواقع والاتصالات العالمية تخضع لشركة واحدة.

وبالمثل، لا تكفي الحادثة لإعلان أن منافسًا آخر أسرع أو أكثر أمانًا في كل الظروف. المقارنات الجيدة تحدد الخدمة والمنطقة والحمل والإعداد والتكلفة، ثم تقيس.

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

ما وراء الصفحة التي لا تفتح

عندما يقول الخادم «أنا أعمل»، فهو يصف حالته. أما المستخدم فيحكم على الرحلة كلها: هل وصل؟ وهل أنجز ما جاء من أجله؟

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

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

قد يبقى البيت مضاءً، بينما يتعطّل الطريق المؤدي إليه. وعلى الإنترنت، سلامة البيت وحدها لا تكفي.

---

مصادر ومراجع

1. تقرير كلاود فلير عن عطل 18 نوفمبر 2025 — مصدر سبب الحادثة وتوقيتها والخدمات المتأثرة؛ التفاصيل من رواية الشركة المنشورة.
2. البنية المرجعية لشبكة توصيل المحتوى ودور الوكيل العكسي.
3. الفرق بين السجلات الممرّرة عبر الوكيل وسجلات DNS فقط.
4. خطة المرونة وتقليل نطاق الأعطال: Fail Small.

أُعدّ المقال في 21 أكتوبر 2026، مستندًا إلى واقعة تاريخية وتحليل لبنية الاعتماد على الخدمات. الصور تصورات تحريرية أصلية، وليست صورًا من العطل. لا يفترض المقال تأثر موقع HD.39 بتلك الحادثة.