خدمات Cloudflare بكلمات بسيطة وبدائلها مفتوحة المصدر

عندما تضيف نطاقك إلى Cloudflare لأول مرة فأنت غالباً تبحث عن شيء واحد، شهادة TLS مجانية أو حماية من هجوم أو طريقة لنشر خدمة من المنزل دون فتح منافذ، ثم تفتح لوحة التحكم فتجد عشرات الأسماء: Proxy وCDN وWAF وTurnstile وTunnel وZero Trust وWorkers وR2 وEmail Routing، وكل اسم منها له خطة مجانية وخطط مدفوعة وحدود لا تظهر إلا في التوثيق. ومن يستضيف خدماته بنفسه يسأل بعد ذلك سؤالاً منطقياً: ما الذي تقدمه كل خدمة من هذه بالضبط؟ وهل يوجد لها بديل مفتوح المصدر أشغله على سيرفري؟ وأين يكون البديل مساوياً لها، وأين لا يمكن استبدالها أصلاً؟

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

وسوف نناقش في هذا المقال ما يلي:

• ما الذي يحدث عندما يمر موقعك عبر Cloudflare، بمخرجات حقيقية لأمري dig وcurl.
• خدمات الشبكة والسرعة: استضافة DNS، وال Proxy، والتخزين المؤقت CDN، وتحسين المسارات Argo.
• خدمات الحماية: صد هجمات DDoS، وجدار حماية تطبيقات الويب WAF، والحماية من الروبوتات Bots وTurnstile، وشهادات SSL/TLS، ووضع Under Attack.
• خدمات الوصول: Cloudflare Tunnel، وZero Trust Access، وWARP، وSpectrum.
• منصة المطورين: Pages وWorkers وR2 وKV وD1 وImages وStream.
• خدمات أخرى: Email Routing وWeb Analytics وتسجيل النطاقات Registrar وZaraz.
• كيف تستخدم Cloudflare مع سيرفرك بشكل صحيح، والأخطاء التي تكشف سيرفرك أو تسرب بيانات مستخدميك.
• الخصوصية والسيادة على البيانات، ثم جدولاً يجمع كل خدمة وبديلها.

ماذا يحدث عندما يمر موقعك عبر Cloudflare؟

Cloudflare شبكة كبيرة من مراكز البيانات، وتقول الشركة في صفحة شبكتها إنها موجودة في 348 مدينة في أكثر من 100 دولة، وكل مركز من هذه المراكز يسمى نقطة تواجد Point of Presence واختصاراً PoP. وعندما تجعل سجل موقعك يمر عبرها فإن الزائر لا يتصل بسيرفرك، وإنما يتصل بأقرب نقطة تواجد إليه، وهناك تتم كل الخدمات التي سوف نتحدث عنها: صد الهجمات وفحص الطلب والرد من الذاكرة المؤقتة، ثم تمر الطلبات التي تحتاج إلى سيرفرك فقط إلى السيرفر الأصلي Origin Server. وأقرب تشبيه لذلك هو موظف الاستقبال في مبنى شركة، فالزائر يقف عنده أولاً، فيتأكد من هويته ويرد على الأسئلة المعتادة بنفسه، ولا يصعد إلى المكاتب إلا من يحتاج إليها فعلاً.

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

ولنأخذ مثالاً حقيقياً، فالنطاق example.com المعروف يمر اليوم عبر Cloudflare، والأمر التالي يسأل عن عنوانه وعن سيرفرات DNS التي تديره:

dig +short example.com A
dig +short NS example.com

والمخرج سوف يكون كما يلي:

104.20.23.154
172.66.147.243
hera.ns.cloudflare.com.
elliott.ns.cloudflare.com.

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

curl -s https://www.cloudflare.com/ips-v4

173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22

والآن نطلب ترويسات الصفحة نفسها:

curl -sI https://example.com

HTTP/1.1 200 OK
Date: Mon, 05 Oct 2026 06:16:08 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Server: cloudflare
last-modified: Fri, 02 Oct 2026 16:11:02 GMT
allow: GET, HEAD
Accept-Ranges: bytes
Age: 9848
cf-cache-status: HIT
CF-RAY: a45a4bba3997e219-MRS
alt-svc: h3=":443"; ma=86400

في المخرج أعلاه لاحظ التالي:

• Server: cloudflare: الذي أجاب عن الطلب هو Cloudflare وليس السيرفر الأصلي.
• cf-cache-status: HIT وAge: 9848: الصفحة جاءت من الذاكرة المؤقتة Cache في نقطة التواجد، ومضى على نسختها 9848 ثانية، أي أن السيرفر الأصلي لم يعلم بهذا الطلب أصلاً.
• CF-RAY: معرف الطلب في Cloudflare، وآخره MRS هو رمز نقطة التواجد التي أجابت، وهذا المعرف هو أول ما يطلبه منك الدعم الفني عند أي مشكلة.

وقبل أن نبدأ بالخدمات يجب أن تعرف خطط Cloudflare، ف صفحة الخطط في أكتوبر 2026 تعرض الخطة المجانية Free، وخطة Pro بسعر 20 دولاراً شهرياً عند الدفع السنوي أو 25 دولاراً شهرياً، وخطة Business بسعر 200 دولار شهرياً عند الدفع السنوي أو 250 دولاراً شهرياً، ثم خطة Enterprise بعقد خاص. أما خدمات المطورين مثل Workers وR2 فلها تسعير منفصل حسب الاستخدام. وكلما ذكرنا في هذا المقال أن خدمة متاحة في الخطة المجانية فالمصدر هو صفحة التوثيق المرتبطة بها، لأن الحدود تتغير من وقت لآخر، لذلك راجع الصفحة نفسها قبل أن تبني قرارك عليها.

والصورة التالية تجمع الخدمات التي سوف نمر عليها في خمس مجموعات، وبجانب كل خدمة البدائل مفتوحة المصدر، ولون الدائرة يبين هل يستبدلها البديل كاملة أم جزءاً منها أم لا يوجد بديل تستضيفه:

