يُتيح لك إنشاء Reverse Proxy نشر عدة مواقع وتطبيقات من عنوان IP واحد، بدل شراء عنوانٍ عام مستقل لكل خدمة. فمع توسّع المشاريع الرقمية، قد تحتاج الشركات إلى تشغيل عدة مواقع وتطبيقات ويب وأنظمة ERP ولوحات إدارة وواجهات API على خوادم منفصلة؛ ومنح كل خادم عنوان IP عام مستقل ليس دائماً الخيار الأفضل من حيث التكلفة أو الأمان.

مع توسع المشاريع الرقمية، قد تحتاج الشركات إلى تشغيل عدة مواقع إلكترونية، تطبيقات ويب، أنظمة ERP، لوحات إدارة، واجهات API وخدمات داخلية على خوادم منفصلة. لكن منح كل خادم عنوان IP عام مستقل ليس دائماً الخيار الأفضل من حيث التكلفة أو الأمان أو سهولة الإدارة.

محتويات المقال

هنا يأتي دور Reverse Proxy بوصفه واحداً من أهم مكونات البنية التحتية الحديثة. فمن خلال خادم Reverse Proxy واحد، تستطيع استقبال طلبات الزوار عبر عنوان IP عام واحد، ثم توجيه كل طلب إلى الخادم أو التطبيق الصحيح بناءً على اسم النطاق، مع إدارة شهادات SSL، وتطبيق سياسات الحماية، وتوزيع الأحمال من نقطة مركزية واحدة.

داخل مرام بلاتفورم يمكن إنشاء خادم Reverse Proxy احترافي يعمل أمام عدة خوادم Linux وWindows وتطبيقات Docker وOdoo وERP، بحيث تبقى الخوادم الخلفية داخل شبكة خاصة، بينما يتم نشر الخدمات المطلوبة فقط عبر الإنترنت.

في هذا الدليل سنتعرف على كيفية إنشاء Reverse Proxy لنشر عدة مواقع وتطبيقات من عنوان IP واحد، وأفضل الأدوات المستخدمة، وطريقة تصميم البنية داخل Proxmox، إضافة إلى أهم ممارسات الأمان والأداء والتوسع.

ما هو Reverse Proxy؟

الـ Reverse Proxy هو خادم وسيط يستقبل اتصالات المستخدمين قبل وصولها إلى خوادم التطبيقات الفعلية.

عنوان IP واحد… عدة مواقع
وزّع مواقعك من عنوانٍ واحد

عندما يفتح المستخدم موقعاً مثل:

example.com

يصل الطلب أولاً إلى خادم Reverse Proxy، ثم يحدد هذا الخادم المكان الذي يجب إرسال الطلب إليه داخل الشبكة الخاصة.

على سبيل المثال:

  • website.example.com يتم توجيهه إلى خادم الموقع.
  • app.example.com يتم توجيهه إلى خادم التطبيق.
  • erp.example.com يتم توجيهه إلى خادم Odoo.
  • api.example.com يتم توجيهه إلى خادم API.
  • panel.example.com يتم توجيهه إلى لوحة الإدارة.

يمكن أن تعمل جميع هذه الخدمات خلف عنوان IPv4 عام واحد، بينما يمتلك كل خادم خلفي عنوان IP خاصاً مستقلاً.

كيف يعمل Reverse Proxy؟

عند وصول طلب من المستخدم، تمر العملية بالمراحل التالية:

كيف يعمل Reverse Proxy
يوجّه الطلب للخادم المناسب داخلياً
  1. يقوم المستخدم بفتح اسم النطاق.
  2. يوجه DNS اسم النطاق إلى عنوان IP العام الخاص بالـ Reverse Proxy.
  3. يستقبل Reverse Proxy طلب HTTP أو HTTPS.
  4. يقرأ اسم النطاق المطلوب.
  5. يطابقه مع قاعدة التوجيه المناسبة.
  6. يرسل الطلب إلى الخادم الخلفي داخل الشبكة الخاصة.
  7. يعيد استجابة الخادم إلى المستخدم.

من وجهة نظر الزائر، يبدو وكأنه يتصل مباشرة بالموقع أو التطبيق، بينما تتم عملية التوجيه داخلياً بصورة آمنة ومنظمة.

لماذا تحتاج الشركات إلى Reverse Proxy؟

عند تشغيل عدة مشاريع، يمكن منح عنوان IP عام لكل خادم. لكن هذا التصميم يرفع عدد العناوين المطلوبة، ويزيد عدد النقاط المكشوفة على الإنترنت، ويجعل إدارة شهادات SSL وقواعد الحماية أكثر تعقيداً.

💡 اقرأ أيضاً: ما هي مرام بلاتفورم؟ منصة البنية التحتية السحابية الكاملة

يقدم Reverse Proxy مجموعة كبيرة من المزايا، أهمها:

  • نشر عدة مواقع من عنوان IP واحد.
  • تقليل الحاجة إلى عناوين IPv4 إضافية.
  • إخفاء عناوين الخوادم الخلفية.
  • إدارة شهادات SSL من مكان واحد.
  • توجيه النطاقات إلى خوادم مختلفة.
  • تطبيق سياسات حماية مركزية.
  • دعم Load Balancing.
  • تسهيل نقل التطبيقات بين الخوادم.
  • توفير نقطة دخول موحدة للبنية التحتية.
  • عزل خوادم قواعد البيانات والتطبيقات عن الإنترنت.

