Nginx Proxy Manager أم Traefik أم HAProxy أم Caddy: أي Reverse Proxy يناسبك؟

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

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

وهذه أدلة التثبيت والاستخدام التي نقارن بينها:

دليلNginx Proxy Manager: نطاقات وشهادات TLS لكل خدماتكبدلاً من فتح منفذ مستقل لكل تطبيق، يتيح لك Nginx Proxy Manager أن تربط كل خدمة بنطاقها وتمنحها شهادة HTTPS مجانية من واجهة بسيطة، دون أن تكتب إعدادات Nginx بنفسك.دليلتثبيت Traefik على خادمك: Reverse Proxy لحاويات Docker بشهادات TLS تلقائيةمع Traefik، يحصل كل تطبيق على نطاقه وشهادة HTTPS بمجرد إضافة بضعة أسطر إلى ملف Compose الخاص به. نثبته على Ubuntu 24.04، ونحمي لوحة التحكم، ونجهز النسخ الاحتياطي والتحديث.دليلHAProxy على Ubuntu: Reverse Proxy وLoad Balancer أمام خدماتكعندما يعمل تطبيقك على أكثر من خادم، يوزع HAProxy الطلبات بينها ويستبعد المعطل منها تلقائياً. نثبته مع Docker Compose، ونكتب إعداده خطوة بخطوة، ونضيف شهادات HTTPS.دليلتثبيت Caddy على خادمك: Reverse Proxy بشهادات HTTPS تلقائيةيمنح Caddy كل موقع شهادة HTTPS تلقائياً بملف إعداد من بضعة أسطر. نثبته على Ubuntu مع Docker Compose، ونربط به تطبيقاتك بأمان، ونجهز النسخ الاحتياطي والتحديث وحلول المشكلات الشائعة.

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

• ما الذي يفعله ال Reverse Proxy بالضبط، ولماذا يرى كل ما يمر إلى تطبيقاتك.
• معايير المقارنة التي تهمك في التشغيل اليومي، وجدول يلخص الفروق بين الأدوات الأربع في إصداراتها الحالية.
• كل أداة على حدة، بنقاط قوتها ونقاط ضعفها.
• توصية واضحة لكل حالة، ومتى تجمع بين أداتين، وماذا تفعل إذا كنت تستخدم Coolify أو Dokploy.
• قاعدة المنفذين 80 و443، وملاحظات على الانتقال من أداة إلى أخرى.

ماذا يفعل الـ Reverse Proxy؟

ال Reverse Proxy برنامج يقف بين الإنترنت وتطبيقاتك، فيستقبل كل الطلبات على المنفذين Ports 80 و443، ويقرأ اسم النطاق Domain في كل طلب، ثم يرسله إلى التطبيق المقصود على منفذه الداخلي، وبالتالي يبقى على السيرفر منفذان مفتوحان فقط مهما زاد عدد التطبيقات، وهو يشبه موظف الاستقبال في مبنى فيه عدة شركات، فالزائر لا يحتاج أن يعرف رقم مكتب كل شركة وإنما يذكر اسمها فيوجهه الموظف إليها.

وفي العادة يتولى ال Reverse Proxy أيضاً إنهاء التشفير TLS Termination، أي أنه يفك تشفير HTTPS نيابة عن التطبيقات، ويطلب الشهادات من Let's Encrypt ويجددها قبل انتهائها، وقد يضيف طبقة للتحكم في الوصول Access Control، أو يوزع الطلبات على عدة نسخ من التطبيق وهذا ما يسمى موازنة الحمل Load Balancing. وإذا كانت هذه المصطلحات جديدة عليك فابدأ بدليل مصطلحات الاستضافة الذاتية للمبتدئين ثم ارجع إلى هذا المقال.

ولاحظ هنا أمراً مهماً، وهو أن البرنامج الذي يفك التشفير يرى كل ما يمر من خلاله كنص واضح، من الباسوردات وملفات تعريف الارتباط Cookies إلى التوكنات Tokens ومحتوى النماذج، ولكل التطبيقات التي خلفه، لذلك فاختيار ال Reverse Proxy قرار في الأمان قبل أن يكون قراراً في سهولة الإعداد، فاختر مشروعاً نشطاً تصله الإصلاحات الأمنية بانتظام، وحدثه دائماً.