الشبكة والسرعة: DNS وال Proxy والتخزين المؤقت

استضافة DNS: من يجيب عن اسم نطاقك؟

كل نطاق يحتاج إلى سيرفر DNS موثوق Authoritative DNS يجيب عن أسئلة الناس عن سجلاته، أي ما عنوان example.com وأين يستلم البريد، وCloudflare تقدم هذه الخدمة في كل الخطط، وتقول في الأسئلة الشائعة إنها لا تحاسب الخطط Free وPro وBusiness على عدد الاستعلامات ولا تضع حداً لها. ومعها DNSSEC بضغطة زر. وقد شرحنا DNS وسجلاته بالتفصيل في شرح DNS وسجلاته للمبتدئين، فلن نعيده هنا.

والبديل مفتوح المصدر موجود ومستقر منذ سنوات، ف PowerDNS Authoritative Server برخصة GPL-2.0 يحفظ السجلات في قاعدة بيانات ويقدم واجهة HTTP API، وTechnitium DNS Server برخصة GPL-3.0 يقدم واجهة ويب سهلة ويعمل كسيرفر موثوق وكسيرفر بحث Recursive معاً. وقد يتساءل البعض: هل يستحق الأمر أن أستضيف DNS نطاقي بنفسي؟ والإجابة في الغالب لا، والسبب أن نطاقك يحتاج إلى سيرفرين على الأقل في مكانين مختلفين، فإذا توقف السيرفر الوحيد توقف كل شيء معه حتى البريد، بينما تقدم Cloudflare والمسجلون الآخرون هذه الخدمة مجاناً على شبكة موزعة. لذلك يكون البديل مناسباً عندما تريد DNS داخلياً لشبكة شركتك، أو عندما تمنعك سياسة المؤسسة من وضع سجلاتها عند مزود خارجي، وعندها شغل سيرفرين في موقعين مختلفين.

ال Proxy أو السحابة البرتقالية: Cloudflare أمام سيرفرك

عندما تجعل السجل Proxied يجيب Cloudflare عن اسم موقعك بعناوينه هو، فتمر كل حركة HTTP وHTTPS عبر شبكته، وهذا الزر هو الذي يفعل كل خدمات الحماية والتخزين المؤقت التي في هذا المقال، فبدونه لا يمر شيء عبر Cloudflare سوى سؤال DNS. ووظيفته في الأساس هي وظيفة ال Reverse Proxy نفسها: يستقبل الطلب نيابة عن سيرفرك ثم يمرره إليه، كما يشرح توثيق Proxy status.

والبديل على سيرفرك هو ال Reverse Proxy الذي تستخدمه في كل أدلة الموقع، مثل Nginx Proxy Manager وCaddy وTraefik، وقد قارنا بينها في مقارنة Nginx Proxy Manager وTraefik وHAProxy. ولاحظ أن الاثنين لا يتعارضان، فأغلب من يستخدم Cloudflare يبقي Reverse Proxy على سيرفره كذلك، فيوزع الطلبات على التطبيقات ويصدر الشهادات، ويكون Cloudflare طبقة إضافية أمامه. والفرق الحقيقي أن ال Reverse Proxy على سيرفرك يعمل في مكان واحد، فلا يقرب موقعك من الزائر ولا يصد عنه هجوماً أكبر من اتصال السيرفر بالإنترنت.

التخزين المؤقت CDN: نسخة من موقعك قرب الزائر

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

curl -sI "https://example.com/?test=arabroot1" | grep -i -E "^HTTP|^server|cf-cache-status|^age"
curl -sI "https://example.com/?test=arabroot1" | grep -i -E "^HTTP|^server|cf-cache-status|^age"

والمخرج سوف يكون كما يلي:

HTTP/1.1 200 OK
Server: cloudflare
cf-cache-status: MISS
HTTP/1.1 200 OK
Server: cloudflare
Age: 0
cf-cache-status: HIT

في الطلب الأول كانت الحالة MISS، أي أن نقطة التواجد لم تجد نسخة فطلبت الصفحة من السيرفر الأصلي، وفي الطلب الثاني أصبحت HIT بعمر صفر ثانية، أي أن النسخة حفظت للتو. ويجدر الإشارة هنا إلى أمر لا ينتبه له الكثيرون: Cloudflare لا تحفظ صفحات HTML ولا ردود JSON بشكل افتراضي، وإنما تحفظ الملفات الثابتة بحسب امتدادها مثل CSS وJavaScript والصور والخطوط وPDF، كما يبين توثيق السلوك الافتراضي للتخزين المؤقت. وإذا أردت أن تحفظ صفحات HTML فعليك بقواعد التخزين المؤقت Cache Rules، والخطة المجانية فيها 10 قواعد، و Pro فيها 25، وBusiness فيها 50. والخدمة نفسها، أي التخزين المؤقت مع عدد غير محدود من الزيارات، متاحة في الخطة المجانية.

والبديل مفتوح المصدر للتخزين المؤقت على سيرفرك هو Varnish Cache برخصة BSD-2-Clause، وهو مخصص لهذه الوظيفة منذ سنوات، ولاحظ أن نسخة المجتمع منه انتقلت إلى اسم جديد هو Vinyl Cache، بينما تكمل شركة Varnish Software تطوير نسختها بالاسم القديم. والأبسط من ذلك أن تستخدم التخزين المؤقت في ال Reverse Proxy الذي تستخدمه أصلاً، مثل تعليمات proxy_cache في Nginx، أو وحدة cache-handler الرسمية في Caddy التي تضيفها عند بناء Caddy لأنها ليست في النسخة الافتراضية.

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

Argo Smart Routing: طريق أسرع بين Cloudflare وسيرفرك

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

الحماية: من هجمات DDoS إلى الروبوتات

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

صد هجمات DDoS: لماذا يعجز سيرفرك وحده عن صدها؟