نشر عدة مواقع من عنوان IP واحد

تعتمد الفكرة على استخدام أسماء نطاقات أو نطاقات فرعية مختلفة، مع توجيه جميع سجلات DNS إلى عنوان IP العام نفسه.

💡 اقرأ أيضاً: تخصيص رينجات IP: توفير /29 و/28 و/27 حسب الحاجة

على سبيل المثال، يمكن أن تشير النطاقات التالية إلى عنوان IP واحد:

  • company.com
  • shop.company.com
  • erp.company.com
  • api.company.com
  • support.company.com

يتولى Reverse Proxy تحديد الخادم المطلوب لكل نطاق.

قد تكون الخوادم الخلفية بالشكل التالي:

  • الموقع الرئيسي: 10.10.10.11
  • المتجر الإلكتروني: 10.10.10.12
  • نظام Odoo: 10.10.10.13
  • خادم API: 10.10.10.14
  • نظام الدعم: 10.10.10.15

وبذلك تحصل الشركة على بنية منظمة دون فتح جميع الخوادم مباشرة على الإنترنت.

الفرق بين Reverse Proxy وForward Proxy

رغم تشابه الاسمين، فإن وظيفة كل منهما مختلفة.

يعمل Forward Proxy نيابة عن المستخدمين، حيث يمر اتصال المستخدم بالإنترنت عبر خادم وسيط.

أما Reverse Proxy فيعمل نيابة عن الخوادم، حيث يستقبل طلبات الزوار ويوجهها إلى الخوادم الخلفية المناسبة.

يستخدم Forward Proxy عادةً في:

  • التحكم باتصال الموظفين بالإنترنت.
  • إخفاء عنوان المستخدم.
  • تصفية المحتوى.
  • تجاوز بعض قيود الشبكة.

بينما يستخدم Reverse Proxy في:

  • نشر المواقع والتطبيقات.
  • إدارة SSL.
  • توزيع الأحمال.
  • حماية الخوادم الخلفية.
  • توجيه النطاقات.

تصميم Reverse Proxy داخل مرام بلاتفورم

يمكن بناء البنية داخل مرام بلاتفورم باستخدام عدة خوادم افتراضية ضمن لوحة Proxmox واحدة.

يتكون التصميم الأساسي من:

  • خادم Reverse Proxy.
  • خادم الموقع الإلكتروني.
  • خادم التطبيق.
  • خادم قاعدة البيانات.
  • خادم Odoo أو ERP.
  • خادم Monitoring.
  • خادم Backup.
  • Firewall افتراضي عند الحاجة.

يمتلك Reverse Proxy واجهة شبكة مرتبطة بالإنترنت، بينما ترتبط جميع الخوادم الخلفية بشبكة خاصة.

يمكن أن يكون التصميم على الشكل التالي:

الإنترنت ← Firewall ← Reverse Proxy ← الشبكة الخاصة ← خوادم المواقع والتطبيقات

هذا التصميم يقلل عدد الخوادم المكشوفة مباشرة، ويوفر تحكماً مركزياً في الاتصالات الواردة.

أفضل برامج Reverse Proxy

توجد عدة حلول يمكن استخدامها حسب حجم المشروع وخبرة فريق الإدارة.

ويُعدّ NGINX من أشهر خيارات Reverse Proxy وأكثرها كفاءةً واستقراراً، إلى جانب HAProxy وTraefik وCaddy.

NGINX

يعد NGINX Reverse Proxy من أشهر الحلول المستخدمة لنشر المواقع والتطبيقات.

يتميز بـ:

  • أداء مرتفع.
  • استهلاك منخفض للموارد.
  • دعم HTTP وHTTPS.
  • إدارة SSL.
  • دعم WebSocket.
  • دعم Load Balancing.
  • مرونة كبيرة في الإعداد.
  • توافق مع معظم تطبيقات الويب.

يمكن استخدامه أمام:

  • WordPress.
  • Laravel.
  • Node.js.
  • Odoo.
  • Django.
  • ASP.NET.
  • Docker.
  • تطبيقات SaaS.

NGINX Proxy Manager

يقدم NGINX Proxy Manager واجهة رسومية تسهل إدارة Reverse Proxy دون الحاجة إلى كتابة جميع ملفات الإعداد يدوياً.

يتيح:

  • إضافة Proxy Hosts.
  • إصدار شهادات SSL.
  • إدارة النطاقات.
  • إضافة قواعد وصول.
  • دعم WebSocket.
  • إعادة توجيه النطاقات.
  • إنشاء قوائم وصول.

يعتبر خياراً مناسباً للشركات التي تريد حلاً سهلاً وقابلاً للإدارة من خلال المتصفح.

HAProxy

يعد HAProxy حلاً احترافياً لتوزيع الأحمال وإدارة الاتصالات ذات الحجم الكبير.

يتميز بـ:

  • أداء عالٍ.
  • Load Balancing متقدم.
  • Health Checks.
  • دعم TCP وHTTP.
  • توزيع الجلسات.
  • مراقبة الخوادم الخلفية.
  • Failover تلقائي.