جدول المقارنة

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

• أسلوب الإعداد Configuration: هل تدير الأداة من واجهة ويب أم من ملف نصي أم من labels تضعها على كل Container، وهذا يحدد من يستطيع إدارتها في فريقك، وهل تستطيع حفظ الإعداد في Git ومراجعته.
• أتمتة الشهادات ACME: هل تطلب الأداة شهادات Let's Encrypt وتجددها بنفسها، وهل تدعم التحقق من ملكية النطاق عبر ال DNS (DNS-01 Challenge) الذي تحتاجه لشهادات Wildcard، أي شهادة واحدة تغطي كل النطاقات الفرعية، وللخدمات الداخلية التي لا يصل إليها الإنترنت.
• اكتشاف الخدمات Service Discovery: هل تعرف الأداة بوجود Container جديد بنفسها، أم عليك أن تضيفه يدوياً في كل مرة.
• موازنة الحمل وفحوص الصحة Health Checks: ماذا يحدث عندما يتعطل أحد الخوادم الخلفية Backend Servers، وهل تخرجه الأداة من التوزيع تلقائياً.
• دعم TCP وUDP: هل تمرر الأداة خدمات لا تعمل بـ HTTP، مثل البريد وقواعد البيانات وخوادم الألعاب.
• المراقبة Monitoring والمصادقة Authentication: ماذا ترى عن الحركة التي تمر، وكيف تحمي خدمة لا تملك صفحة دخول خاصة بها.
• منحنى التعلم Learning Curve والترخيص License ونشاط المشروع: كم من الوقت يحتاج فريقك حتى يتقن الأداة، ومن يطورها، وهل تصلها التحديثات بانتظام.

والجدول التالي يلخص الفروق في الإصدارات التي اعتمدنا عليها في هذه المقارنة، وهي Nginx Proxy Manager 2.16.0، وTraefik Proxy 3.7.13، وHAProxy 3.4.6 من سلسلة الدعم طويل الأمد Long Term Support واختصاراً LTS، وCaddy 2.11.4، ويجدر الإشارة هنا إلى أن Caddy أصدر بعده الإصدار 2.11.6 في 1 أكتوبر 2026 ثم 2.11.7 في 3 أكتوبر لإصلاح أخطاء ظهرت في 2.11.6، كما سيأتي في قسم Caddy.

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

Nginx Proxy Manager: التحكم من الواجهة الرسومية

Nginx Proxy Manager واختصاراً NPM هو خادم Nginx تديره من واجهة ويب، فتضيف Proxy Host بنطاقه واسم ال Container ومنفذه، ثم تطلب الشهادة بنقرة واحدة، ويذكر دليل المشروع أن هدفه البساطة، بحيث لا يحتاج من يستخدمه إلى معرفة Nginx أو Let's Encrypt.

والصورة التالية تبين قائمة المضيفين Proxy Hosts في Nginx Proxy Manager من تثبيتنا، فكل سطر فيها نطاق مع الوجهة التي يمرر إليها الطلبات ونوع الشهادة وقائمة الوصول وحالة المضيف:

نقاط القوة

• لا توجد ملفات إعداد: يستطيع مدير غير متخصص أن يضيف نطاقاً جديداً أو يجدد شهادة دون أن يفتح الطرفية Terminal، وهذا وحده سبب كاف لاختياره في كثير من المكاتب الصغيرة.
• شهادات عبر التحقق من ال DNS (DNS Challenge): يثبت NPM إضافة Certbot المناسبة لمزود DNS الذي تختاره، وبالتالي تحصل على شهادة Wildcard، أو على شهادة لخدمة داخلية لا يصل إليها الإنترنت.
• قوائم وصول ومستخدمون: تقيد الخدمة بالباسورد أو بعناوين IP، وتعطي مستخدمين آخرين صلاحيات Permissions على مضيفيهم فقط، مع سجل للعمليات يبين من غير ماذا.
• Streams لخدمات TCP وUDP: تمرر منفذاً كاملاً إلى خدمة لا تعمل بـ HTTP، مثل خادم ألعاب أو قاعدة بيانات Database.

نقاط الضعف