هجوم حجب الخدمة الموزع Distributed Denial of Service واختصاراً DDoS هو أن يرسل آلاف الأجهزة المخترقة حركة إلى موقعك في الوقت نفسه حتى يتوقف عن الرد على الزوار الحقيقيين، وCloudflare تقدم حماية من هجمات DDoS دون حد للحجم Unmetered على طبقات الشبكة من 3 إلى 7 في كل الخطط ومنها الخطة المجانية، ولا تحاسبك على حجم الهجوم.

وقد يتساءل البعض: هل يوجد بديل مفتوح المصدر أثبته فيحمي سيرفري من DDoS؟ والإجابة الصريحة لا، على الأقل ليس للهجمات الكبيرة. والسبب أن الهجوم الحجمي Volumetric Attack يملأ الاتصال بين سيرفرك والإنترنت قبل أن يصل إلى أي برنامج على السيرفر، فإذا كان اتصال سيرفرك 1 Gbps وجاءه هجوم بعشرة أضعاف ذلك فلن يصل الزوار الحقيقيون مهما كان جدار الحماية على السيرفر ذكياً، كما أن الماء الذي يغرق الشارع لا يوقفه قفل باب البيت. والحل هنا عند من يملك شبكة أكبر من الهجوم، أي Cloudflare أو مزود السيرفر نفسه، فبعض مزودي VPS يقدمون حماية DDoS على مستوى الشبكة ضمن السعر، وهذا من الأسئلة التي ذكرناها في كيف تختار خادماً افتراضياً VPS.

أما الهجمات الصغيرة على طبقة التطبيق Layer 7، مثل آلاف الطلبات على صفحة البحث أو صفحة الدخول، فلها أدوات مفتوحة المصدر على سيرفرك: الحد من معدل الطلبات Rate Limiting في ال Reverse Proxy، وCrowdSec الذي يحظر العناوين بحسب سلوكها ويشارك قوائم العناوين المسيئة مع مستخدميه، ومحركه برخصة MIT. وكلاهما مشروح في دليل الحماية الذي ذكرناه.

جدار حماية تطبيقات الويب WAF

جدار حماية تطبيقات الويب Web Application Firewall واختصاراً WAF يقرأ محتوى كل طلب، ويحظر الطلبات التي تشبه هجوماً معروفاً، مثل حقن SQL Injection أو محاولة استغلال ثغرة منشورة في WordPress. والخطة المجانية في Cloudflare فيها مجموعة القواعد المجانية Free Managed Ruleset التي تغطي الثغرات الأوسع انتشاراً، و5 قواعد مخصصة Custom Rules تحظر بها دولة أو مساراً أو عنواناً، وقاعدة واحدة للحد من معدل الطلبات بفترة عد ثابتة 10 ثوان. أما مجموعة Cloudflare Managed Ruleset الكاملة ومجموعة OWASP Core Ruleset فهي من خطة Pro فما فوق.

وفي هذه الخدمة البدائل مفتوحة المصدر قريبة جداً مما تقدمه Cloudflare، بل إن Cloudflare نفسها تقدم نسخة من قواعد OWASP:

• ModSecurity برخصة Apache-2.0: أقدم WAF مفتوح المصدر، وأصبح اليوم مشروعاً تحت رعاية OWASP، ويعمل مع OWASP CRS وهي مجموعة القواعد العامة برخصة Apache-2.0.
• OWASP Coraza برخصة Apache-2.0: WAF مكتوب بلغة Go ومتوافق مع قواعد ModSecurity ويشغل CRS نفسها، ويدخل في Caddy وغيره كوحدة إضافية.
• BunkerWeb برخصة AGPL-3.0: Reverse Proxy مبني على NGINX ومعه WAF وواجهة ويب، وله نسخة PRO مدفوعة.
• SafeLine من شركة Chaitin برخصة GPL-3.0: Reverse Proxy مع WAF وواجهة ويب، وله كذلك نسخة مدفوعة.

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

الحماية من الروبوتات وTurnstile

ليس كل من يزور موقعك إنساناً، فهناك محركات البحث، وهناك أدوات تجمع المحتوى Scrapers، ومنها اليوم روبوتات شركات الذكاء الاصطناعي، وهناك من يجرب كلمات المرور آلياً. وCloudflare تقدم ثلاث مستويات: Bot Fight Mode في الخطة المجانية، وSuper Bot Fight Mode في Pro وBusiness، وBot Management مع درجة لكل طلب في Enterprise. وتقدم كذلك AI Crawl Control في كل الخطط، وفيه ترى روبوتات الذكاء الاصطناعي التي تزور موقعك وتسمح أو تحظر كل واحد منها. ويمكنك أن ترى هذه الحماية من الطرف الآخر، فالأمر التالي يطلب صفحة من موقع يحمي نفسه ب Cloudflare:

curl -sI https://www.npmjs.com/ | grep -i -E "^HTTP|^server:|cf-mitigated|^cf-ray"

HTTP/1.1 403 Forbidden
Cf-Mitigated: challenge
Server: cloudflare
CF-RAY: a45a679e3df48b7f-MRS

لاحظ أن الرد 403 مع الترويسة Cf-Mitigated: challenge، أي أن Cloudflare لم تمرر الطلب إلى الموقع، وإنما ردت بصفحة تحقق Challenge لا يستطيع curl أن يجتازها لأنه لا ينفذ JavaScript، بينما يفتح المتصفح الصفحة نفسها بشكل عادي. وهذا ما تريده لصفحة الدخول، وما لا تريده لواجهة API يستخدمها تطبيق، لذلك عليك أن تستثني مسارات ال API من هذه الحماية.

أما Turnstile فهو بديل Cloudflare لاختبار CAPTCHA الذي تضعه في نموذج الدخول أو التسجيل، ولا يطلب من المستخدم أن يختار صور الإشارات، ويعمل على أي موقع حتى لو لم يمر عبر Cloudflare، والخطة المجانية منه تعطيك 20 Widget في الحساب و10 نطاقات لكل Widget.