يستخدم عادةً في البيئات التي تحتوي على عدة نسخ من التطبيق نفسه.

Traefik

تم تصميم Traefik بصورة خاصة للبيئات الديناميكية والحاويات.

يتكامل بشكل ممتاز مع:

  • Docker.
  • Docker Compose.
  • Kubernetes.
  • Docker Swarm.

يستطيع اكتشاف الخدمات الجديدة تلقائياً وتحديث قواعد التوجيه دون تعديل يدوي كبير.

Caddy

يعتبر Caddy خياراً بسيطاً وحديثاً، ويتميز بسهولة إصدار شهادات HTTPS وإدارتها تلقائياً.

يمكن استخدامه للمشاريع الصغيرة والمتوسطة التي تحتاج إلى إعداد سريع وواضح.

أي Reverse Proxy تختار؟

يعتمد الاختيار على نوع البنية التحتية.

يمكن استخدام NGINX عندما تحتاج إلى:

  • تحكم كامل.
  • إعدادات متقدمة.
  • أداء ثابت.
  • دعم واسع للتطبيقات.

يمكن استخدام NGINX Proxy Manager عندما تحتاج إلى:

  • واجهة رسومية.
  • إدارة سهلة.
  • إصدار SSL بنقرات بسيطة.
  • نشر عدد كبير من النطاقات بسرعة.

يمكن استخدام HAProxy عندما تحتاج إلى:

  • Load Balancing متقدم.
  • عدد كبير من الاتصالات.
  • High Availability.
  • توزيع الحمل بين عدة خوادم.

يمكن استخدام Traefik عندما تعتمد بيئتك على:

  • Docker.
  • Kubernetes.
  • الخدمات المصغرة.
  • النشر الآلي.

خطوات إنشاء Reverse Proxy داخل مرام بلاتفورم

إنشاء آلة افتراضية مخصصة

ابدأ بإنشاء آلة افتراضية جديدة داخل لوحة Proxmox.

يمكن تثبيت أحد الأنظمة التالية:

  • Ubuntu Server.
  • Debian.
  • AlmaLinux.
  • Rocky Linux.

بالنسبة إلى معظم المشاريع، تعد Ubuntu Server أو Debian خيارات مناسبة ومستقرة.

تخصيص الموارد

لا يحتاج Reverse Proxy الأساسي عادةً إلى موارد ضخمة، لكن الحجم الفعلي يعتمد على عدد المواقع، الاتصالات المتزامنة، التشفير، الكاش، وحجم الترافيك.

يمكن البدء بموارد مناسبة مثل:

  • 2 vCPU.
  • 2 إلى 4 GB RAM.
  • 30 إلى 60 GB NVMe.

ثم زيادة الموارد وفق الاستهلاك الفعلي.

عند تشغيل WAF أو IDS أو عدد كبير من الاتصالات المشفرة، قد تحتاج إلى CPU وRAM إضافيين.

ربط الشبكات

يفضل أن يمتلك Reverse Proxy:

  • اتصالاً بالشبكة العامة أو مساراً عبر Firewall.
  • اتصالاً بالشبكة الخاصة التي تحتوي على خوادم التطبيقات.

أما الخوادم الخلفية، فيمكن تشغيلها بعناوين IP خاصة فقط.

تثبيت برنامج Reverse Proxy

يمكن تثبيت NGINX مباشرة على النظام، أو تشغيل NGINX Proxy Manager وTraefik من خلال Docker.

بعد التثبيت، تتم إضافة النطاقات والخوادم الخلفية والمنافذ المطلوبة.

إعداد DNS

يجب إنشاء سجل DNS من نوع A لكل نطاق أو نطاق فرعي، وتوجيهه إلى عنوان IP العام الخاص بالـ Reverse Proxy.

مثال:

  • www.example.com ← عنوان IP العام.
  • app.example.com ← عنوان IP العام نفسه.
  • erp.example.com ← عنوان IP العام نفسه.
  • api.example.com ← عنوان IP العام نفسه.

بعد ذلك يحدد Reverse Proxy الوجهة الداخلية لكل نطاق.

إعداد قواعد التوجيه

يتم إنشاء قاعدة منفصلة لكل موقع أو تطبيق.

على سبيل المثال:

  • www.example.com إلى 10.10.10.11:80
  • app.example.com إلى 10.10.10.12:3000
  • erp.example.com إلى 10.10.10.13:8069
  • api.example.com إلى 10.10.10.14:8080

يجب التأكد من أن Reverse Proxy يستطيع الوصول إلى هذه العناوين عبر الشبكة الخاصة.

مثال على إعداد NGINX Reverse Proxy

يمكن إنشاء إعداد لنطاق تطبيق بالشكل التالي:

💡 اقرأ أيضاً: شرح NGINX Reverse Proxy وربط الدومين بتطبيقك عبر proxy_pass

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://10.10.10.12:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

يستقبل هذا الإعداد الطلبات الموجهة إلى app.example.com ثم يرسلها إلى التطبيق الذي يعمل على العنوان الخاص 10.10.10.12 والمنفذ 3000.

تمرير عنوان IP الحقيقي للزائر