• يحفظ الإعداد في قاعدة بيانات، SQLite افتراضياً أو MySQL أو PostgreSQL، وليس في ملفات نصية، لذلك يصعب أن تراجعه في Git أو تعيد بناءه آلياً على سيرفر جديد.
• لا يكتشف ال Containers، فكل تطبيق جديد يعني خطوة يدوية في الواجهة.
• لا توجد في الواجهة موازنة حمل ولا فحوص صحة، وتستطيع كتابتها يدوياً في إعدادات Nginx المخصصة، ولكنك تخسر عندها البساطة التي اخترته من أجلها.
• يعتمد تطوير المشروع كثيراً على مطور رئيسي واحد، لذلك ضع هذا في حسابك عندما تقدر المخاطر في مؤسستك.

Traefik Proxy: تكتب الإعداد مع التطبيق نفسه

يعمل Traefik Proxy بطريقة معاكسة، فأنت لا تخبره بوجود تطبيق جديد، وإنما يقرأ ذلك بنفسه من ال labels التي تضعها على ال Container في ملف Compose، فتشغل ال Container فيظهر مساره، وتوقفه فيختفي، دون أن تعيد تشغيل Traefik.

والصورة التالية تبين لوحة Traefik Dashboard من تثبيت تجريبي فيه تطبيقان، ولاحظ أن المسارين blog@docker وwiki@docker ظهرا من ال labels دون أن نضيفهما يدوياً، وأيقونة Docker في عمود Provider تبين مصدر كل مسار:

نقاط القوة

• اكتشاف تلقائي: يتابع مزود Docker Docker Provider أحداث Docker مباشرة، وفي Traefik مزودات مماثلة لـ Swarm وKubernetes ولـ الملفات.
• البنية التحتية ككود Infrastructure as Code: مسار كل تطبيق وشهادته في ملف Compose الخاص به، لذلك يناسب أسلوب GitOps، فيصبح المستودع Repository المرجع الوحيد لكل ما يعمل على السيرفر.
• شهادات تلقائية: يطلب محلل الشهادات Certificate Resolver الشهادة حين يظهر نطاق جديد ويجددها، بالتحقق عبر HTTP أو TLS أو DNS.
• Middlewares جاهزة: منها BasicAuth وIPAllowList وForwardAuth، والأخير يربط التطبيقات بنظام دخول موحد مثل authentik.
• موازنة حمل ومراقبة: يوزع الطلبات على نسخ الخدمة بعدة استراتيجيات مع فحوص صحة نشطة وسلبية، ويصدر مقاييس بصيغة Prometheus وOpenTelemetry وغيرها.

نقاط الضعف

• المفاهيم الأربعة EntryPoints وRouters وServices وMiddlewares تحتاج وقتاً حتى تفهمها، وخطأ في label واحد قد يخفي المسار دون رسالة واضحة، وسوف تقضي وقتاً في البحث عن حرف ناقص قبل أن تعتاد عليها.
• يحتاج مزود Docker إلى الوصول إلى Docker socket، وهذا الوصول يكاد يساوي صلاحيات root على السيرفر، ولا يقيده تركيب ال socket للقراءة فقط، والسبب أن القراءة فقط تمنع تعديل الملف نفسه ولا تمنع إرسال الأوامر إلى Docker عبره، لذلك ضع بينهما وسيطاً Socket Proxy لا يسمح إلا بطلبات القراءة.
• اللوحة للعرض فقط، ولا تكشفها أبداً دون مصادقة.
• يذكر التوثيق الرسمي أنك لا تستطيع تشغيل أكثر من نسخة من Traefik Proxy مع Let's Encrypt، والسبب أنه لا يضمن وصول طلب التحقق إلى النسخة التي طلبت الشهادة، فإذا أردت التوافرية High Availability مع شهادات تلقائية فسوف تحتاج إلى إصدار الشهادات خارج Traefik، مثل cert-manager في Kubernetes.
• بعض ال Middlewares في التوثيق، مثل OIDC، متاحة في Traefik Hub التجاري فقط، فانتبه إلى هذه العلامة في رأس الصفحة قبل أن تبني عليها.

HAProxy: عندما توزع الحمل على عدة خوادم

