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

ماذا يفعل Cloudflare هيكلياً

يجلس Cloudflare بين الزوار وخادمك الأصلي كبروكسي عكسي: يتحلل DNS إلى عناوين IP الخاصة بـ Cloudflare، وينهي Cloudflare الاتصال، و(للسجلات المُوكَّلة) يُعيد توجيه الطلب إلى خادمك الفعلي، مُخزّناً مؤقتاً ما يستطيع ومُصفّياً ما يجب على طول الطريق. هنا يأتي معظم القيمة — تخفيف DDoS، والتخزين المؤقت، وطبقة WAF أمام خادمك الأصلي — وهنا أيضاً تأتي أوضاع الفشل المُربكة، لأن "موقعك" الآن له سياقا SSL (الزائر إلى Cloudflare، وCloudflare إلى الخادم الأصلي) يجب أن يكونا صحيحين.

وضع SSL/TLS الذي يسبب أكبر عدد من التذاكر

لإعداد SSL/TLS في Cloudflare أربعة أوضاع، واختيار الخاطئ منها هو المصدر الأكثر شيوعاً لتذاكر "موقعي فجأة يعرض حلقة إعادة توجيه":

  • معطّل (Off) — لا تشفير بين الزائر وCloudflare. لا تستخدم هذا في 2026.
  • مرن (Flexible) — يشفّر الزائر إلى Cloudflare، لكن Cloudflare إلى الخادم الأصلي بروتوكول HTTP عادي. هذا الوضع يسبب حلقات إعادة التوجيه على المواقع التي تفرض HTTPS على الخادم الأصلي، لأن الخادم يرى طلب HTTP من Cloudflare ويُعيد توجيهه إلى HTTPS، الذي يُعيد Cloudflare طلبه كـ HTTP مرة أخرى، إلى الأبد.
  • كامل (Full) — يشفّر كلا الجانبين، لكن لا يتحقق من شهادة SSL للخادم الأصلي، بحيث تظل شهادة موقّعة ذاتياً أو منتهية "تعمل" دون تحذيرك بضعفها.
  • كامل (صارم) — يشفّر كلا الجانبين ويتحقق من شهادة الخادم الأصلي مقابل جهة إصدار موثوقة. هذا هو الإعداد الصحيح لأي خادم أصلي بشهادة SSL صالحة، ويجب أن يكون تقريباً كل موقع إنتاج.

إذا كان لدى العميل خادم أصلي بشهادة صالحة بالفعل (Let's Encrypt، أو صادرة عن Plesk، أو غيرها)، فـكامل (صارم) هو الإجابة الصحيحة تقريباً دائماً. يجب أن يُعامَل Flexible كحالة مؤقتة، لا كإعداد راحة.

توكيل DNS: السحابة البرتقالية مقابل الرمادية

كل سجل DNS في Cloudflare يمكن "توكيله" (سحابة برتقالية — تمر حركة المرور عبر Cloudflare) أو "DNS فقط" (سحابة رمادية — يحل Cloudflare الاسم فقط، وتذهب حركة المرور مباشرة إلى خادمك). هذا مهم أكثر مما يبدو:

  • سجلات البريد (MX) يجب ألا تُوكَّل أبداً. لا يوكّل Cloudflare حركة SMTP؛ يجب أن تشير سجلات MX إلى IP خادم البريد الفعلي، مُحلّلة مباشرة.
  • السجلات المستخدمة للتواصل بين الخوادم (نقطة نهاية API يستدعيها خادم آخر مباشرة، مثلاً) غالباً ما يُفضَّل تركها DNS فقط، لأن التوكيل يضيف قفزة توجيه ويمكن أن يتفاعل بشكل غير متوقع مع قواعد وصول قائمة على IP على الخادم الأصلي.
  • أي شيء يُقصَد أن يستفيد من التخزين المؤقت وWAF وحماية DDoS في Cloudflare — الموقع الرئيسي، عادة — يجب أن يكون موكَّلاً.

WAF وقواعد جدار الحماية التي تستحق التفعيل افتراضياً

تشمل مستويات Cloudflare المجانية والاحترافية كلاهما مجموعة قواعد WAF مُدارة تستحق التفعيل بدلاً من تركها معطّلة "للأمان" — إنها مضبوطة لالتقاط أنماط هجوم شائعة (محاولات حقن SQL، بوتات معروفة سيئة) دون الحاجة لضبط كبير. بعد ذلك، مجموعة صغيرة من قواعد جدار الحماية تغطي معظم ما يحتاجه عميل استضافة نموذجي فعلياً: تحديد معدل على صفحات تسجيل الدخول لكسر محاولات القوة الغاشمة، وتحديات قائمة على الدولة أو ASN إذا كان الموقع لا يرى حركة مرور شرعية من مناطق معينة.

تعرض IP الأصلي — الخطأ الذي يبطل كل شيء آخر

تفعيل بروكسي Cloudflare لا يخفي بأثر رجعي IP خادم أصلي كان عاماً بالفعل قبل إضافة Cloudflare — سجلات DNS القديمة، أو تاريخ استضافة سابق، أو نطاق فرعي مُعطَّل يشير مباشرة إلى الخادم الأصلي يمكن أن تُسرّب جميعها عنوان الخادم الحقيقي. إذا تسرّب IP الخادم الأصلي، يمكن للمهاجمين تجاوز WAF وحماية DDoS في Cloudflare تماماً بضرب الخادم مباشرة. قواعد جدار حماية على الخادم الأصلي نفسه، تسمح بحركة مرور فقط من نطاقات IP المنشورة لـ Cloudflare، تُغلق هذه الفجوة بغض النظر عما يتسرب عبر تاريخ DNS.

ترتيب إعداد يتجنب التوقف

  1. أضف النطاق إلى Cloudflare وتحقق أن كل سجلات DNS الحالية استُوردت بشكل صحيح — لا تثق بالمسح التلقائي بشكل أعمى، تحقق مقابل مزود DNS السابق.
  2. اضبط وضع SSL/TLS بناءً على حالة شهادة الخادم الأصلي الفعلية — كامل (صارم) إذا وُجدت شهادة صالحة، وإلا احصل على واحدة قبل التبديل.
  3. حدّث خوادم الأسماء عند المسجّل، وتوقع تأخير انتشار قبل أن يكون Cloudflare فعلياً في مسار حركة المرور.
  4. بمجرد التشغيل، اقفل جدار حماية الخادم الأصلي على نطاقات IP الخاصة بـ Cloudflare فقط.
  5. فعّل مجموعة قواعد WAF المُدارة وتحديد معدل أساسي على النقاط الحساسة.

المبدأ الأساسي

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