من المهم تمرير عنوان IP الحقيقي إلى الخادم الخلفي بدلاً من ظهور عنوان Reverse Proxy في جميع السجلات.

تستخدم عادةً الترويسات التالية:

  • X-Real-IP
  • X-Forwarded-For
  • X-Forwarded-Proto
  • Host

بعد ذلك يجب إعداد التطبيق الخلفي ليثق بترويسات Reverse Proxy من المصدر الصحيح فقط.

يساعد ذلك في:

  • تسجيل عناوين الزوار.
  • تطبيق Rate Limiting.
  • تحليل السجلات.
  • اكتشاف محاولات الهجوم.
  • منع العناوين المشبوهة.

إدارة شهادات SSL من مكان واحد

من أهم فوائد Reverse Proxy إمكانية إدارة شهادات SSL لجميع المواقع من نقطة واحدة.

إدارة SSL من مكان واحد
شهادة واحدة لكل مواقعك

ويمكنك إصدار شهادات SSL مجانية عبر Let’s Encrypt وإدارتها مركزياً من الـ Reverse Proxy.

يمكن استخدام:

  • Let’s Encrypt.
  • شهادات SSL تجارية.
  • Wildcard SSL.
  • شهادات Origin عند استخدام CDN.

يقوم Reverse Proxy بإنهاء اتصال HTTPS، ثم يرسل الطلب إلى الخادم الخلفي.

يمكن أن يكون الاتصال الداخلي:

  • HTTP داخل شبكة موثوقة ومعزولة.
  • HTTPS أيضاً للحصول على تشفير كامل بين جميع الطبقات.

في البيئات الحساسة، يفضل استخدام HTTPS بين Reverse Proxy والخوادم الخلفية أيضاً.

SSL Termination

تعني SSL Termination أن Reverse Proxy يتولى:

  • استقبال اتصال HTTPS.
  • فك التشفير.
  • التحقق من الشهادة.
  • تمرير الطلب إلى التطبيق.

تساعد هذه الطريقة على تخفيف إدارة الشهادات داخل كل خادم، وتوحيد إعدادات التشفير والبروتوكولات الأمنية.

استخدام Wildcard SSL

إذا كانت جميع الخدمات تستخدم نطاقات فرعية من نطاق واحد، يمكن استخدام شهادة Wildcard مثل:

*.example.com

يمكن أن تغطي هذه الشهادة:

  • app.example.com
  • erp.example.com
  • api.example.com
  • panel.example.com

لكن يجب حماية المفتاح الخاص بالشهادة بعناية، لأن اختراقه قد يؤثر في جميع النطاقات المغطاة.

نشر التطبيقات خلف Reverse Proxy

يعتبر تشغيل Odoo خلف NGINX Reverse Proxy من التصاميم الشائعة في بيئات ERP.

انشر تطبيقاتك خلف Reverse Proxy
WordPress وOdoo وLaravel وDocker

💡 اقرأ أيضاً: استضافة Odoo وERP على مرام بلاتفورم: بنية آمنة قابلة للتوسّع

يمكن أن يعمل Odoo داخل شبكة خاصة على المنفذ 8069، بينما يستقبل Reverse Proxy الاتصالات العامة عبر HTTPS.

يتيح ذلك:

  • استخدام اسم نطاق احترافي.
  • إصدار شهادة SSL.
  • إخفاء منفذ Odoo الداخلي.
  • حماية خادم Odoo من الوصول المباشر.
  • إضافة Rate Limiting.
  • إدارة WebSocket وLong Polling.
  • تشغيل أكثر من بيئة Odoo.

يمكن مثلاً نشر:

  • erp.example.com لبيئة Production.
  • staging-erp.example.com لبيئة Staging.
  • dev-erp.example.com لبيئة Development.

نشر WordPress ومتاجر WooCommerce

يمكن وضع خادم WordPress داخل شبكة خاصة ونشره من خلال Reverse Proxy.

يستفيد WordPress من:

  • إدارة SSL مركزياً.
  • الكاش.
  • ضغط المحتوى.
  • حجب الطلبات المشبوهة.
  • دمج CDN.
  • إخفاء عنوان خادم الويب الأصلي.

لكن يجب ضبط إعدادات WordPress حتى يتعرف بصورة صحيحة على بروتوكول HTTPS خلف Reverse Proxy.

نشر تطبيقات Laravel

يمكن تشغيل تطبيق Laravel على خادم مستقل خلف NGINX أو Apache، ثم نشره عبر Reverse Proxy.

يساعد ذلك على فصل:

  • طبقة الدخول العامة.
  • خادم التطبيق.
  • Redis.
  • Queue Workers.
  • قاعدة البيانات.

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

نشر تطبيقات Node.js

تعمل تطبيقات Node.js غالباً على منافذ مثل:

  • 3000
  • 4000
  • 8080

بدلاً من فتح هذه المنافذ للعامة، يمكن إبقاؤها داخل الشبكة الخاصة، وتوجيه النطاق إليها عبر Reverse Proxy.

يجب تفعيل دعم WebSocket إذا كان التطبيق يستخدم:

  • Socket.IO.
  • لوحات مباشرة.
  • إشعارات فورية.
  • تطبيقات محادثة.
  • بث بيانات لحظي.

نشر تطبيقات ASP.NET