يقدم HAProxy نفسه موازن حمل Load Balancer موثوقاً وعالي الأداء لحركة TCP وHTTP، ويعمل أمام مواقع وخدمات كبيرة منذ سنوات، وتضعه منصات كثيرة طبقة أولى أمام خوادمها، ولكنه لم يصمم لإدارة عشرات التطبيقات الصغيرة على سيرفر منزلي، وهذا ما سوف تشعر به من أول ملف إعداد تكتبه.

والصورة التالية تبين صفحة الإحصاءات Stats Page في HAProxy من تثبيت تجريبي فيه خادمان خلفيان للتطبيق، وقد أوقفنا أحدهما عمداً، فتلاحظ أن app2 ظهر باللون الأحمر بحالة DOWN بعد أن فشل فحص الصحة، بينما يستمر app1 في استقبال الطلبات:

نقاط القوة

• موازنة حمل دقيقة: عدد كبير من خوارزميات balance، مثل roundrobin وleastconn وsource، مع ثبات الجلسة Session Persistence.
• فحوص صحة متقدمة: يفحص كل خادم خلفي على مستوى TCP أو عبر option httpchk، فيخرجه من التوزيع فور تعطله، ويعيده بعد أن يتعافى.
• TCP بالكامل: في وضع tcp يمرر HAProxy أي بروتوكول فوق TCP، مثل SMTP وIMAP وقواعد البيانات، ويوزعه على عدة خوادم.
• رؤية تفصيلية: تعرض صفحة الإحصاءات حالة كل خادم وعدد اتصالاته وأخطاءه، وفي المشروع مصدر لمقاييس Prometheus.
• تحكم في الحركة: بقواعد ACL وجداول Stick Tables تحدد معدل الطلبات وتصد الإساءة قبل أن تصل إلى التطبيق.
• دعم طويل: تحصل سلاسل LTS على تحديثات لمدة خمس سنوات، فسلسلة 3.4 مدعومة حتى الربع الثاني من 2031 بحسب جدول الإصدارات.

نقاط الضعف

• كل شيء في ملف نصي، فلإضافة تطبيق جديد تعدل الملف ثم تعيد تحميله Reload، ويسمح Runtime API وData Plane API ببعض التعديل الآلي، ولكنهما لا يغنيانك عن فهم الإعداد.
• لا يكتشف ال Containers من ال labels، وأقصى ما يقدمه هنا حل الأسماء عبر DNS مع server-template.
• عميل ACME المدمج ما زال تجريبياً ويحتاج إلى تفعيل expose-experimental-directives، ولا يكتب HAProxy الشهادات التي يصدرها على القرص بنفسه، وإنما تستخرجها من خارجه بأمر dump ssl cert أو بسكربت مرفق مع المشروع، لذلك تصدر أغلب البيئات الشهادات بأداة خارجية.
• لا يوجد في النسخة المجتمعية توزيع لحركة UDP العامة، مثل DNS أو الألعاب.
• لا توجد واجهة ويب للإدارة في النسخة المجتمعية، وأدوات الإدارة المركزية موجودة في منتجات HAProxy Technologies التجارية، مثل HAProxy Enterprise.

Caddy: HTTPS دون أن تطلبه

فكرة Caddy بسيطة، فكل موقع تكتب اسمه في الإعداد يعمل عبر HTTPS تلقائياً، فلا تعرف محلل شهادات ولا تثبت Certbot، وإنما تكتب اسم النطاق وعنوان التطبيق في Caddyfile، فيطلب Caddy الشهادة ويجددها ويحول HTTP إلى HTTPS، وهو أيضاً خادم ويب Web Server كامل يقدم المواقع الثابتة Static Sites من الملف نفسه.

وليس لـ Caddy واجهة رسومية، فكل الإدارة تتم من ال Caddyfile، والصورة التالية تبين ملفاً فيه موقعان، والثاني منهما يوزع الطلبات على نسختين مع فحص الصحة، ثم فحص الملف بالأمر caddy validate قبل تطبيقه:

نقاط القوة