والبدائل مفتوحة المصدر هنا تعمل بفكرة إثبات العمل Proof of Work، أي أن متصفح الزائر يحل مسألة حسابية تأخذ جزءاً من الثانية، فلا يشعر بها الإنسان، بينما تصبح مكلفة لمن يرسل ملايين الطلبات:

• ALTCHA برخصة MIT: Widget تضعه في النموذج بدل CAPTCHA، ويتحقق منه سيرفرك دون أي طرف خارجي.
• mCaptcha برخصة AGPL-3.0: الفكرة نفسها مع سيرفر تستضيفه، ولكن المشروع ما زال في بدايته وصدر منه إصدار واحد، فلا ينصح به لموقع مهم الآن.
• Anubis برخصة MIT: يقف أمام موقعك ك Reverse Proxy ويطلب من كل متصفح حل مسألة إثبات العمل قبل أن يمرره، وانتشر بين المشاريع مفتوحة المصدر لحماية مستودعات الكود والتوثيق من روبوتات جمع البيانات للذكاء الاصطناعي.

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

شهادات SSL/TLS: القفل في المتصفح

تصدر Cloudflare لكل نطاق في كل الخطط شهادة Universal SSL مجانية، وهي الشهادة التي يراها الزائر، أي بين متصفحه ونقطة التواجد. أما الجزء الثاني من الطريق، بين Cloudflare وسيرفرك، فيحدده وضع التشفير SSL/TLS encryption mode، وسوف نعود إليه في قسم الاستخدام الصحيح لأنه من أكثر الأخطاء شيوعاً.

والبديل هنا كامل ومجاني: Let's Encrypt جهة إصدار شهادات مجانية، وكل Reverse Proxy في أدلتنا يطلب منها الشهادات ويجددها تلقائياً، سواءً Nginx Proxy Manager أو Caddy أو Traefik. ولا تحتاج إلى Cloudflare لتحصل على القفل في المتصفح.

وضع Under Attack: آخر خط عندما يبدأ الهجوم

وضع Under Attack زر في لوحة النطاق ضمن Quick Actions، وعندما تفعله تعرض Cloudflare على كل زائر صفحة تحقق تنفذ JavaScript لبضع ثوان قبل أن تمرره، فيتوقف أغلب ما يرسله الهجوم على طبقة التطبيق. ويمكنك أن تفعله لمسار واحد عبر Configuration Rules بدل الموقع كله. ولاحظ أنه يوقف كذلك كل ما ليس متصفحاً، أي تطبيقات الجوال التي تستخدم ال API وال Webhooks القادمة من خدمات أخرى، ويقول التوثيق إنه يؤثر على أدوات الإحصائيات، لذلك فعله وقت الهجوم فقط، ولا تتركه يعمل دائماً.

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

الوصول والاتصال: Tunnel وZero Trust

Cloudflare Tunnel: نشر خدمة دون فتح منافذ

في الطريقة العادية ينتظر سيرفرك الاتصالات على المنفذ 443، وهذا يحتاج إلى عنوان IP عام ومنفذ مفتوح، وهو ما لا يتوفر في كثير من اتصالات المنزل خلف CGNAT. أما Cloudflare Tunnel فيعكس الاتجاه، فالبرنامج cloudflared على سيرفرك يفتح اتصالاً خارجاً إلى Cloudflare، ثم تعود طلبات الزوار عبر هذا الاتصال نفسه، فلا تحتاج إلى عنوان عام ولا إلى فتح أي منفذ، وهو متاح في كل الخطط. والبرنامج cloudflared نفسه مفتوح المصدر برخصة Apache-2.0، أما الخدمة التي يتصل بها فليست كذلك. وقد شرحنا إعداده خطوة خطوة في تشغيل خادمك من إنترنت المنزل.

والبدائل مفتوحة المصدر تعمل بالفكرة نفسها، ولكن مع شرط مهم: تحتاج إلى سيرفر صغير له عنوان عام، مثل VPS رخيص، يقوم بدور نقطة التواجد، فيتصل به سيرفرك في المنزل من الداخل ويستقبل هو الزوار:

• Pangolin: الأقرب لتجربة Cloudflare Tunnel، فهو Reverse Proxy مع نفق ولوحة تحكم وتسجيل دخول للمستخدمين، ونسخة المجتمع برخصة AGPL-3.0 مع نسخة تجارية Enterprise.
• frp برخصة Apache-2.0: أداة قديمة ومستقرة تنشر منافذ TCP وUDP وHTTP من خلف NAT عبر سيرفرك العام، بملف إعداد ودون واجهة ويب.
• rathole برخصة Apache-2.0: نفق خفيف مكتوب بلغة Rust، ولكن آخر إصدار مستقر منه في 2023، فاعتبره مشروعاً قليل الصيانة.
• WireGuard: إذا كانت الخدمة لك ولفريقك فقط فلا تنشرها للعالم أصلاً، وإنما ادخل إليها عبر شبكة VPN خاصة.

وهذه البدائل تستبدل فكرة النفق كاملة، ولكنها لا تعطيك ما يأتي مع Cloudflare في الطريق نفسه، أي صد DDoS والتخزين المؤقت وWAF، فسيرفرك العام الصغير هو الذي يستقبل الهجوم هذه المرة.

Zero Trust Access: تسجيل دخول قبل الوصول إلى التطبيق

لنفرض أن لديك لوحة إدارة أو أداة داخلية لا تريد أن يراها أحد سوى فريقك، فخدمة Cloudflare Access تضع صفحة تسجيل دخول أمامها على مستوى Cloudflare، فلا يصل الطلب إلى التطبيق إلا بعد أن يثبت المستخدم هويته بحساب Google أو Microsoft أو رمز يصله بالبريد، وهذا ما يسمى نموذج انعدام الثقة Zero Trust، أي أن كل طلب يجب أن يثبت هويته حتى لو جاء من داخل الشبكة. وتقول Cloudflare في صفحة الخدمة إن الخطة المجانية مناسبة للفرق الأقل من 50 مستخدماً.