يمكن تشغيل تطبيق ASP.NET Core باستخدام Kestrel خلف Reverse Proxy.

يتولى Reverse Proxy:

  • HTTPS.
  • اسم النطاق.
  • إعادة التوجيه.
  • ترويسات الاتصال.
  • الحماية الأساسية.
  • توزيع الحمل عند تشغيل أكثر من نسخة.

نشر عدة تطبيقات Docker

يمكن تشغيل كل تطبيق داخل Container مستقل، ثم نشره عبر:

  • NGINX Proxy Manager.
  • Traefik.
  • Caddy.
  • NGINX.

تعتبر هذه الطريقة مناسبة لمنصات SaaS وبيئات التطوير التي تحتوي على عدد كبير من الخدمات.

استخدام Reverse Proxy مع Kubernetes

في بيئات Kubernetes، يستخدم عادةً Ingress Controller لتنفيذ وظيفة مشابهة للـ Reverse Proxy.

يمكن استخدام:

  • NGINX Ingress Controller.
  • Traefik.
  • HAProxy Ingress.
  • Envoy.

يتم توجيه النطاقات والمسارات إلى Kubernetes Services المناسبة.

التوجيه حسب النطاق والمسار

يعد التوجيه حسب Hostname الطريقة الأكثر شيوعاً.

التوجيه حسب النطاق والمسار
وجّه كل نطاق لخادمه

مثلاً:

  • site1.example.com إلى الخادم الأول.
  • site2.example.com إلى الخادم الثاني.
  • erp.example.com إلى خادم ERP.

هذه الطريقة تسمح بنشر عدد كبير من الخدمات باستخدام عنوان IP واحد.

التوجيه حسب المسار

يمكن أيضاً نشر عدة خدمات ضمن النطاق نفسه باستخدام المسارات.

مثلاً:

  • example.com/app إلى تطبيق معين.
  • example.com/api إلى خادم API.
  • example.com/docs إلى خادم التوثيق.

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

موازنة التحميل والتوافر

لا يقتصر دور Reverse Proxy على توجيه كل نطاق إلى خادم واحد، بل يمكنه توزيع الطلبات بين عدة خوادم.

على سبيل المثال، يمكن توزيع زوار متجر إلكتروني على:

  • Web Server 1.
  • Web Server 2.
  • Web Server 3.

يؤدي ذلك إلى:

  • رفع القدرة الاستيعابية.
  • تحسين الأداء.
  • تقليل تأثير تعطل خادم واحد.
  • دعم التوسع الأفقي.

Health Checks

تسمح بعض حلول Reverse Proxy بفحص حالة الخوادم الخلفية دورياً.

إذا توقف أحد الخوادم، يتم إيقاف إرسال الطلبات إليه وتوجيهها إلى خادم آخر سليم.

تعتبر هذه الميزة مهمة في:

  • التطبيقات عالية التوفر.
  • المتاجر الكبيرة.
  • الخدمات التي تعمل على مدار الساعة.
  • منصات SaaS.
  • أنظمة ERP متعددة المستخدمين.

Session Persistence

تحتاج بعض التطبيقات إلى بقاء المستخدم متصلاً بالخادم الخلفي نفسه طوال الجلسة.

يمكن استخدام:

  • Sticky Sessions.
  • Cookies.
  • Source IP Hash.

لكن التصميم الأفضل غالباً هو جعل التطبيق Stateless وتخزين الجلسات في نظام مشترك مثل Redis.

حماية الخوادم الخلفية

يجب ألا تسمح قواعد Firewall بالوصول إلى الخوادم الخلفية من الإنترنت مباشرة.

Reverse Proxy يحمي خوادمك الخلفية
إخفاء وحماية وتحديد معدّل

يفضل السماح بالاتصالات الواردة إليها فقط من:

  • عنوان Reverse Proxy الداخلي.
  • شبكة الإدارة.
  • خادم Monitoring.
  • خادم Backup.
  • VPN الإدارة.

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

دمج Reverse Proxy مع Firewall

يمكن وضع Reverse Proxy خلف:

💡 اقرأ أيضاً: كيفية إنشاء Firewall خاص داخل مرام بلاتفورم بـ OPNsense/pfSense

  • OPNsense.
  • pfSense.
  • MikroTik CHR.
  • Firewall خارجي.
  • Proxmox Firewall.

يقوم Firewall بالسماح فقط بالمنافذ المطلوبة، وعادةً:

  • TCP 80.
  • TCP 443.
  • منفذ VPN عند الحاجة.

أما منافذ التطبيقات الداخلية فلا يتم فتحها للعامة.

استخدام Web Application Firewall

يمكن إضافة WAF أمام التطبيقات لحماية طبقة الويب من أنواع شائعة من الهجمات.

يمكن أن يساعد في تقليل مخاطر:

  • SQL Injection.
  • Cross-Site Scripting.
  • محاولات استغلال الثغرات.
  • الطلبات الآلية الضارة.
  • بعض عمليات المسح والهجوم.

من الخيارات الممكنة:

  • ModSecurity.
  • Coraza.
  • حلول WAF سحابية.
  • Cloudflare WAF.
  • إضافات أمنية متوافقة مع NGINX.

يجب إعداد قواعد WAF بعناية لتجنب منع الطلبات الشرعية.