• HTTPS افتراضي: يفعل HTTPS التلقائي لكل نطاق في الإعداد، وإذا فشل الطلب من Let's Encrypt جرب ZeroSSL، ثم يعيد المحاولة بفواصل متزايدة دون تدخل منك.
• إعداد قصير مقروء: الموقع العادي يكفيه سطران أو ثلاثة، والإعدادات المشتركة تكتبها مرة واحدة في مقتطف Snippet وتدرجها بـ import، والملف سهل الحفظ في Git والمراجعة.
• لا يحتاج إلى Docker socket: يصل إلى ال Containers بأسمائها عبر شبكة Docker مشتركة، ولا يملك أي وصول إلى Docker نفسه، وهذا فرق أمني مهم مقارنة بـ Traefik.
• إعادة تحميل دون انقطاع: يطبق الأمر caddy reload الإعداد الجديد دون قطع الاتصالات، وإذا وجد فيه خطأ رفضه وأبقى القديم.
• توزيع حمل يكفي أغلب الحالات: يوزع reverse_proxy الطلبات على عدة نسخ بعدة سياسات، مع فحوص صحة نشطة وسلبية.

نقاط الضعف

• لا توجد واجهة ويب للإدارة، فمن لا يريد تعديل ملف نصي سوف يجد Nginx Proxy Manager أسهل.
• لا يكتشف ال Containers في النسخة القياسية، فكل تطبيق جديد يعني موقعاً جديداً في ال Caddyfile، إلا إذا استخدمت إضافة مثل caddy-docker-proxy.
• التحقق من ملكية النطاق عبر ال DNS (DNS Challenge) وشهادات Wildcard ودعم TCP وUDP تحتاج كلها إلى بناء نسخة مخصصة بأداة xcaddy وإلى إعادة بنائها مع كل تحديث، وإضافة caddy-l4 لحركة TCP وUDP ما زالت تجريبية.
• ال Admin API بلا أي مصادقة في الإعداد الافتراضي، فأبقه على localhost ولا تنشر منفذه أبداً.
• يحفظ الشهادات في مجلد البيانات Data Directory، فإذا شغلته دون Volume دائم فسوف يطلب الشهادات من جديد كلما أعدت إنشاء ال Container، حتى يصطدم بحدود Let's Encrypt.
• لا تحدث إلى 2.11.6 إذا كان Caddy يمرر حركة HTTP/2 أو ردوداً متدفقة مثل Server-Sent Events، والسبب أن هذا الإصدار أضاف مهلات خمول Idle Timeouts افتراضية تسببت في توقف Caddy بخطأ panic عند تمرير بعض طلبات HTTP/2، وفي قطع الردود المتدفقة بعد دقيقة، وقد أصلحها الإصدار 2.11.7 بعد يومين، فإذا لم تجد وسمه في ال Image الرسمي بعد فابق على 2.11.4، واقرأ قسم التغييرات الكاسرة Breaking Changes في ملاحظات 2.11.6 قبل الترقية.

أيها تختار؟

لا تسأل أي أداة هي الأفضل، وإنما اسأل من سوف يدير ال Reverse Proxy، وكم مرة يتغير ما خلفه، فإذا عرفت الإجابة على هذين السؤالين فسوف تجد أن الاختيار واضح في أغلب الحالات، وفيما يلي توصيتنا لكل حالة.

خادم واحد وبضعة تطبيقات ومدير غير متخصص: Nginx Proxy Manager

لنفرض أن لديك مكتباً صغيراً يشغل على سيرفر واحد قاعدة معرفة Knowledge Base ونظام تذاكر وموقعاً، ويديره موظف تقنية معلومات لا يكتب ملفات إعداد، فهنا يكفي NPM تماماً، والسبب أن التطبيقات قليلة ولا تتغير كل أسبوع، والمدير يرى كل المضيفين والشهادات في صفحة واحدة ويستطيع أن يصلح أي شيء من المتصفح. ولكن تذكر أن تدرج مجلد بيانات NPM في النسخ الاحتياطي Backup، فالإعداد كله محفوظ فيه.

Containers كثيرة تتغير باستمرار وإعداد في Git: Traefik

أما إذا كان لديك فريق تطوير ينشر كل أسبوع تطبيقات جديدة وبيئات اختبار Staging، ويحفظ كل ملفات Compose في مستودع ويطبقها عبر Pipeline، فهنا يتفوق Traefik، والسبب أن المطور يضيف ال labels إلى خدمته فيظهر المسار والشهادة دون أن يلمس أحد ال Reverse Proxy، وتصبح مراجعة أي تغيير في المسارات جزءاً من مراجعة الكود نفسه.

عدة خوادم خلفية وحركة كثيفة وخدمات TCP وتوافرية عالية: HAProxy

