.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
لديك خمسون موقعاً تريد نشرها من خلف عنوان عام واحد. لو استعملت تمرير المنافذ لاحتجت خمسين منفذاً غريباً — ولن يكتب زائر example.com:8437 في متصفحه. المشكلة ليست تقنية بل منطقية: المنفذ رقم، والزائر يحفظ أسماء.
الحل أن يستقبل برنامج واحد كل طلبات الويب على المنفذين 80 و443، ويقرأ اسم النطاق في كل طلب ليقرّر إلى أي خدمة داخلية يمرّره. هذا هو الوسيط العكسي، وهذا الجزء يشرح كيف يعمل قبل أن ننصّبه في الجزء التالي.
كل ما في هذه السلسلة مُنفَّذ فعلاً. بنينا المختبر على سيرفر Proxmox VE 9.2 بعنوان عام واحد، وأنشأنا عليه شبكة خاصة 10.10.10.0/24 وأربع حاويات، ونشرنا ثلاثة نطاقات فرعية حقيقية بشهادات Let's Encrypt. كل لقطة وكل مخرج أمر في هذه المقالات من ذلك المختبر — والعناوين في الصور حقيقية وقت التنفيذ.
لماذا يعمل هذا أصلاً؟
السبب في تفصيل صغير داخل بروتوكول الويب: كل طلب HTTP يحمل اسم الموقع المطلوب في ترويسة اسمها Host. جرّبها بنفسك:
curl -v https://example.com/page 2>&1 | grep -i "^> host"
> Host: example.comالخادم لا يستقبل «أعطني الصفحة» فقط، بل «أعطني صفحة example.com». فإذا وصله طلب باسم crm.example.com وآخر باسم shop.example.com على المنفذ نفسه، استطاع التفريق بينهما فوراً.
وماذا عن HTTPS؟ الاتصال مشفّر، فكيف يقرأ الوسيط الاسم قبل فكّ التشفير؟ الجواب امتداد اسمه SNI: المتصفح يرسل اسم النطاق بوضوح في أول رسالة مصافحة، قبل التشفير. بهذا يعرف الوسيط أي شهادة يقدّم وأي خدمة يقصد. بلا SNI لما أمكن وضع أكثر من موقع HTTPS على عنوان واحد.
رحلة الطلب — الصورة الكاملة
انتبه إلى الخطوة الثانية: نظام الأسماء يعطي عنوان الخادم لا عنوان الخدمة. خمسون نطاقاً تعطي العنوان نفسه، والتفريق يحدث بعد الوصول لا قبله. هذا ما يجعل عنواناً واحداً كافياً.
ما الذي يفعله الوسيط أكثر من التوجيه؟
لو كان دوره التمرير فقط لما استحقّ طبقة كاملة. لكنه يتولّى خمسة أشياء ثقيلة نيابةً عن كل خدماتك:
| الوظيفة | ماذا يعني لك عملياً |
|---|---|
| إنهاء TLS | الشهادات في مكان واحد. خدماتك الداخلية تتكلّم HTTP بسيطاً، ولا تتعامل مع الشهادات إطلاقاً. |
| تجديد Let's Encrypt | يطلب الشهادات ويجدّدها كل 90 يوماً تلقائياً — لخمسين موقعاً بالطريقة نفسها. |
| التحويل إلى HTTPS | أي طلب على 80 يُحوَّل إلى 443 بسطر واحد لكل موقع. |
| الضغط والكاش | ضغط gzip وكاش للملفات الثابتة مركزياً. |
| الحماية الأساسية | حجب أنماط هجوم معروفة، وتحديد معدّل الطلبات، وقوائم وصول لصفحات الإدارة. |
الفرق بين الحلول الثلاثة — نهائياً
الخلاصة التي يجب أن تخرج بها: NAT للخروج، وتمرير المنافذ لما ليس ويباً، والوسيط العكسي لكل الويب.
الخدمات الداخلية تتكلّم HTTP فقط
نقطة يسيء فهمها كثيرون: بعد وضع الوسيط، لا تحتاج شهادة SSL داخل كل حاوية. الترتيب:
المتصفح ──HTTPS──▶ الوسيط ──HTTP──▶ الحاوية (10.10.10.11:80)الشطر المشفّر هو الذي يعبر الإنترنت. أما بين الوسيط والحاوية فداخل سيرفرك، على جسر افتراضي لا يغادر الجهاز. تشفيره ممكن لكنه غير ضروري في هذه الحالة، ويضيف تعقيداً بلا مقابل.
لكن انتبه: الخدمة الداخلية الآن ترى كل الطلبات قادمة من عنوان الوسيط، فتظنّ أن كل زوّارك شخص واحد. الحل أن يمرّر الوسيط ترويسات X-Forwarded-For وX-Forwarded-Proto، وأن يُهيَّأ تطبيقك ليثق بها. في ووردبريس مثلاً يحتاج سطرين في wp-config.php — وسنكتبهما في الجزء السابع.
الدليل من المختبر
في مختبرنا ثلاثة نطاقات تشير إلى العنوان نفسه، وتصل إلى ثلاث حاويات مختلفة:
أي وسيط تختار؟
| الأداة | تناسب | ملاحظة |
|---|---|---|
| Nginx Proxy Manager | من يريد واجهة رسومية | الأسهل بفارق كبير — وهو خيارنا في هذه السلسلة |
| Caddy | من يحب ملفات إعداد قصيرة | شهادات تلقائية بسطرين، بلا واجهة |
| Traefik | بيئات Docker المتغيّرة | يكتشف الحاويات تلقائياً، ومنحنى تعلّمه أحدّ |
| Nginx يدوياً | من يريد تحكّماً كاملاً | أقوى وأكثر عملاً، وتدير الشهادات بنفسك |
| HAProxy | توزيع أحمال ثقيل | ممتاز في الطبقة الرابعة، أثقل في إعداد الويب |
مقارنة تفصيلية في الجزء التاسع.
أخطاء شائعة في الفهم
| الاعتقاد | الصواب |
|---|---|
| «كل موقع يحتاج عنواناً عاماً» | ترويسة Host تكفي للتفريق |
| «الوسيط يبطّئ الموقع» | يضيف أقل من ملّي ثانية، وغالباً يُسرّع بالكاش والضغط |
| «أحتاج شهادة لكل حاوية» | الشهادة على الوسيط فقط |
| «الوسيط يصلح لكل شيء» | للويب فقط — SSH وقواعد البيانات لها طرق أخرى |
| «هو نفسه موازن الأحمال» | مفهومان متقاطعان: الوسيط يوجّه حسب الاسم، والموازن يوزّع الحمل بين نسخ متطابقة |
أسئلة شائعة
هل يرى الوسيط بيانات المستخدمين؟
نعم — هو يفكّ التشفير ليقرأ الطلب. لذلك عامله كخدمة حسّاسة: حدّث نسخته، ولا تنشر لوحة إدارته على الإنترنت.
ماذا يحدث لو تعطّل؟
تتوقّف كل مواقعك معاً — وهذه تكلفة المركزية. خفّفها بـRestart=always ومراقبة تنبّهك فوراً، وبنسخة احتياطية لإعداداته (ملف صغير جداً).
هل يعمل مع تطبيقات تحتاج WebSocket؟
نعم، لكن يجب تفعيل ترقية الاتصال صراحةً. خدمات مثل n8n وNextcloud تحتاجها، ونسيانها ينتج واجهة تفتح ثم تتجمّد.
وماذا عن رفع الملفات الكبيرة؟
الوسيط يضع حدّاً افتراضياً لحجم الطلب (1 ميغابايت في nginx). إن رفعت ملفاً أكبر ستحصل على خطأ 413. الحل سطر client_max_body_size في الإعداد المتقدّم.
هل أستطيع وضع موقع على مسار بدل نطاق فرعي؟
نعم (example.com/app)، لكنها أصعب: كثير من التطبيقات لا تتعامل جيداً مع العمل تحت مسار فرعي. النطاق الفرعي أنظف دائماً.
الخطوة التالية
فهمنا الفكرة. في الجزء السادس ننصّب Nginx Proxy Manager فعلياً على حاوية LXC، ونربط به أول ثلاث خدمات بالصور خطوة بخطوة.
هذه المقالة جزء من سلسلة «من IP واحد إلى عشرات الخدمات» — عشرة أجزاء بُنيت كلها على سيرفر Proxmox حقيقي: ١. لماذا يكفي عنوان واحد · ٢. الشبكة الخاصة · ٣. إعداد NAT · ٤. تمرير المنافذ · ٥. الـReverse Proxy · ٦. Nginx Proxy Manager · ٧. النطاقات الفرعية · ٨. Cloudflare والشهادات · ٩. مقارنة الحلول · ١٠. سحابة صغيرة كاملة