Rate Limiting

يساعد Rate Limiting على تحديد عدد الطلبات المسموح بها خلال فترة معينة.

يمكن استخدامه لحماية:

  • صفحات تسجيل الدخول.
  • واجهات API.
  • لوحات الإدارة.
  • نماذج الاتصال.
  • خدمات إرسال الرموز.
  • نقاط المصادقة.

يقلل ذلك من تأثير:

  • Brute Force.
  • Abuse.
  • Bots.
  • الطلبات المتكررة.
  • بعض هجمات حجب الخدمة البسيطة.

إخفاء الخادم الأصلي

عندما يتم توجيه النطاق إلى Reverse Proxy فقط، يمكن إخفاء عنوان IP الخاص بخادم التطبيق.

لكن يجب التأكد من عدم تسريب عنوان الخادم الأصلي عبر:

  • سجلات DNS قديمة.
  • نطاقات فرعية منسية.
  • رسائل البريد الصادرة.
  • إعدادات التطبيق.
  • شهادات أو خدمات أخرى.
  • فتح منافذ الإدارة للعامة.

التكامل مع CDN وتحسين الأداء

يمكن وضع CDN أمام Reverse Proxy للحصول على طبقة إضافية من الأداء والحماية.

💡 اقرأ أيضاً: الفرق بين CDN وReverse Proxy: متى تستخدم كل منهما؟

يصبح المسار:

المستخدم ← CDN ← Reverse Proxy ← Application Server

يقدم هذا التصميم:

  • تخزيناً مؤقتاً للمحتوى.
  • توزيعاً عالمياً.
  • تقليل الضغط على الخوادم.
  • حماية إضافية من الهجمات.
  • تحسين زمن تحميل الملفات الثابتة.

تحسين الأداء باستخدام Cache

يمكن إعداد Reverse Proxy لتخزين بعض الاستجابات مؤقتاً بدلاً من إرسال كل طلب إلى الخادم الخلفي.

يناسب ذلك:

  • الصفحات العامة.
  • الصور.
  • ملفات CSS.
  • JavaScript.
  • ملفات التنزيل.
  • بعض استجابات API غير المتغيرة.

لكن لا ينبغي تطبيق الكاش على:

  • صفحات المستخدمين.
  • لوحات التحكم.
  • سلة التسوق.
  • الصفحات المصرفية.
  • البيانات الشخصية.
  • المحتوى المتغير لكل جلسة.

ضغط المحتوى

يمكن تفعيل:

  • Gzip.
  • Brotli.

لتقليل حجم الملفات المنقولة وتحسين سرعة تحميل المواقع، خاصة ملفات:

  • HTML.
  • CSS.
  • JavaScript.
  • JSON.
  • XML.

السجلات والمراقبة والنسخ

يجب الاحتفاظ بسجلات Reverse Proxy، لأنها تساعد على تحليل:

  • عناوين الزوار.
  • الطلبات.
  • الأخطاء.
  • أوقات الاستجابة.
  • الخوادم الخلفية.
  • الهجمات المحتملة.
  • حجم الترافيك.

يمكن إرسال السجلات إلى نظام مركزي مثل:

  • Grafana Loki.
  • Elasticsearch.
  • Graylog.
  • Wazuh.
  • SIEM.

مراقبة Reverse Proxy

من المهم مراقبة:

  • CPU.
  • RAM.
  • استهلاك الشبكة.
  • الاتصالات النشطة.
  • عدد الطلبات.
  • أخطاء 4xx و5xx.
  • مدة الاستجابة.
  • حالة الخوادم الخلفية.
  • صلاحية شهادات SSL.

يمكن استخدام:

  • Prometheus.
  • Grafana.
  • Zabbix.
  • Netdata.
  • Uptime Kuma.

النسخ الاحتياطي لإعدادات Reverse Proxy

يجب الاحتفاظ بنسخ احتياطية من:

  • ملفات إعداد NGINX.
  • قاعدة بيانات NGINX Proxy Manager.
  • شهادات SSL.
  • مفاتيح التشفير.
  • إعدادات Traefik.
  • ملفات Docker Compose.
  • قوائم الوصول.
  • قواعد التوجيه.

يمكن حماية الآلة الافتراضية كاملة باستخدام Proxmox Backup Server داخل مرام بلاتفورم.

التوافر العالي وتوزيع الموارد

إذا كان Reverse Proxy الوحيد متوقفاً، فقد تتوقف جميع المواقع المنشورة من خلاله حتى لو كانت الخوادم الخلفية تعمل.

في البيئات الحساسة، يمكن تشغيل:

  • Reverse Proxy رئيسي.
  • Reverse Proxy احتياطي.
  • عنوان IP افتراضي.
  • Health Checks.
  • Failover تلقائي.

يمكن تنفيذ ذلك باستخدام تقنيات مثل:

  • Keepalived.
  • VRRP.
  • HAProxy.
  • CARP عند استخدام pfSense أو OPNsense.
  • Load Balancer خارجي.

مخاطر الاعتماد على Reverse Proxy واحد

رغم المزايا الكبيرة، فإن خادم Reverse Proxy واحد قد يصبح نقطة فشل مركزية.