وفي مؤسسة متوسطة تشغل تطبيقها على ثلاثة سيرفرات، ولا يجوز أن يتوقف إذا تعطل أحدها، وتمرر أيضاً خدمات بريد وقاعدة بيانات عبر TCP، فالحل الأنسب هو HAProxy، والسبب أنه صمم لهذه البيئة بالذات، فيفحص كل سيرفر ويخرجه إذا تعطل ويوزع الاتصالات بحسب الحمل. وحتى لا يصبح HAProxy نفسه نقطة فشل وحيدة Single Point of Failure، فإنه يشغل عادة على سيرفرين يتشاركان عنوان IP عائماً Floating IP تنقله بينهما أداة مثل Keepalived.

ملفات إعداد بسيطة وأقصر طريق إلى HTTPS: Caddy

وإذا كان لديك فريق صغير يشغل على سيرفر واحد موقع الشركة الثابت وبضعة تطبيقات داخلية، ويريد الإعداد ملفاً نصياً يحفظه في Git ويراجعه، بلا labels على كل Container وبلا واجهة ويب، فإن Caddy هو الأنسب، والسبب أن التطبيق الجديد ثلاثة أسطر في ال Caddyfile ثم caddy reload، والشهادات تصدر وتتجدد دون أي خطوة إضافية، ولا يحتاج إلى Docker socket كما يحتاجه Traefik. ولكن تذكر أن تدرج مجلد بيانات Caddy في النسخ الاحتياطي، فالشهادات ومفاتيحها محفوظة فيه.

الجمع بينهما: HAProxy في الأمام وTraefik على كل خادم

ولست مضطراً إلى أداة واحدة للبنية كلها، فمن الأنماط الشائعة أن يقف HAProxy في الطبقة الأولى يوزع الحركة على عدة سيرفرات ويفحص صحتها، وعلى كل سيرفر يعمل Traefik ويوجه الطلبات إلى ال Containers المحلية بحسب ال labels، وبهذا الشكل تجمع بين موازنة الحمل الدقيقة والاكتشاف التلقائي.

وفي هذا النمط لديك طريقان، إما أن يمرر HAProxy حركة TLS كما هي في وضع tcp ويتولى Traefik الشهادات، وإما أن ينهي HAProxy التشفير بنفسه ثم يمرر HTTP، وفي الحالتين فعل send-proxy-v2 على HAProxy، وPROXY Protocol على نقطة الدخول EntryPoint في Traefik مع تحديد العناوين الموثوقة، والسبب أنك بدون ذلك سوف ترى في سجلات كل التطبيقات عنوان HAProxy بدلاً من عنوان IP الحقيقي للزائر.

ماذا لو كنت تستخدم Coolify أو Dokploy؟

إذا كنت تنشر تطبيقاتك عبر منصة مثل Coolify أو Dokploy فغالباً لا تحتاج إلى هذا الاختيار أصلاً، فمنصة Coolify تشغل على كل سيرفر Container اسمه coolify-proxy، وخيارها الافتراضي Traefik ويمكنك اختيار Caddy بدلاً منه، ويعتمد Dokploy على Traefik للتوجيه واكتشاف الخدمات، وفي الحالتين تولد المنصة ال labels والشهادات من واجهتها، لذلك لا تثبت Reverse Proxy آخر على السيرفر نفسه، وإذا أصررت على أداتك الخاصة فإن Coolify يتيح لك إيقاف ال Proxy الذي يديره، ولكنك عندها تتولى التوجيه والشهادات بنفسك.

وللمقارنة بين هذه المنصات راجع مقارنة Portainer وCoolify وDokploy، ثم دليل تثبيت Coolify أو دليل تثبيت Dokploy.

قاعدة لا استثناء فيها: برنامج واحد على المنفذين 80 و443

لا يستطيع برنامجان الاستماع على المنفذ نفسه في العنوان نفسه، فإذا شغلت NPM على سيرفر يعمل عليه Traefik الذي تثبته Coolify فسوف يفشل أحدهما في البدء برسالة مثل address already in use، أو يأخذ أحدهما المنفذ ويبقى الآخر بلا حركة، لذلك اختر لكل سيرفر Reverse Proxy واحداً يملك المنفذين 80 و443، ومرر كل الخدمات عبره.

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

