نطاقاتك تعمل بشهادات صالحة، لكن كل من يستعلم عن أي واحد منها يحصل على عنوان سيرفرك الحقيقي. ومن يعرف العنوان يستطيع مهاجمته مباشرةً متجاوزاً كل حماية.
في هذا الجزء نضع Cloudflare أمام كل شيء: يخفي عنوانك، ويصدّ الهجمات، ويخزّن ملفاتك الثابتة في عشرات المدن — مجاناً. ثم نحلّ المشكلة التي تظهر فور تفعيله: شهادات Let's Encrypt تتوقّف عن التجديد.
كل ما في هذه السلسلة مُنفَّذ فعلاً. بنينا المختبر على سيرفر Proxmox VE 9.2 بعنوان عام واحد، وأنشأنا عليه شبكة خاصة 10.10.10.0/24 وأربع حاويات، ونشرنا ثلاثة نطاقات فرعية حقيقية بشهادات Let's Encrypt. كل لقطة وكل مخرج أمر في هذه المقالات من ذلك المختبر — والعناوين في الصور حقيقية وقت التنفيذ.
السحابة الرمادية والسحابة البرتقالية
في لوحة Cloudflare، بجانب كل سجل زرّ سحابة له وضعان — والفرق بينهما جوهري:
| رمادية (DNS only) | برتقالية (Proxied) | |
|---|---|---|
| ما يراه الزائر | عنوان سيرفرك | عنوان Cloudflare |
| مسار الطلب | الزائر ← سيرفرك | الزائر ← Cloudflare ← سيرفرك |
| الحماية والكاش | لا شيء | حماية وكاش وضغط |
| عنوانك | مكشوف | مخفيّ |
| تحدّي Let's Encrypt عبر المنفذ 80 | يعمل | قد يفشل |
الدليل من المختبر
فعّلنا السحابة البرتقالية على نطاق واحد وتركنا الآخر رمادياً، ثم قارنّا:
لاحظ cf-cache-status: HIT: الطلب لم يصل إلى سيرفرك أصلاً، بل خُدم من ذاكرة Cloudflare القريبة من الزائر. هذا يخفّف الحمل ويسرّع الموقع في آن.
الإعداد خطوة بخطوة
1) أضف نطاقك
من لوحة Cloudflare: Add a Site، ثم غيّر خوادم الأسماء عند مسجّل نطاقك إلى الخادمين اللذين يعطيك إياهما. يستغرق الانتشار من دقائق إلى ساعات.
2) أنشئ السجلات
Type Name Content Proxy
A wp 82.39.115.50 DNS only ← ابدأ رمادياً
A n8n 82.39.115.50 DNS only
A api 82.39.115.50 DNS only
ابدأ دائماً بالسحابة الرمادية. اجعل كل شيء يعمل أولاً: الوسيط، والشهادات، والمواقع. ثم فعّل السحابة البرتقالية. من يبدأ بها يقضي ساعات في تشخيص أخطاء لا يعرف مصدرها — هل المشكلة في الوسيط أم في Cloudflare؟
3) اضبط وضع التشفير
من SSL/TLS ← Overview، والخيار الصحيح واحد فقط:
| الوضع | الحكم |
|---|---|
| Off | ❌ لا تشفير إطلاقاً |
| Flexible | ❌ خطر — مشفّر إلى Cloudflare فقط، والنصف الثاني مكشوف. ويسبّب حلقات تحويل لا تنتهي |
| Full | ⚠️ مشفّر كاملاً لكن بلا تحقّق من الشهادة |
| Full (strict) | ✅ هذا هو الصحيح — مشفّر كاملاً مع التحقّق. ويعمل لأن عندك شهادة Let's Encrypt صالحة |
المشكلة: الشهادات تتوقّف عن التجديد
الشهادة من Let's Encrypt تُطلب بتحدّي HTTP-01: تضع ملفاً على المنفذ 80 ويقرؤه Let's Encrypt ليتأكّد أنك تملك النطاق. ومع السحابة البرتقالية يمرّ الطلب عبر Cloudflare، وقد يُخدَم من الكاش أو يُعاد توجيهه، فيفشل التحدّي.
الحل الأول: تحدّي DNS
بدل وضع ملف على الخادم، تضع سجلاً في نطاقك. NPM يدعم هذا مع Cloudflare مباشرةً:
- أنشئ رمز API في Cloudflare بصلاحية Zone : DNS : Edit على نطاقك فقط.
- في NPM عند طلب الشهادة فعّل Use a DNS Challenge واختر Cloudflare.
- الصق الرمز واحفظ.
ميزتان إضافيتان: يعمل والسحابة برتقالية، ويتيح شهادة شاملة *.example.com تغطّي كل نطاقاتك الفرعية بشهادة واحدة.
حدّد صلاحية الرمز بأضيق نطاق. رمز بصلاحية تعديل DNS لنطاق واحد كافٍ تماماً. لا تُنشئ رمزاً بصلاحيات كاملة على الحساب كله — إن تسرّب فقدت نطاقاتك جميعاً.
الحل الثاني: قاعدة تتجاوز الكاش
إن أردت البقاء على تحدّي HTTP، أنشئ قاعدة تستثني مسار التحدّي:
Rule: *example.com/.well-known/acme-challenge/*
Settings: Cache Level = Bypass, SSL = Off
الحل الثالث: أطفئ السحابة مؤقّتاً
عملي ومباشر: اجعل السجل رمادياً، اطلب الشهادة، ثم أعده برتقالياً. عيبه أنك ستكرّره كل تسعين يوماً — لذلك الحل الأول أفضل للمدى الطويل.
ماذا تفعل الوضعية البرتقالية أيضاً؟
| الميزة | الفائدة |
|---|---|
| إخفاء العنوان | من لا يعرف عنوانك لا يهاجمه مباشرة |
| صدّ هجمات الحرمان | يمتصّ الهجوم قبل أن يصل إلى سيرفرك |
| كاش الملفات الثابتة | الصور وملفات التنسيق من أقرب مدينة للزائر |
| الضغط التلقائي | حجم أقل وسرعة أعلى بلا إعداد |
| شهادة عند الحافة | حتى لو تعطّلت شهادتك يبقى الاتصال مشفّراً للزائر |
| سجلّات وتحليلات | ترى الطلبات المحجوبة ومن أين يأتي زوّارك |
احمِ لوحات الإدارة بـCloudflare Access
إن اضطررت لنشر لوحة إدارة، لا تتركها بكلمة مرور فقط. Cloudflare Access يضع طبقة تحقّق قبل وصول الطلب إلى سيرفرك:
Access ← Applications ← Add an application
Domain: panel.example.com
Policy: Allow — Emails ending in @company.com
أو: Allow — IP in 203.0.113.0/24
النتيجة: من لا يجتاز الشرط لا يصل إلى صفحة الدخول أصلاً. وهو مجاني حتى خمسين مستخدماً.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحل |
|---|---|---|
| حلقة تحويل لا تنتهي | وضع Flexible مع تحويل إجباري في الوسيط | انقل إلى Full (strict) |
| خطأ 521 Web Server Is Down | سيرفرك يرفض اتصالات Cloudflare | تأكّد أن 80 و443 ممرَّران، ولا تحجب نطاقات Cloudflare |
| خطأ 526 Invalid SSL Certificate | شهادة الأصل منتهية أو ذاتية مع strict | جدّد الشهادة أو استعمل شهادة أصل من Cloudflare |
| الشهادة تفشل بعد التفعيل | تحدّي HTTP لا يمرّ | انتقل إلى تحدّي DNS |
| كل الزوّار بعنوان واحد | تقرأ عنوان Cloudflare لا الزائر | اقرأ ترويسة CF-Connecting-IP |
| تغييرات لا تظهر | الكاش | Caching ← Purge Everything |
أسئلة شائعة
هل Cloudflare مجاني فعلاً؟
نعم، والخطة المجانية تغطّي كل ما ذُكر: DNS غير محدود، وشهادات، وحماية أساسية، وكاش. المدفوع للميزات المتقدّمة.
هل يبطّئ موقعي؟
عادةً يُسرّعه: الملفات الثابتة من أقرب مدينة. قد تلاحظ تأخّراً بسيطاً في الطلبات الديناميكية لأنها تمرّ بوسيط إضافي، وهو مقابل زهيد للحماية.
هل يرى Cloudflare بيانات مستخدميّ؟
مع السحابة البرتقالية نعم — هو يفكّ التشفير عند الحافة ثم يعيد تشفيره إليك. هذه طبيعة الخدمة. للبيانات شديدة الحساسية استعمل السحابة الرمادية أو نفقاً.
هل أستطيع خلط الوضعين؟
نعم، لكل سجل وضعه. شائع: المواقع العامة برتقالية، وسجل SSH أو VPN رمادي (لأن Cloudflare لا يمرّر إلا الويب في الخطة المجانية).
وماذا عن Cloudflare Tunnel؟
بديل مختلف كلياً: يفتح نفقاً خارجاً من سيرفرك فلا تحتاج فتح أي منفذ ولا عنواناً عاماً. مقارنته بالوسيط العكسي في الجزء التاسع.
الخطوة التالية
في الجزء التاسع نضع كل الحلول في جدول واحد — NAT وتمرير المنافذ وNPM وTraefik وHAProxy وCaddy وCloudflare Tunnel — ونحدّد متى تختار كلاً منها.
هذه المقالة جزء من سلسلة «من IP واحد إلى عشرات الخدمات» — عشرة أجزاء بُنيت كلها على سيرفر Proxmox حقيقي: ١. لماذا يكفي عنوان واحد · ٢. الشبكة الخاصة · ٣. إعداد NAT · ٤. تمرير المنافذ · ٥. الـReverse Proxy · ٦. Nginx Proxy Manager · ٧. النطاقات الفرعية · ٨. Cloudflare والشهادات · ٩. مقارنة الحلول · ١٠. سحابة صغيرة كاملة