تفعيل Cloudflare على موقعك سهل — تنقله وتضيء «السحابة البرتقالية». لكن الفرق بين إعداد يسرّع موقعك ويحمي سيرفرك وإعداد يبطئه أو يكشفه يكمن في الضبط الصحيح بعد التفعيل. كثير من أصحاب مواقع VPS يفعّلون Cloudflare ثم يصطدمون بحلقات إعادة توجيه، أو يتركون عنوان سيرفرهم مكشوفًا فتصبح الحماية بلا قيمة. في هذا الدليل من مرام هوست نركّز على إعداد Cloudflare مع VPS بالطريقة الصحيحة: وضع SSL المناسب، وحماية عنوان الأصل، وضبط الكاش والجدار الناري — لا على خطوات التسجيل الأساسية (تجدها في دليلنا المنفصل).
⚡ الإجابة المختصرة
قبل أن نبدأ: الإعداد الأساسي مقابل الضبط المتقدّم
هذا الدليل لا يشرح كيفية إنشاء حساب Cloudflare وتغيير NameServers — تلك خطوات الإعداد الأساسي تجدها في إعداد Cloudflare وربطه بموقعك خطوة بخطوة. هنا نفترض أنك ربطت نطاقك بالفعل، ونركّز على إعداد Cloudflare مع VPS بالضبط الصحيح الذي يصنع الفرق في الأداء والحماية.
كيف تقف Cloudflare أمام سيرفرك؟
في إعداد Cloudflare مع VPS، حين تفعّل البروكسي لا يصل الزائر إلى سيرفرك مباشرة، بل يمرّ الطلب هكذا: الزائر ← Cloudflare (عند الحافة) ← سيرفر الأصل (VPS). هذا يمنحك: شبكة توصيل محتوى (CDN) تسرّع التحميل، وتخفيفًا لهجمات DDoS، وجدار حماية تطبيقات (WAF)، وإخفاء عنوان سيرفرك الحقيقي. لفهم موقع Cloudflare ضمن طبقات الحماية راجِع طبقات حماية موقعك: CDN وFirewall وWAF، وللفرق بينها وبين الوكيل العكسي الفرق بين CDN وReverse Proxy.
أهم قرار في إعداد Cloudflare مع VPS: وضع SSL الصحيح
هذا الإعداد وحده يسبّب أكثر المشاكل شيوعًا في إعداد Cloudflare مع VPS. توثّق Cloudflare أوضاع SSL، وإليك الفرق عمليًا:
| الوضع | ماذا يفعل | الحكم |
|---|---|---|
| Flexible | تشفير بين الزائر وCloudflare فقط، ثم اتصال غير مشفّر إلى سيرفرك | ❌ يسبّب حلقات إعادة توجيه (too many redirects) وغير آمن — لا تستخدمه |
| Full | تشفير حتى سيرفرك لكن دون التحقّق من شهادته | 🟡 حلّ انتقالي فقط |
| Full (strict) | تشفير كامل + التحقّق من شهادة أصل موثوقة | ✅ الصحيح — اعتمده دائمًا |
لتفعيل Full (strict) تحتاج شهادة صالحة على سيرفرك: إمّا Let’s Encrypt مجانية عبر Nginx، أو «شهادة الأصل» (Origin Certificate) التي تصدرها Cloudflare نفسها لسيرفرك (صالحة 15 عامًا وتعمل مع البروكسي فقط).
حماية عنوان الأصل: أهم خطوة في إعداد Cloudflare مع VPS
إذا بقي عنوان سيرفرك مكشوفًا، يستطيع المهاجم تجاوز Cloudflare والوصول إليه مباشرة — فتصبح كل الحماية بلا قيمة. أغلق هذه الثغرة بخطوتين:
- لا تكشف IP الأصل: تأكّد ألا يشير أي سجلّ DNS (مثل سجلّ بريد قديم أو نطاق فرعي) إلى IP سيرفرك مباشرة بالسحابة الرمادية.
- اقبل Cloudflare فقط: اضبط جدار سيرفرك الناري ليسمح بحركة المنفذين 80/443 من عناوين Cloudflare المعلنة فقط، ويرفض ما عداها.
مثال مبسّط بـ UFW للسماح بعنوان واحد من قائمة Cloudflare (كرّره لكل النطاقات، أو استخدم سكربتًا يجلبها تلقائيًا):
# اسمح بحركة HTTPS من نطاق Cloudflare (مثال — استبدله بالقائمة الكاملة)
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcp
# ... كرّر لكل نطاقات Cloudflare، ثم:
sudo ufw deny 443/tcp # ارفض 443 من أي مصدر آخربعدها، لاستعادة عناوين الزوّار الحقيقية في سجلّاتك (بدل عناوين Cloudflare)، فعّل وحدة mod_remoteip أو ما يكافئها في Nginx لقراءة ترويسة CF-Connecting-IP. راجِع أيضًا تأمين VPS في 10 خطوات.
البروكسي البرتقالي مقابل الرمادي
جوهر إعداد Cloudflare مع VPS في لوحة DNS: كل سجلّ له حالتان: برتقالي (Proxied) = المرور عبر Cloudflare مع كل الحماية والكاش؛ ورمادي (DNS only) = Cloudflare يحلّ الاسم فقط ثم يصل الزائر لسيرفرك مباشرة — فيُكشف عنوانك وتُلغى الحماية. القاعدة: اجعل سجلّات موقعك (A/AAAA وwww) برتقالية، وأبقِ رماديًا فقط ما يجب أن يتصل مباشرة (مثل سجلّ بريد MX الذي لا يُبرّأ أصلًا).
ضبط الكاش في إعداد Cloudflare مع VPS: سرّع دون أن تكسر موقعك
Cloudflare يخزّن الملفات الثابتة افتراضيًا (صور، CSS، JS). المشكلة تبدأ حين يُخزَّن المحتوى الديناميكي فيرى المستخدم صفحة قديمة أو بيانات غيره. القواعد الآمنة:
- خزّن الثابت: الصور والخطوط وملفات CSS/JS — فعّل عمرًا طويلًا للكاش عليها.
- استثنِ الديناميكي: لوحة الإدارة (
/wp-admin)، السلة، صفحة الحساب، والـ API — بقاعدة «Bypass Cache». - احترم الكوكيز: لا تخزّن صفحات المستخدم المسجّل دخوله.
- فعّل Brotli وMinify لتقليل حجم الملفات دون أثر على المحتوى.
تحذير: تخزين لوحة الإدارة
أخطاء شائعة في إعداد Cloudflare مع VPS
- وضع SSL = Flexible: سبب حلقات «too many redirects» الأشهر — حوّله إلى Full (strict).
- ترك IP الأصل مكشوفًا: سجلّ فرعي رمادي أو بريد قديم يفضح سيرفرك ويتجاوز الحماية.
- جدار ناري يقبل الجميع: دون حصر 80/443 بعناوين Cloudflare، يمكن مهاجمة سيرفرك مباشرة.
- تخزين المحتوى الديناميكي: يكسر لوحة الإدارة والسلة وصفحات الحساب.
- السجلّ رمادي بدل برتقالي: يلغي CDN والحماية دون أن تشعر.
الأسئلة الشائعة
ما وضع SSL الصحيح عند إعداد Cloudflare مع VPS؟
Full (strict) دائمًا: يشفّر الاتصال كاملًا من الزائر حتى سيرفرك ويتحقّق من شهادة الأصل. تجنّب Flexible لأنه يسبّب حلقات إعادة توجيه ويترك الاتصال بين Cloudflare وسيرفرك غير مشفّر. يتطلّب Full (strict) شهادة صالحة على سيرفرك مثل Let’s Encrypt أو شهادة الأصل من Cloudflare.
كيف أحمي عنوان سيرفرك من الكشف خلف Cloudflare؟
خطوتان: لا تترك أي سجلّ DNS رماديًا يشير إلى IP سيرفرك، واضبط الجدار الناري ليقبل اتصالات المنفذين 80/443 من عناوين Cloudflare المعلنة فقط ويرفض ما عداها. بذلك لا يمكن تجاوز Cloudflare والوصول إلى سيرفرك مباشرة.
ما الفرق بين السجلّ البرتقالي والرمادي في Cloudflare؟
البرتقالي (Proxied) يمرّر الحركة عبر Cloudflare مع الكاش والحماية وإخفاء عنوانك؛ الرمادي (DNS only) يحلّ الاسم فقط ويصل الزائر لسيرفرك مباشرة فيُكشف عنوانك وتُلغى الحماية. اجعل سجلّات موقعك برتقالية.
هل يسرّع Cloudflare موقعي العراقي فعلًا؟
نعم غالبًا: يخزّن الملفات الثابتة قرب الزوّار ويقلّل الحمل عن سيرفرك ويضغط الملفات. لكن السرعة الحقيقية تتطلّب ضبطًا صحيحًا للكاش — تخزين الثابت واستثناء الديناميكي — وإلا قد لا تلمس تحسّنًا أو تكسر وظائف الموقع.
هل Cloudflare يغني عن تأمين سيرفري؟
لا. Cloudflare طبقة أمام سيرفرك، لكن يبقى عليك تأمين الخادم نفسه (SSH، جدار ناري، تحديثات) وحماية عنوان الأصل. إن تسرّب عنوانك أو بقي الجدار مفتوحًا، يمكن تجاوز Cloudflare مباشرة.
الخلاصة
إعداد Cloudflare مع VPS لا ينتهي بإضاءة السحابة البرتقالية؛ بل يبدأ منها. اضبط SSL على Full (strict)، واحمِ عنوان الأصل بجدار يقبل Cloudflare فقط، وأبقِ سجلّاتك برتقالية، واضبط كاشًا ذكيًا يخزّن الثابت ويستثني الديناميكي. بهذا تحصل على أداء أسرع وحماية حقيقية دون كشف سيرفرك أو كسر موقعك — وهو الفرق بين إعداد صحيح وإعداد يبدو مفعّلًا لكنه بلا قيمة.
تحتاج سيرفرًا جاهزًا للعمل خلف Cloudflare؟