والبديل على سيرفرك كامل، وهو المصادقة الأمامية Forward Auth، حيث يسأل ال Reverse Proxy مزود الهوية قبل أن يمرر أي طلب، وقد شرحنا ذلك مع authentik، الذي نواته برخصة MIT، في حماية أي تطبيق باستخدام authentik Forward Auth. وهناك Pomerium برخصة Apache-2.0، وهو Reverse Proxy مخصص لهذه الوظيفة يعتمد على الهوية في كل طلب. والفرق أنك تدير مزود الهوية بنفسك، وتنسخه احتياطياً وتحدثه، لأنه إذا توقف توقف الدخول إلى كل ما خلفه.

WARP وGateway: شبكة خاصة لأجهزة الفريق

برنامج WARP على أجهزة الفريق يربطها بشبكة Cloudflare، ومعه خدمة Gateway التي تفلتر DNS وحركة الإنترنت، فيستطيع الموظف من بيته أن يصل إلى الخدمات الداخلية كأنه في المكتب، وهذا جزء من منصة Zero Trust نفسها ويعمل مع Tunnel لربط الشبكات الخاصة.

والبديل مفتوح المصدر هنا جيد جداً:

• WireGuard مع wg-easy: شبكة VPN خاصة بسيطة تديرها من واجهة ويب، وهي كافية لفريق صغير.
• Headscale برخصة BSD-3-Clause: سيرفر تحكم مفتوح المصدر لبرنامج Tailscale، فتحصل على شبكة Mesh تتصل فيها الأجهزة ببعضها مباشرة، وسيرفر التحكم عندك وليس عند Tailscale.
• NetBird: شبكة Mesh مبنية على WireGuard مع لوحة تحكم تستضيفها، وبرنامج الأجهزة فيه برخصة BSD-3-Clause، أما أجزاء السيرفر فأصبحت برخصة AGPL-3.0 منذ أغسطس 2025.

أما فلترة DNS وحظر المواقع الضارة كما في Gateway فهي وظيفة مختلفة يقدمها سيرفر DNS داخلي مثل Technitium الذي ذكرناه في قسم DNS.

Spectrum: حماية ما ليس ويب

ال Proxy العادي يحمل HTTP وHTTPS فقط، أما Spectrum فيحمل بروتوكولات TCP وUDP أخرى، وهو ليس في الخطة المجانية، ففي Pro وBusiness إضافة مدفوعة لتطبيق Minecraft واحد وSSH واحد، وRDP في Business فقط، وأي بروتوكول TCP أو UDP في Enterprise. والبديل على سيرفرك هو توجيه حركة TCP عبر HAProxy أو وحدة stream في Nginx، وهذا يوزع الحركة ولكنه لا يصد DDoS عنها لنفس السبب الذي ذكرناه.

منصة المطورين: Pages وWorkers والتخزين

Pages: استضافة المواقع الثابتة

Cloudflare Pages تستضيف الموقع الثابت Static Site، مثل موقع مبني ب Hugo أو Astro أو تطبيق React، فتربطها بمستودع Git فتبني الموقع عند كل Push وتنشره على شبكتها. والخطة المجانية فيها 500 عملية بناء Build في الشهر، وعملية بناء واحدة في الوقت نفسه، و100 مشروع، و20,000 ملف لكل موقع.

والبديل على سيرفرك سهل، فالموقع الثابت مجموعة ملفات يقدمها أي سيرفر ويب، مثل Caddy بسطرين في ملف الإعداد، وإذا أردت البناء والنشر التلقائي من Git كما في Pages فهذا ما تقدمه منصات النشر مثل Coolify برخصة Apache-2.0 وDokploy وأغلبه برخصة Apache-2.0 مع مجلد لميزات تجارية، وقد قارنا بينهما في مقارنة Portainer وCoolify وDokploy. والذي يبقى عند Pages هو التوزيع على نقاط التواجد، فموقعك على سيرفرك في مكان واحد.

Workers: كود يعمل على حافة الشبكة

Cloudflare Workers تشغل كود JavaScript أو TypeScript أو WebAssembly في نقاط التواجد نفسها، فتكتب دالة ترد على الطلب أو تعدله قبل أن يصل إلى سيرفرك، وتدفع حسب الاستخدام بدل أن تدير سيرفراً، وهذا ما يسمى الحوسبة دون سيرفر Serverless. والخطة المجانية فيها 100,000 طلب في اليوم و10 ملي ثانية من وقت المعالج CPU لكل طلب.

والطريف هنا أن البيئة التي تشغل Workers نفسها مفتوحة المصدر، فقد نشرت Cloudflare workerd برخصة Apache-2.0، وتستطيع أن تشغل به كود Workers على سيرفرك. ولكن التوثيق يحذر صراحة من أن workerd ليس بيئة معزولة محصنة Hardened Sandbox، فلا تشغل به كوداً لا تثق به إلا داخل VM. وهناك OpenFaaS لتشغيل الدوال على Kubernetes، ولكن انتبه إلى أن نسخته المجانية Community Edition أصبحت باتفاقية استخدام تقصر الاستخدام التجاري على تثبيت واحد لمدة 60 يوماً، فهي ليست مفتوحة المصدر بالمعنى الكامل. وفي الحالتين تحصل على الكود نفسه على سيرفر واحد، ولا تحصل على تشغيله في مئات المدن قرب كل زائر، وهي الفكرة التي بنيت عليها Workers.

R2 وKV وD1: التخزين وقواعد البيانات

• R2: تخزين ملفات متوافق مع واجهة Amazon S3، والميزة التي جعلته مشهوراً أن تنزيل الملفات منه مجاني دون رسوم نقل Egress، والخطة المجانية فيها 10 GB من التخزين في الشهر ومليون عملية من الفئة A وعشرة ملايين من الفئة B.
• KV: تخزين مفتاح وقيمة Key-Value للقراءة السريعة من Workers، والخطة المجانية فيها 100,000 قراءة و1,000 كتابة في اليوم و1 GB.
• D1: قاعدة بيانات SQL مبنية على SQLite، والخطة المجانية فيها 5 ملايين صف للقراءة و100,000 صف للكتابة في اليوم و5 GB.