sudo ss -tlnp | grep -E ':(80|443)\b'

ملاحظات على الانتقال بين الأدوات

• من NPM إلى Traefik: انسخ من الواجهة قائمة بكل Proxy Host ونطاقه ومنفذه، ثم حولها إلى labels على ال Containers، وأبق NPM يعمل حتى تجهز ال labels، ثم أوقفه وشغل Traefik مكانه في نافذة صيانة قصيرة، وسجلات DNS لا تتغير ما دام السيرفر نفسه.
• الشهادات: تطلب الأداة الجديدة شهادات جديدة لكل النطاقات، فإذا كانت النطاقات كثيرة فانتبه إلى حدود Let's Encrypt Rate Limits، واختبر أولاً على بيئة الاختبار Staging التي توفرها Let's Encrypt.
• قوائم الوصول: لا تنتقل تلقائياً، فقائمة الوصول في NPM تصبح Middleware في Traefik، أو قاعدة ACL في HAProxy، أو basic_auth ومطابق remote_ip في Caddy.
• من NPM أو Traefik إلى Caddy: كل Proxy Host أو Router يصبح موقعاً من بضعة أسطر في ال Caddyfile فيه النطاق واسم ال Container ومنفذه، فافحص الملف بالأمر caddy validate قبل أن توقف الأداة القديمة، ثم شغل Caddy مكانها في نافذة صيانة قصيرة، وتذكر أن Caddy أيضاً سوف يطلب الشهادات من جديد لكل النطاقات.
• إضافة HAProxy أمام بنية قائمة: لا تحتاج إلى إزالة Traefik أو NPM، وإنما تنقل الأداة الحالية إلى منفذ داخلي أو إلى خوادم خلفية، وتضع HAProxy أمامها، ثم توجه سجلات DNS إلى عنوان HAProxy.
• الانتقال إلى منصة: إذا ثبتت Coolify أو Dokploy على سيرفر يعمل عليه NPM فأوقف NPM أولاً وانقل نطاقاته إلى المنصة، والسبب أن المنصة سوف تطلب المنفذين 80 و443 لنفسها.

وقبل أي انتقال خذ نسخة احتياطية من بيانات الأداة الحالية وشهاداتها، حتى تعود إليها إذا تعثر شيء، وإذا كنت تنقل ال Containers إلى سيرفر جديد في الوقت نفسه فافصل الخطوتين، وابدأ بـ تثبيت Docker على السيرفر الجديد.

الخلاصة

وصلنا لنهاية الموضوع، والجدول التالي يلخص توصيتنا لكل حالة:

• اختر الأداة بحسب من يديرها وكم مرة يتغير ما خلفها، وليس بحسب أرقام الأداء، فعلى سيرفر يشغل بضعة تطبيقات لن تشعر بفرق بينها.
• ال Reverse Proxy يرى كل بيانات تطبيقاتك بعد فك التشفير، فحدثه دائماً، واقرأ ملاحظات الإصدار قبل الترقية كما رأينا مع Caddy 2.11.6.
• إذا استخدمت Traefik فلا تعطه Docker socket مباشرة، وإنما عبر Socket Proxy للقراءة فقط.
• برنامج واحد فقط يملك المنفذين 80 و443 على كل سيرفر، وأدرج بيانات الأداة وشهاداتها في النسخ الاحتياطي، فالخطأ المكلف فعلاً هو أداتان تتنازعان المنفذين نفسيهما أو إعداد بلا نسخة احتياطية.

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

• أكتوبر 2026: كتابة المقال.
• أكتوبر 2026: إضافة Caddy إلى المقارنة.
• أكتوبر 2026: مراجعة تقنية للمقارنة، وإضافة تحذير من Caddy 2.11.6 وإصلاحه في 2.11.7، وتوضيح حدود عميل ACME في HAProxy 3.4 وطريقة التحقق dns-persist-01، وعارض السجلات وقوائم الوصول لكل مسار في Nginx Proxy Manager 2.16.0، وخيار metrics في Caddy.
• أكتوبر 2026: إضافة صور من تثبيتنا لكل أداة، ورابط واضح في نهاية قسم كل أداة إلى دليل تثبيتها واستخدامها، وربط أسماء الأدوات في جدول المقارنة بأدلتها.