باختصار، لأن كلاودفلير ليست شبكة توصيل محتوى (CDN) تقليدية.
تشير السحابة الرمادية إلى أن كلاودفلير تقدم فقط خدمة DNS لتلك العناوين.
إذا قمت بتفعيل السحابة البرتقالية، فإن ذلك يغير عنوان IP الظاهر للعالم الخارجي ويعمل كوسيط لجميع البيانات عبر شبكتها، مما يسمح لها بحماية الخادم وتخزين الأصول مثل الصور وملفات JavaScript.
القالب ضروري لأنه بمجرد أن تتوسط كلاودفلير بين موقعك والعالم الخارجي، سيرى الخادم فقط عناوين IP الخاصة بكلاودفلير كعناوين متصلة به. وباستخدام القالب، سيعود موقعك لرؤية عناوين IP الخاصة بالعملاء التي تقوم كلاودفلير بتحويلها ضمن رأس CF-Connecting-IP.
بدون إعداد هذا بشكل صحيح، ستواجه أخطاء تتعلق بحدود الاتصال وأخطاء تتعلق بعناوين IP المسجلة، حيث سيبدو أن جميع بيانات المستخدمين قادمة من عدد قليل من العناوين.
إذا قررت تمكين شبكة توصيل محتوى كلاودفلير (السحابة البرتقالية)، فيجب عليك اتخاذ خطوة إضافية وإنشاء قاعدة صفحة لعنوان مثيل Discourse الخاص بك. يجب أن تكون القاعدة “تعطيل الأداء”، مما سيوقف ميزات كلاودفلير التي يُوثق جيدًا أنها تتداخل مع عمل Discourse.
لاحظ أنه إذا كنت تستخدم كلاودفلير كواجهة أمامية لموقعك بدلاً من سلة S3، فإنك تضيف قفزات شبكية إضافية بين خادمك والعملاء عبر الإنترنت. تذكر أن Discourse ليس مجرد موقع ويب، بل هو تطبيق JavaScript. بمجرد تحميل Discourse في المتصفح، لا يقوم بتنزيل صفحات عند نقر المستخدمين على الروابط. وإضافة تلك القفزات الشبكية الإضافية سيؤدي إلى تأخير بسيط ولكنه ملحوظ إلى حد ما في كل نقرة.
ما لم يكن موقعك تحت هجوم، فإن الطريقة الذكية لاستخدام كلاودفلير هي نقل أصولك إلى S3 (تخزين الكائنات، وليس شبكة توصيل محتوى)، ثم استخدام كلاودفلير كواجهة أمامية لتخزين S3. وبهذه الطريقة، تظل اتصالات العملاء سريعة، ويقل عرض النطاق الترددي لتنزيل الأصول، والأهم من ذلك، فإنك تحرر مساحة التخزين المحلية على خادم Discourse الخاص بك.
شكرًا لك، @Stephen. كانت هذه المعلومات مفيدة للغاية. الاستنتاج الرئيسي لدي هو أن Cloudflare ربما لم تكن الخيار الصحيح لي، نظرًا لأن شبكات CDN التقليدية أقل اضطرابًا - على الرغم من عدم وجود حماية من هجمات DDoS.