والبدائل مفتوحة المصدر كما يلي:

• بدل R2: Garage برخصة AGPL-3.0، وهو تخزين S3 خفيف مصمم لعدة سيرفرات صغيرة في أماكن مختلفة، وSeaweedFS برخصة Apache-2.0 للأحجام الكبيرة. أما MinIO الشهير فقد أصبح مستودعه يقول إنه لم يعد يصان، فلا تبدأ به مشروعاً جديداً.
• بدل KV: Valkey برخصة BSD-3-Clause، وهو النسخة المفتوحة التي انفصلت عن Redis بعد تغيير رخصته، وRedis نفسه من الإصدار 8 يتيح رخصة AGPL-3.0 من بين رخصه.
• بدل D1: SQLite نفسها وهي ملكية عامة Public Domain، أو libSQL برخصة MIT إذا أردت أن تصل إليها عبر الشبكة.

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

Images وStream: الصور والفيديو

Cloudflare Images تغير حجم الصور وصيغتها عند الطلب، والخطة المجانية فيها 5,000 تحويل فريد في الشهر، أما Stream لاستضافة الفيديو وبثه فليس فيها خطة مجانية، وتحاسب على الدقائق المخزنة والمشاهدة. والبديل للصور هو imgproxy برخصة Apache-2.0 الذي يحول الصور عند الطلب على سيرفرك، وللفيديو PeerTube برخصة AGPL-3.0، ولكن بث الفيديو لعدد كبير من المشاهدين يحتاج إلى Bandwidth كبير، وهذه هي النقطة التي تجعل الخدمات المدفوعة منطقية.

خدمات أخرى: البريد والإحصائيات وتسجيل النطاقات

Email Routing: عنوان بريد يحول إلى بريدك الحالي

Email Routing تجعلك تنشئ عناوين مثل [email protected] وتحول الرسائل التي تصل إليها إلى بريدك في Gmail أو غيره، وهي مجانية دون حد للبريد الوارد. ولاحظ أنها تستقبل وتحول فقط، فلا يوجد فيها صندوق بريد، ولا تستطيع أن ترد من العنوان نفسه إلا بإعداد إضافي، أما خدمة الإرسال الجديدة Email Sending فما زالت تجريبية Beta وتحتاج إلى خطة Workers المدفوعة.

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

Web Analytics: إحصائيات الزوار دون ملفات تعريف

Cloudflare Web Analytics متاحة في كل الخطط، وتعمل حتى لو لم يمر موقعك عبر Cloudflare بوضع سكربت صغير في الصفحة، وتقول Cloudflare في صفحة الخدمة إنها لا تستخدم ملفات تعريف الارتباط Cookies ولا localStorage ولا تتعرف على الزائر ببصمة جهازه.

والبديل مفتوح المصدر هنا كامل، ف Umami برخصة MIT وPlausible Community Edition برخصة AGPL-3.0 يقدمان الإحصائيات نفسها دون ملفات تعريف، وتبقى البيانات على سيرفرك. وموقع عرب رووت نفسه يستخدم Umami على سيرفره.

Registrar: شراء النطاق بسعر التكلفة

Cloudflare Registrar يبيع النطاقات ويجددها بسعر الجهة المسؤولة عن الامتداد Registry دون أي زيادة، وهذا يجعله من أرخص المسجلين، ولكن له شرط مهم تذكره الأسئلة الشائعة: كل نطاق مسجل فيه يجب أن يستخدم سيرفرات DNS الخاصة ب Cloudflare، فإذا أردت مزود DNS آخر فعليك أن تنقل النطاق إلى مسجل آخر.

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

Zaraz باختصار

Zaraz يحمل سكربتات الطرف الثالث مثل أدوات الإعلانات والإحصائيات من شبكة Cloudflare بدل متصفح الزائر، فتصبح الصفحة أخف، وفيه مليون حدث مجاني في الشهر. وهو مفيد لمن يستخدم أدوات تسويق كثيرة، أما إذا كنت تستخدم Umami أو Plausible فلن تحتاجه أصلاً.

كيف تستخدم Cloudflare مع سيرفرك بشكل صحيح

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

ما يمر عبر ال Proxy وما يبقى DNS only

ال Proxy يحمل حركة الويب فقط، لذلك اجعل سجلات المواقع Proxied، واجعل كل ما ليس ويب DNS only، وأولها سيرفر البريد، فلو جعلت mail.example.com Proxied لأجاب الاسم بعنوان Cloudflare ولن تجد سيرفرات البريد من يستقبل رسائلها على المنفذ 25، والأمر نفسه مع SSH وWireGuard. وقد شرحنا هذا مع السبب في قسم السحابة البرتقالية في شرح DNS، وسجلات البريد كاملة في دليل استضافة البريد. ولاحظ أن سجل البريد يكشف عنوان سيرفرك إذا كان الموقع والبريد على السيرفر نفسه، فلا تعتمد على ال Proxy لإخفاء العنوان في هذه الحالة.

عنوان الزائر الحقيقي خلف Cloudflare

عندما يمر الموقع عبر Cloudflare يرى سيرفرك أن كل الطلبات جاءت من عناوين Cloudflare، فتمتلئ السجلات بعناوين لا تفيدك، ويحظر fail2ban أو CrowdSec عنوان Cloudflare نفسه فيتوقف الموقع عن الجميع. والحل أن يستعيد ال Reverse Proxy عنوان الزائر من الترويسة CF-Connecting-IP، بشرط أن يصدقها من نطاقات Cloudflare فقط، وإلا كتبها أي أحد يصل إلى سيرفرك مباشرة. وقد شرحنا ذلك لكل Reverse Proxy في تطبيقك خلف Reverse Proxy، مع توثيق Cloudflare لاستعادة عنوان الزائر.

أغلق سيرفرك على Cloudflare أو استخدم Tunnel