لذلك يجب:

  • مراقبته باستمرار.
  • إنشاء Backup دوري.
  • تحديثه أمنياً.
  • تخصيص موارد مناسبة له.
  • إعداد نسخة احتياطية في المشاريع المهمة.
  • توثيق إعداداته.
  • اختبار الاستعادة.

توزيع الموارد لخادم Reverse Proxy

يعتمد استهلاك الموارد على:

  • عدد المواقع.
  • حجم الترافيك.
  • عدد الاتصالات المتزامنة.
  • تشفير SSL.
  • استخدام Cache.
  • ضغط Brotli.
  • تشغيل WAF.
  • حفظ السجلات.
  • استخدام Load Balancing.

يمكن البدء بموارد متوسطة ثم مراقبتها وتوسيعها عند الحاجة.

ميزة مرام بلاتفورم أنها تسمح بزيادة:

  • CPU.
  • RAM.
  • مساحة NVMe.

بحسب نمو المشروع.

Reverse Proxy حسب نوع النشاط

يمكن لشركات البرمجيات ومزودي الخدمات نشر تطبيقات عدة عملاء من خلال عنوان IP واحد.

مثلاً:

  • client1.example.com
  • client2.example.com
  • client3.example.com

يمكن توجيه كل نطاق إلى:

  • VM مستقلة.
  • Container مستقل.
  • تطبيق مختلف.
  • قاعدة بيانات منفصلة.

لكن يجب تطبيق عزل قوي بين العملاء على مستوى الشبكة والتطبيق وقواعد البيانات.

Reverse Proxy في بيئة SaaS

تحتاج منصات SaaS إلى نقطة دخول مركزية لإدارة التطبيقات والعملاء.

يمكن استخدام Reverse Proxy من أجل:

  • توجيه نطاق كل عميل.
  • إدارة SSL.
  • نشر API.
  • توجيه لوحة الإدارة.
  • تطبيق Rate Limiting.
  • توزيع الحمل.
  • إضافة خدمات جديدة دون تغيير عنوان IP.

Reverse Proxy لأنظمة ERP

يمكن نشر عدة أنظمة ERP داخل المنصة مثل:

  • Odoo.
  • ERPNext.
  • Dolibarr.
  • تطبيق ERP مخصص.

ويكون لكل نظام نطاق مستقل، بينما تبقى قواعد البيانات داخل شبكة خاصة غير متاحة للعامة.

Reverse Proxy لبيئات Development وStaging وProduction

يمكن تخصيص نطاق لكل بيئة:

💡 اقرأ أيضاً: كيف تبني بيئة تطوير وStaging وProduction داخل Proxmox؟

  • dev.example.com
  • staging.example.com
  • example.com

يفضل حماية Development وStaging باستخدام:

  • VPN.
  • Basic Authentication.
  • IP Allowlist.
  • Access Lists.
  • Identity-Aware Proxy.

لا ينبغي ترك بيئات الاختبار مفتوحة للعامة دون حماية.

استخدام عنوان IP واحد مع عدة خوادم Windows وLinux

لا يهم نظام التشغيل الموجود خلف Reverse Proxy، ما دام التطبيق يقدم خدمة HTTP أو HTTPS يمكن الوصول إليها من الخادم الوسيط.

يمكن توجيه الطلبات إلى:

  • Ubuntu.
  • Debian.
  • AlmaLinux.
  • Windows Server.
  • Docker Containers.
  • Kubernetes Services.

وهذا يمنح الشركات حرية اختيار النظام المناسب لكل تطبيق.

إدارة المنافذ الداخلية

يمكن أن يعمل كل تطبيق على منفذ مختلف داخل الشبكة الخاصة، مثل:

  • 3000 لتطبيق Node.js.
  • 8000 لتطبيق Django.
  • 8069 لخادم Odoo.
  • 8080 لخدمة Java.
  • 5000 لتطبيق ASP.NET.
  • 80 أو 443 لخادم ويب مستقل.

لا يحتاج المستخدم إلى معرفة هذه المنافذ، لأن Reverse Proxy يعرض جميع الخدمات عبر HTTPS على المنفذ 443.

أفضل الممارسات وأخطاء شائعة

لإنشاء Reverse Proxy آمن، ينصح باتباع الممارسات التالية:

  • تحديث النظام والبرنامج باستمرار.
  • فتح المنفذين 80 و443 فقط عند الحاجة.
  • حماية لوحة الإدارة عبر VPN أو IP Allowlist.
  • تعطيل الوصول المباشر إلى الخوادم الخلفية.
  • استخدام شهادات SSL موثوقة.
  • تعطيل البروتوكولات وخوارزميات التشفير القديمة.
  • تفعيل Rate Limiting.
  • مراقبة السجلات.
  • إنشاء نسخ احتياطية دورية.
  • استخدام كلمات مرور قوية و2FA إذا كانت الأداة تدعمها.
  • عدم تثبيت خدمات غير ضرورية على خادم Reverse Proxy.
  • فصل شبكة الإدارة عن شبكة التطبيقات.
  • اختبار الإعدادات قبل تطبيقها على Production.

أخطاء شائعة يجب تجنبها

