لماذا تحتاج إلى وكيل عكسي على خادم VPS
يكشف خادم VPS عن عنوان IP عام واحد فقط. خلف هذا العنوان، يمكنك تشغيل خمس أو عشر أو عشرين خدمة على منافذ داخلية مختلفة. بدون وكيل عكسي، يعني كشف كل خدمة على منفذ عام فتح تلك المنافذ في جدار الحماية، وإدارة شهادات TLS يدوياً لكل منها، وإعلام كل مستخدم بها. يحلّ الوكيل العكسي هذه المشكلات الثلاث دفعة واحدة: يستقبل كل حركة المرور على المنفذين 80 و443، ويحدد النطاق المطلوب، ويوجّه الطلب إلى الحاوية الداخلية الصحيحة. يضيف Nginx Proxy Manager طبقة واجهة رسومية إلى هذه الآلية: لا ملف تهيئة للكتابة، ولا إعادة تحميل يدوية، وتُدار شهادات Let's Encrypt ببضع نقرات. وهذا ملائم بشكل خاص للوكالات التي تستضيف تطبيقات عدة لعملاء على الخادم ذاته، أو للمطورين المستقلين الذين يشغّلون مشاريع متوازية.
NPM في مقابل إعداد Nginx اليدوي: 7 مزايا ملموسة
- لا ملفات تهيئة: يُنشأ كل proxy host من واجهة الويب، دون الحاجة إلى حفظ صياغة Nginx.
- شهادات Let's Encrypt تلقائية: يطلبها NPM ويثبّتها ويجدّدها دون تدخّل. الـ wildcard ممكن عبر DNS challenge.
- إدارة مركزية: جميع نطاقاتك ونطاقاتك الفرعية وعمليات إعادة التوجيه في شاشة واحدة، بدل عشرة ملفات في
/etc/nginx/sites-enabled/. - قوائم الوصول (Access Lists) المدمجة: احمِ خدمة بعنوان IP أو بكلمة مرور دون المساس بإعدادات كل تطبيق.
- سجلّات لكل مضيف قابلة للاطّلاع في الواجهة: اكشف خطأ 502 أو إساءة استخدام دون الاتصال بالحاوية.
- عمليات إعادة التوجيه من HTTP إلى HTTPS وصفحات 404 مخصصة قابلة للإعداد بصرياً.
- الاكتشاف باسم حاوية Docker: استهدف
portainer:9000بدلاً من عنوان IP داخلي غير ثابت يتغير عند إعادة التشغيل.
المتطلبات الأساسية قبل تثبيت NPM
لا يفعل NPM سوى توجيه حركة المرور، لذا فهو خفيف الوزن. يكفي خادم VPS بذاكرة 1 غيغابايت من RAM ومعالج vCPU واحد إذا كان NPM الخدمة الوحيدة الجوهرية. إن كنت تستضيف أيضاً التطبيقات خلفه، خصّص الموارد وفق مجموع احتياجاتها. احتجز 15 غيغابايت من قرص SSD (الشهادات وقاعدة بيانات SQLite والسجلّات). البرمجيات المطلوبة: Docker 24+ وإضافة Compose الإصدار 2 (docker compose وليس الأمر القديم docker-compose). الشبكة: يجب أن يكون المنفذان 80 و443 حرّين على خادم VPS — فـ NPM هو الشاغل الوحيد لهما. المنفذ 81 مخصص لواجهة الإدارة ويجب ألا يُكشف مباشرةً على الإنترنت. DNS: وجّه سجلاتك A إلى عنوان IP الخاص بخادم VPS قبل طلب الشهادات.
التثبيت والتهيئة الأولى لـ Nginx Proxy Manager
تثبيت Docker على خادم VPS
على خادم Debian/Ubuntu: curl -fsSL https://get.docker.com | sh. تحقق بعد ذلك: docker --version وdocker compose version. إن لم تكن إضافة Compose موجودة، ثبّت حزمة docker-compose-plugin عبر apt.
إنشاء مجلد العمل وملف Compose
أنشئ /opt/npm على خادم VPS. في هذا المجلد، أنشئ ملفاً باسم docker-compose.yml. أعلن فيه خدمة NPM بالصورة jc21/nginx-proxy-manager:latest، وعيّن المنافذ 80:80 و443:443 و81:81، وعرّف وحدتي تخزين: ./data:/data و./letsencrypt:/etc/letsencrypt.
تشغيل الحاوية
من /opt/npm، شغّل docker compose up -d. تحقق من أن الحاوية تعمل: docker compose ps. تصبح واجهة الإدارة متاحة على http://IP_DU_VPS:81 في غضون ثلاثين ثانية.
تسجيل الدخول لأول مرة وتأمين حساب المسؤول
سجّل الدخول ببيانات الاعتماد الافتراضية: البريد الإلكتروني [email protected]، وكلمة المرور changeme. يطلب NPM فوراً تغيير القيمتين. افعل ذلك قبل أي إجراء آخر: يمنح هذا الحساب وصولاً كاملاً إلى بنية التوجيه الخاصة بك.
إنشاء شبكة Docker مشتركة
كي يتمكن NPM من الوصول إلى حاويات التطبيقات بأسمائها، يجب أن تشترك في الشبكة ذاتها. أنشئ شبكة خارجية: docker network create proxy. في ملف docker-compose.yml الخاص بـ NPM، أعلن هذه الشبكة خارجية. كرّر الأمر في ملف Compose لكل تطبيق تريد توكيله.
إضافة أول Proxy Host
في الواجهة: Proxy Hosts ثم Add Proxy Host. أدخل النطاق (مثل app.your-domain.com) والمضيف الأمامي Forward Hostname (اسم الحاوية أو عنوان IP الداخلي) والمنفذ. ضع علامة على Block Common Exploits. إن استخدم التطبيق WebSockets، فعّل Websockets Support.
تفعيل SSL من Let's Encrypt
في تبويب SSL الخاص بـ Proxy Host، اختر Request a new SSL Certificate، واقبل شروط Let's Encrypt وفعّل Force SSL. يتصل NPM بخوادم ACME، ويتحقق من النطاق عبر HTTP-01 ويثبّت الشهادة. تصبح خدمتك على HTTPS في ثوانٍ، والتجديد تلقائي.
تأمين واجهة الإدارة (المنفذ 81)
أغلق المنفذ 81 في جدار الحماية (ufw deny 81). ثم أنشئ Proxy Host مخصصاً — مثل npm.your-domain.com نحو localhost:81 — مع SSL وقائمة وصول مقيّدة بعنوان IP الإداري. يمكنك بذلك الوصول إلى الواجهة عبر HTTPS دون كشف المنفذ 81 لبقية العالم.
شهادة wildcard عبر DNS challenge
لتغطية جميع نطاقاتك الفرعية بشهادة واحدة، استخدم DNS challenge. في تبويب SSL، اختر Use a DNS Challenge، وحدد مزوّدك (Cloudflare وOVH وغيرهما) وأدخل مفتاح API. يُنشئ NPM سجل TXT في منطقة DNS الخاصة بك، ويتحقق من ملكية النطاق، ويحصل على شهادة *.your-domain.com.
اختبار السلسلة الكاملة
من طرفية: curl -I https://app.your-domain.com. انتظر الرمز 200 أو رمز الاستجابة الخاص بتطبيقك. تحقق أيضاً من إعادة توجيه HTTP: curl -I http://app.your-domain.com يجب أن يُعيد 301 نحو النسخة HTTPS.
الإعداد المتقدم
يكشف NPM في واجهته عن عدة وظائف تتجاوز الوكالة العكسية البسيطة. تتيح قوائم الوصول (Access Lists) تقييد الوصول إلى مضيف بنطاق IP أو ببيانات اعتماد HTTP Basic Auth أو بمزيج من الاثنين — مفيد لحماية لوحة إدارية دون إضافة مصادقة في التطبيق نفسه. تُعالج Streams توجيه TCP/UDP للبروتوكولات غير HTTP (MySQL البعيد، وخوادم الألعاب، وMQTT...). تُنشئ قسم Redirections قواعد دائمة (301) أو مؤقتة (302) من نطاق أو مسار إلى رابط آخر، دون الحاجة إلى خدمة خلفه. تتيح تبويبات Advanced لكل proxy host حقن تهيئة Nginx خام حين لا تغطي الواجهة حالة بعينها.
التصليب: تحديد معدل الطلبات في تبويب Advanced
لا يعرض NPM شريط تمرير لتحديد المعدل في واجهته الأساسية، لكن يمكنك حقن توجيه Nginx في تبويب Advanced لـ proxy host المعني. أعلن منطقة مشتركة في التهيئة المخصصة: limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m; ثم طبّقها: limit_req zone=api burst=10 nodelay;. يُقيّد هذا كل عنوان IP بـ 30 طلباً في الدقيقة مع burst مقداره 10.
استكشاف الأخطاء الشائعة
إليك أكثر خمس مشكلات شيوعاً يواجهها المستخدمون بعد تثبيت NPM، مع تشخيص مباشر لكل منها.
الأخطاء الشائعة وأسبابها
- 502 Bad Gateway: لا يمكن لـ NPM الوصول إلى حاويتك. تحقق أولاً من أن الحاوية التطبيقية تعمل (
docker ps) وأنها على شبكة Docker ذاتها التي يستخدمها NPM (docker network inspect proxy). تحقق بعد ذلك من أنForward Hostnameيطابق تماماً اسم الخدمة المعلن في ملف Compose الخاص بالتطبيق. - شهادة SSL في انتظار أو خطأ ACME: يجب أن تتمكن Let's Encrypt من الوصول إلى خادمك عبر المنفذ 80 بالنطاق المعلن. تحقق من أن سجل DNS A يشير إلى عنوان IP الصحيح، وأن المنفذ 80 غير محجوب، وأن النطاق يُحلّ من الخارج (
dig app.your-domain.com). - الحاوية لا يمكن الوصول إليها عبر اسم DNS في Docker: إن استهدفت
myapp:3000وحصلت على خطأ تحليل، فإن حاويةmyappليست على الشبكة ذاتها التي يستخدمها NPM. أضف شبكةproxyفي ملف Compose الخاص بالتطبيق وأعد إنشاء الحاويات (docker compose up -d --force-recreate). - حلقة إعادة توجيه لا نهائية من HTTP إلى HTTPS: يحدث هذا حين يُجري التطبيق إعادة توجيه HTTPS بنفسه فوق إعادة توجيه NPM. أضف في تبويب Advanced:
proxy_set_header X-Forwarded-Proto $scheme;لكي يعرف التطبيق البروتوكول الفعلي. - واجهة الإدارة لا تعمل بعد إعادة التشغيل: تأكد من أن خدمة NPM تحمل التوجيه
restart: unless-stoppedفي ملف Compose الخاص بك. بدونه، لن يُعيد Docker تشغيل الحاوية بعد إعادة تشغيل خادم VPS.
Nginx Proxy Manager في مواجهة Traefik
| المعيار | Nginx Proxy Manager | Traefik |
|---|---|---|
| التهيئة | واجهة ويب بصرية، لا ملف لتحريره | ملفات YAML وعلامات Docker |
| منحنى التعلّم | منخفض، متاح دون خبرة Nginx | أكثر انحداراً، موجّه نحو DevOps |
| شهادات SSL من Let's Encrypt | تلقائية عبر الواجهة، wildcard ممكن | تلقائية عبر التهيئة |
| اكتشاف الخدمات | يدوي (اسم الحاوية أو IP:port) | تلقائي عبر علامات Docker |
| مثالي لـ | بضع خدمات تُدار يدوياً، إعداد واضح | بيئات ديناميكية مع حاويات كثيرة |
| استهلاك RAM | منخفض جداً | منخفض |
| السجلّات لكل مضيف | قابلة للاطّلاع في الواجهة | عبر مكدّس سجلّات خارجي |
| إدارة الوصول | قوائم وصول (Access Lists) مدمجة | برمجيات وسيطة للتهيئة |
متى تنتقل إلى Traefik أو Caddy
يناسب NPM تماماً مجموعة خدمات مستقرة يظل عددها قابلاً للإدارة. بمجرد أن تُدير عمليات نشر ديناميكية — حاويات تظهر وتختفي تلقائياً، كما في بيئات Kubernetes أو مع أنابيب CI/CD — يصبح Traefik أكثر ملاءمة. Caddy خيار جيد إن كنت تبحث عن بساطة التهيئة بملفات مع شهادات تلقائية، دون واجهة ويب. في جميع الأحوال، يمكن لـ NPM أن يتعايش مع Traefik أو Caddy على خادم VPS الواحد، بشرط ألا يشغل وكيلان المنفذين 80 و443 أنفسهما.