هذه هي النقطة التي ينساها الكثيرون: كل حماية Cloudflare تعمل فقط على الطلبات التي تمر عبرها، فإذا عرف المهاجم العنوان الحقيقي لسيرفرك، من سجل البريد أو من سجل DNS قديم أو من شهادة TLS منشورة، فإنه يتصل به مباشرة ويتجاوز WAF وصد DDoS وكل شيء. لذلك لا تترك المنفذين 80 و443 مفتوحين للجميع، وإنما اسمح بهما لعناوين Cloudflare فقط. وإذا كان ال Reverse Proxy مثبتاً على السيرفر نفسه وليس داخل Docker فالأوامر التالية تفعل ذلك في ufw:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443 comment "Cloudflare"
done
sudo ufw enable
sudo ufw status | grep -c Cloudflare

والمخرج الأخير سوف يكون عدد القواعد التي أضيفت:

22

في الأوامر أعلاه لاحظ التالي:

• نسمح بالمنفذ 22 قبل تفعيل ufw، وإلا أغلقت اتصال SSH على نفسك، والأمر sudo ufw enable يسألك للتأكيد قبل التفعيل.
• العدد 22 هو 15 نطاقاً من IPv4 و7 نطاقات من IPv6، وكل قاعدة تسمح بالمنفذين 80 و443 معاً من نطاق واحد.
• التعليق Cloudflare على كل قاعدة يسهل عليك أن تجدها وتحذفها عندما تحدث القائمة.

وهناك طبقة أخرى تثبت أن الطلب جاء من Cloudflare وليس من أي أحد يستخدم Cloudflare، وهي Authenticated Origin Pulls المتاحة في كل الخطط، حيث تقدم Cloudflare شهادة عميل Client Certificate عند كل اتصال بسيرفرك، ويرفض ال Reverse Proxy أي اتصال لا يحملها. أما أبسط طريقة على الإطلاق فهي Tunnel، لأن السيرفر لا ينتظر أي اتصال من الخارج، فلا يوجد منفذ يمكن أن يصل إليه أحد.

وضع Full (strict) مع شهادة على سيرفرك

وضع التشفير يحدد كيف تتصل Cloudflare بسيرفرك، وهذه هي الأوضاع وما يعنيه كل واحد منها:

• Flexible: الزائر يتصل ب Cloudflare عبر HTTPS، ثم تتصل Cloudflare بسيرفرك عبر HTTP دون تشفير، فيرى القفل في المتصفح بينما تمر البيانات مكشوفة في نصف الطريق. وهذا الوضع غير مناسب إطلاقاً لأي موقع فيه تسجيل دخول، وهو كذلك سبب شائع لخطأ ERR_TOO_MANY_REDIRECTS عندما يحول سيرفرك HTTP إلى HTTPS.
• Full: الاتصال بسيرفرك مشفر، ولكن Cloudflare تقبل أي شهادة حتى لو كانت منتهية أو موقعة ذاتياً، فلا تتأكد أنها تتحدث مع سيرفرك فعلاً.
• Full (strict): الاتصال مشفر، والشهادة على سيرفرك يجب أن تكون صالحة وصادرة من جهة موثوقة أو من Cloudflare Origin CA ومطابقة لاسم النطاق، كما يشرح توثيق Full (strict). وهذا هو الوضع الذي يجب أن تستخدمه.

ولكي يعمل Full (strict) تحتاج إلى شهادة على سيرفرك، ولها طريقتان: شهادة Let's Encrypt عادية يصدرها ال Reverse Proxy، وهنا يفضل التحقق عبر DNS (DNS Challenge) لأن التحقق عبر HTTP (HTTP Challenge) يمر عبر Cloudflare، أو شهادة Cloudflare Origin CA المجانية التي تصل مدتها إلى 15 سنة. ولاحظ أن شهادة Origin CA لا يثق بها المتصفح، فهي تعمل فقط والسجل Proxied، وإذا جعلته DNS only يوماً ما فسوف يرى الزوار خطأ في الشهادة.

لا تحفظ في الذاكرة المؤقتة ما يخص مستخدماً واحداً

عندما تكتب قاعدة Cache Rule تحفظ كل شيء Cache Everything لتسرع الموقع، فإن Cloudflare تحفظ الصفحة كما وصلتها وتقدمها لكل من يطلب العنوان نفسه. فإذا كانت الصفحة لوحة حساب مستخدم مسجل دخوله فسوف ترى الزائرة التالية اسمه وبياناته، وإذا كانت ترد ب Set-Cookie فقد تصل جلسة شخص إلى شخص آخر. لذلك لا تقم بحفظ أي صفحة بعد تسجيل الدخول، واستثن صراحة مسارات مثل /admin و/account و/api وكل طلب يحمل Cookie الجلسة، واجعل تطبيقك يرسل Cache-Control: private, no-store للصفحات الخاصة، وابدأ بحفظ الملفات الثابتة فقط وهو الإعداد الافتراضي أصلاً. وبعد أي قاعدة جديدة افتح الصفحة الخاصة بحسابين مختلفين وتأكد من cf-cache-status في ترويساتها، فيجب أن يكون BYPASS أو DYNAMIC وليس HIT.

الخصوصية والسيادة على البيانات: ما الذي تراه Cloudflare؟

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

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

وهل يعني هذا أن تبتعد عن Cloudflare؟ لا، والتفصيل كما يلي: لموقع عام ومدونة ومتجر صغير تكون الحماية التي تحصل عليها مجاناً أكبر بكثير من الخطر، وللأنظمة الداخلية وبيانات العملاء الحساسة اجعل الوصول عبر VPN أو Forward Auth على سيرفرك، أو اجعل السجل DNS only وتحمل أنت مسؤولية الحماية بالأدوات التي ذكرناها. وبين الاثنين يوجد حل وسط، وهو أن تستخدم Cloudflare في DNS فقط، فتستفيد من شبكتها الموزعة دون أن تمر حركة مستخدميك عبرها.

جدول الخدمات وبدائلها

