Cloudflare Tunnel أم Nginx Proxy Manager أم NAT؟ مقارنة عملية

وصلت إلى السؤال الذي يطرحه كل من يبني هذه المعمارية: أي حلّ أختار؟ الأسماء كثيرة و«الأفضل» يتغيّر بتغيّر حالتك. هذا الجزء يضع الحلول السبعة في جدول واحد، ويعطيك قاعدة اختيار واضحة بدل مقارنة نظرية.

أولاً: افصل الطبقات

نصف الحيرة يزول حين تدرك أن هذه الحلول ليست بدائل لبعضها بالضرورة:

السؤال الحقيقي ليس «NAT أم وسيط؟» بل «أي وسيط عكسي أختار؟» — وبعده: «هل أحتاج نفقاً بدل فتح المنافذ؟».

الجدول الكامل

متى تختار كلاً منها؟

Nginx Proxy Manager — الافتراضي لأغلب الناس

اخترْه إذا: عندك عنوان عام، وتريد نشر عدة مواقع، وتفضّل واجهة على ملفات إعداد.

تجنّبه إذا: ترفض Docker، أو تريد إدارة إعداداتك كنصوص في مستودع Git.

Caddy — الأبسط نصّياً

wp.example.com {
    reverse_proxy 10.10.10.11:80
}
n8n.example.com {
    reverse_proxy 10.10.10.12:5678
}

هذا الملف كامل: يطلب الشهادات ويجدّدها ويحوّل إلى HTTPS تلقائياً. اخترْه إذا كنت مرتاحاً مع الطرفية وتريد أقل تعقيد ممكن. تجنّبه إذا كان فريقك يحتاج واجهة.

Traefik — لبيئات Docker

ميزته أنه يكتشف الخدمات تلقائياً: تضيف وسماً على الحاوية فيوجّه إليها بلا تعديل إعداد.

labels:
  - "traefik.http.routers.app.rule=Host(`app.example.com`)"

اخترْه إذا كانت خدماتك في Docker وتتغيّر كثيراً. تجنّبه إذا كانت خدماتك ثابتة في حاويات LXC — ستدفع تعقيداً بلا مقابل.

HAProxy — للأحمال الثقيلة

أقوى موزّع أحمال مفتوح المصدر، ويعمل في الطبقة الرابعة أيضاً (يوزّع MySQL وRedis لا الويب فقط). اخترْه إذا كنت توزّع الحمل على عدة نسخ متطابقة وتحتاج فحوص صحة دقيقة. تجنّبه إذا كان هدفك نشر عشرة مواقع مختلفة.

Cloudflare Tunnel — حين لا تملك عنواناً عاماً

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

اخترْه إذا كنت تستضيف من بيتك أو من خلف CGNAT. تجنّبه إذا كان عندك عنوان عام وتريد استقلالية.

ثلاثة سيناريوهات واقعية

1) شركة صغيرة: موقع + نظام + سحابة ملفات

الوصفة: NAT + Nginx Proxy Manager + Cloudflare بالسحابة البرتقالية + تمرير منفذ SSH واحد مقيّد بعنوان المكتب.

لماذا: أقل تعقيد، وواجهة يفهمها من يأتي بعدك، وشهادات تُدار نفسها.

2) مطوّر يستضيف من بيته

الوصفة: Cloudflare Tunnel وحده.

لماذا: غالباً لا عنوان عام ثابت، وفتح منافذ من شبكة منزلية فكرة سيئة أصلاً.

3) مزوّد استضافة صغير: عشرات مواقع الزبائن

الوصفة: NAT + HAProxy أو nginx مُدار بملفات في Git، وحاوية معزولة لكل زبون، ومراقبة.

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

قاعدة الاختيار في ثلاثة أسئلة

1. هل عندك عنوان عام؟ لا ← Cloudflare Tunnel. نعم ← أكمل.
2. هل تريد واجهة رسومية؟ نعم ← Nginx Proxy Manager. لا ← أكمل.
3. هل خدماتك في Docker وتتغيّر كثيراً؟ نعم ← Traefik. لا ← Caddy.

وHAProxy يبقى للحالة التي تعرف فيها بنفسك أنك تحتاجه — توزيع حمل حقيقي على نسخ متعدّدة.

أخطاء شائعة في الاختيار

أسئلة شائعة

هل أستطيع الجمع بين أكثر من حل؟

نعم وهو شائع: NPM للمواقع العامة، وTunnel للوحات الإدارة، وتمرير منافذ لـSSH. الشرط ألّا يتنازع اثنان على المنفذين 80 و443.

أيّها أسرع؟

الفرق بينها مجهري في الأحمال العادية. HAProxy وnginx يتفوّقان عند عشرات آلاف الطلبات في الثانية — وهو حمل لن تبلغه غالباً. لا تختر على أساس السرعة.

هل الانتقال بينها صعب؟

لا. خدماتك لا تتغيّر، ما يتغيّر هو من يوجّه إليها. الانتقال من NPM إلى Caddy يعني كتابة ملف بعدد أسطر يساوي عدد مواقعك.

ما أخفّها على الموارد؟

Caddy وHAProxy، ثم Traefik، ثم NPM (لأنه nginx + قاعدة بيانات + واجهة). الفروق بالميغابايتات — لا تقرّر على أساسها.

هل يعمل أي منها مع WebSocket وHTTP/2؟

كلها تدعمهما. في NPM فعّل الخيار يدوياً لكل مضيف؛ في Caddy وTraefik يعملان تلقائياً.

الخطوة التالية

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