من أبرز الأخطاء:

  • فتح جميع منافذ الخوادم الخلفية للعامة.
  • استخدام HTTP فقط للمواقع الحساسة.
  • عدم تمرير عنوان IP الحقيقي.
  • عدم تفعيل WebSocket للتطبيقات التي تحتاج إليه.
  • استخدام شهادة SSL منتهية.
  • تشغيل لوحة NGINX Proxy Manager على الإنترنت دون حماية.
  • الاعتماد على Reverse Proxy واحد دون Backup.
  • عدم مراقبة أخطاء 502 و504.
  • توجيه الطلبات إلى منفذ أو عنوان IP خاطئ.
  • عدم ضبط Timeout للتطبيقات طويلة التنفيذ.
  • تفعيل Cache على صفحات المستخدمين الحساسة.
  • عدم تحديد حجم رفع الملفات.

معالجة أخطاء Gateway (502 و504)

يظهر الخطأ 502 غالباً عندما لا يستطيع Reverse Proxy الاتصال بالخادم الخلفي.

يجب التحقق من:

  • تشغيل التطبيق.
  • صحة عنوان IP.
  • صحة المنفذ.
  • قواعد Firewall.
  • استماع التطبيق على الواجهة المناسبة.
  • اتصال الشبكة الخاصة.
  • صحة بروتوكول HTTP أو HTTPS المستخدم.

معالجة خطأ 504 Gateway Timeout

يظهر الخطأ 504 عندما يتأخر الخادم الخلفي في الرد.

قد يكون السبب:

  • استعلام قاعدة بيانات بطيء.
  • نقص CPU أو RAM.
  • توقف التطبيق.
  • Timeout منخفض.
  • ضغط كبير.
  • مشكلة اتصال بالشبكة.

يجب معالجة السبب الأساسي بدلاً من رفع Timeout فقط دون تحليل.

قابلية التوسّع والانتقال إلى Dedicated

مع نمو التطبيقات، يمكن توسيع البنية من خادم Reverse Proxy واحد وتطبيق واحد إلى تصميم متقدم يحتوي على:

  • عدة Reverse Proxies.
  • عدة Application Servers.
  • Load Balancing.
  • قاعدة بيانات منفصلة.
  • Redis.
  • Monitoring.
  • Proxmox Backup Server.
  • Firewall خاص.
  • شبكة VLAN مستقلة.
  • بيئات Development وStaging وProduction.

تسمح مرام بلاتفورم بزيادة الموارد وإنشاء خوادم إضافية مع المحافظة على نفس تصميم الشبكات وعناوين IP.

الانتقال مستقبلاً إلى Dedicated Server

يمكن للشركة أن تبدأ بتشغيل Reverse Proxy والخوادم الخلفية داخل مرام بلاتفورم، ثم تنتقل مستقبلاً إلى خوادم Dedicated عند ارتفاع عدد المستخدمين أو الترافيك.

يمكن المحافظة على التصميم نفسه الذي يشمل:

  • الشبكات الخاصة.
  • VLAN.
  • أسماء النطاقات.
  • قواعد التوجيه.
  • VPN.
  • Firewall.
  • عناوين IP بحسب تصميم الخدمة.

يساعد ذلك على التوسع دون إعادة بناء المشروع من البداية.

لماذا تعتبر مرام بلاتفورم مناسبة لبناء Reverse Proxy؟

تتيح مرام بلاتفورم للشركات إنشاء بنية تحتية خاصة تعتمد على Proxmox، مع إمكانية تشغيل عدة خوادم افتراضية وتوزيعها على شبكات خاصة مستقلة.

💡 اقرأ أيضاً: كيف تبني مركز بيانات افتراضي خاص لشركتك؟

يمكنك من خلال المنصة إنشاء:

  • Reverse Proxy باستخدام NGINX أو HAProxy أو Traefik.
  • خوادم Linux وWindows.
  • خوادم Odoo وERP.
  • تطبيقات Docker.
  • قواعد بيانات منفصلة.
  • Firewall باستخدام OPNsense أو pfSense.
  • شبكة WireGuard خاصة.
  • خادم Monitoring.
  • Proxmox Backup Server.

وبدلاً من شراء عنوان IP عام لكل خادم، يمكن نشر عدة مواقع وتطبيقات باستخدام عنوان IP واحد، مع إبقاء الخوادم الخلفية داخل شبكة خاصة أكثر أماناً.

الخلاصة

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

من خلال حلول مثل NGINX وNGINX Proxy Manager وHAProxy وTraefik، تستطيع الشركات إدارة شهادات SSL، وحماية الخوادم الأصلية، وتطبيق Rate Limiting، ودعم WebSocket، وتوزيع الحمل، ومراقبة جميع الاتصالات من نقطة مركزية واحدة.

توفر مرام بلاتفورم بيئة مناسبة لبناء هذا التصميم داخل منصة Proxmox خاصة، حيث يمكن إنشاء Reverse Proxy وربطه بخوادم المواقع وقواعد البيانات وأنظمة Odoo وERP وتطبيقات Docker، مع إضافة Firewall وVPN وProxmox Backup Server عند الحاجة.

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

هل تبحث عن استضافة موثوقة لموقعك؟

شركة مرام هوست تقدم أفضل حلول الاستضافة والسيرفرات بدعم فني عربي 24/7

اكتشف خدماتنا ←