الجدول التالي يجمع كل ما سبق، والعمود الأخير هو حكمنا الصريح: هل يستبدل البديل الخدمة فعلاً على سيرفرك؟

أدلة تكمل هذا المقال

إذا قررت أن تبني البديل على سيرفرك، أو أن تجمع بين Cloudflare وأدواتك، فهذه هي الأدلة التي تحتاجها بالترتيب: ال Reverse Proxy أولاً، ثم الحماية، ثم الوصول.

دليلشرح DNS وسجلاته للمبتدئين: A وCNAME وMX وTXT وCAA وPTR بمثال حقيقيكيف يتحول اسم نطاقك إلى عنوان سيرفرك خطوة خطوة، وما وظيفة كل سجل من A وCNAME وMX وTXT وCAA وPTR على سيرفر تستضيفه بنفسك، مع مخرجات حقيقية لأمر dig والأخطاء التي تضيع فيها الساعات عادة.دليلNginx Proxy Manager: نطاقات وشهادات TLS لكل خدماتكبدلاً من فتح منفذ مستقل لكل تطبيق، يتيح لك Nginx Proxy Manager أن تربط كل خدمة بنطاقها وتمنحها شهادة HTTPS مجانية من واجهة بسيطة، دون أن تكتب إعدادات Nginx بنفسك.مقارنةNginx Proxy Manager أم Traefik أم HAProxy أم Caddy: أي Reverse Proxy يناسبك؟أي Reverse Proxy تختار لخدماتك؟ نقارن Nginx Proxy Manager وTraefik وHAProxy وCaddy في سهولة الإعداد وشهادات HTTPS وتوزيع الحمل، لتعرف أيها يناسب خادمك وفريقك.دليلتطبيقك خلف Reverse Proxy: عنوان الزائر الحقيقي وHTTPS والروابط الصحيحةإذا كان تطبيقك يرى عنوان الـ Proxy بدلاً من عنوان الزائر، أو يولد روابط http مع أن موقعك يعمل بـ HTTPS، فستعرف هنا السبب والإعداد الصحيح لإطار عملك دون أن تفتح باباً لانتحال العناوين.دليلحماية تطبيقات الويب على مستوى HTTP: طبقات أمان أمام كل تطبيق في الـ Reverse Proxyكلمة المرور وحدها لا تحمي تطبيقاً مكشوفاً على الإنترنت، لذلك نبني في هذا الدليل أمام كل تطبيق طبقات حماية في الـ Reverse Proxy نفسه، بإعدادات مختبرة على Nginx Proxy Manager وTraefik وCaddy.

دليلتشغيل خادمك من إنترنت المنزل: CGNAT وDDNS وCloudflare Tunnelهل يمكنك تشغيل خدماتك من اتصال الإنترنت في منزلك؟ يشرح هذا الدليل كيف تعرف ما يسمح به اتصالك، ومتى يكفي توجيه المنافذ، ولماذا يكون Cloudflare Tunnel غالباً الحل الأسهل والأكثر أماناً.دليلشبكة خاصة مع WireGuard وواجهة wg-easyلا تحتاج لوحات الإدارة إلى أن تكون مكشوفة للإنترنت. ننشئ شبكة VPN خاصة باستخدام WireGuard وواجهة wg-easy، ونضيف إليها الأجهزة برمز QR، فلا يصل إلى أدواتك إلا أجهزة فريقك.دليلكيف تحمي أي تطبيق ويب بصفحة دخول authentik عبر Forward Authلديك أداة داخلية لا تحتوي على صفحة دخول؟ يمكنك أن تضع أمامها صفحة دخول authentik مع المصادقة الثنائية، دون أي تعديل على التطبيق نفسه.دليلتثبيت Coolify لنشر التطبيقات من Git على خادمكانشر تطبيقاتك من Git على خادمك بضغطة زر، كما تفعل في Heroku أو Vercel. نثبت Coolify بأمان، وننشر أول تطبيق بنطاق وشهادة HTTPS، ونجهز النسخ الاحتياطي لقواعد البيانات.دليلكيف تستضيف بريد مؤسستك بنفسك: دليل عملي من القرار إلى التشغيلمتى تستضيف بريد شركتك أو جامعتك بنفسك ومتى يكون البريد المستضاف أنسب، وما الذي تجهزه قبل البدء، وكيف تنقل المستخدمين على مراحل دون أن تضيع رسالة، مع مسار قراءة يجمع كل أدلة البريد على الموقع.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• Cloudflare تقدم مجاناً DNS والتخزين المؤقت وصد DDoS دون حد للحجم وWAF بقواعد أساسية وشهادات TLS وTunnel وZero Trust لفريق صغير، وهذه حزمة يصعب أن تبنيها بنفسك بالقيمة نفسها.
• ما قيمته في الشبكة العالمية نفسها، أي CDN وصد الهجمات الحجمية وArgo وتشغيل الكود قرب الزائر، لا يمكن أن تستضيفه على سيرفر واحد مهما كانت الأداة.
• ما قيمته في البرنامج، أي ال Reverse Proxy وشهادات TLS وWAF وForward Auth وVPN والإحصائيات وتخزين S3، له بدائل مفتوحة المصدر تستبدله فعلاً، وقد شرحنا أغلبها في أدلة الموقع.
• إذا استخدمت Cloudflare فاجعل البريد وكل ما ليس ويب DNS only، واستعد عنوان الزائر الحقيقي، وأغلق سيرفرك على عناوين Cloudflare أو استخدم Tunnel، واستخدم Full (strict)، ولا تحفظ صفحات المستخدمين المسجلين.
• تذكر أن Cloudflare تفك تشفير حركة موقعك لتقدم خدماتها، فقرر بوعي ما الذي تضعه خلفها وما الذي تبقيه على سيرفرك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، ومراجعة الخطط والحدود في توثيق Cloudflare، وتنفيذ أوامر dig وcurl على نطاقات عامة تمر عبر Cloudflare، واختبار قواعد ufw على Ubuntu 24.04.