لماذا تثبّت Nginx Proxy Manager على خادم VPS الخاص بك
بمجرد أن تستضيف عدة خدمات على خادم VPS (واجهة API، ولوحة إدارة، وPortainer، وn8n…)، عليك توجيه كل نطاق إلى الحاوية الصحيحة وإدارة شهادة SSL لكلٍ منها. القيام بذلك يدويًا بملفات تهيئة Nginx وCertbot أمر ممل ومَصدر للأخطاء. يحل Nginx Proxy Manager هذه المشكلة: من واجهة ويب، تنشئ «Proxy Host» بتحديد نطاق وهدف داخلي (IP:port)، ويولّد NPM تلقائيًا شهادة Let's Encrypt. كما يدير عمليات إعادة التوجيه، والترويسات المخصصة، وقوائم الوصول، وشهادات wildcard. على خلاف منصة PaaS، لا ينشر NPM التطبيقات: فهو لبنة بنية تحتية مخصصة لتوجيه HTTP/HTTPS، تُوضع في الوضع الأمثل أمام جميع حاوياتك الأخرى.
ما يقدّمه Nginx Proxy Manager
- إنشاء وكلاء عكسيين ببضع نقرات، دون تحرير ملف Nginx.
- شهادات Let's Encrypt تلقائية، بما في ذلك wildcard عبر تحدي DNS.
- إدارة مركزية لجميع نطاقاتك ونطاقاتك الفرعية من واجهة واحدة.
- قوائم الوصول (Access Lists) لحماية خدمة بكلمة مرور أو بعنوان IP.
- عمليات إعادة توجيه، ومضيفو 404، وترويسات مخصصة قابلة للتهيئة بصريًا.
- سجلّات الوصول والأخطاء قابلة للاطّلاع لكل مضيف، مفيدة لتصحيح الأخطاء.
متطلبات Nginx Proxy Manager
Nginx Proxy Manager خفيف جدًا: خادم VPS بذاكرة 1 غيغابايت من RAM ومعالج vCPU واحد يكفي بوفرة، لأن NPM لا يفعل سوى توجيه حركة المرور إلى حاوياتك الأخرى. خصّص 15 غيغابايت من قرص SSD للشهادات وقاعدة بيانات SQLite والسجلّات. يجب تثبيت Docker وDocker Compose. نقطة حاسمة: يجب أن يكون NPM الخدمة الوحيدة التي تستمع على المنفذين 80 و443 من خادم VPS، لأنه يعمل كنقطة دخول واحدة لكل حركة مرور الويب. يُستخدم المنفذ 81 لواجهة الإدارة ويجب ألا يُعرَّض أبدًا مباشرةً على الإنترنت. وجّه سجلّات DNS الخاصة بك (سجل A لكل نطاق، أو wildcard لتحدي DNS) إلى عنوان IP الخاص بخادم VPS قبل توليد الشهادات.
Nginx Proxy Manager في مواجهة Traefik
| المعيار | Nginx Proxy Manager | Traefik |
|---|---|---|
| التهيئة | واجهة ويب بصرية، لا ملف لتحريره | ملفات YAML وعلامات (labels) Docker |
| منحنى التعلّم | منخفض، متاح للمبتدئين | أكثر انحدارًا، موجَّه نحو DevOps |
| شهادات SSL من Let's Encrypt | تلقائية عبر الواجهة، wildcard ممكن | تلقائية عبر التهيئة |
| اكتشاف الخدمات | يدوي (إدخال IP:port) | تلقائي عبر علامات Docker |
| مثالي لـ | بضع خدمات تُدار يدويًا | بيئات ديناميكية وحاويات عديدة |
| استهلاك RAM | منخفض جدًا | منخفض |
| السجلّات لكل مضيف | قابلة للاطّلاع في الواجهة | عبر مكدّس سجلّات خارجي |
| إدارة الوصول | قوائم وصول (Access Lists) مدمجة (IP، كلمة مرور) | برمجيات وسيطة (middlewares) للتهيئة |
ثبّت Nginx Proxy Manager وأنشئ وكيلًا
جهّز docker-compose
على خادم VPS، أنشئ مجلدًا /opt/npm وملفًا docker-compose.yml يعلن الصورة jc21/nginx-proxy-manager:latest، مع تعيين المنافذ 80 و443 و81، وأحجام (volumes) لـ ./data و./letsencrypt.
شغّل الحاوية
نفّذ docker compose up -d. يبدأ NPM بقاعدة بيانات SQLite افتراضية. تصبح واجهة الإدارة متاحة على http://IP_DU_VPS:81.
سجّل الدخول وأمّن حساب المسؤول
سجّل الدخول ببيانات الاعتماد الافتراضية ([email protected] / changeme)، ثم غيّر فورًا البريد الإلكتروني وكلمة المرور. هذه خطوة أمنية غير قابلة للتفاوض قبل أي عرض على الإنترنت.
أنشئ Proxy Host
في «Proxy Hosts»، أضِف مضيفًا: النطاق app.mydomain.com، والهدف Forward Hostname (اسم الحاوية أو عنوان IP الداخلي) والمنفذ. فعّل «Block Common Exploits» ودعم WebSocket عند الحاجة.
فعّل SSL التلقائي
في علامة تبويب SSL الخاصة بـ Proxy Host، اختر «Request a new SSL Certificate»، واقبل شروط Let's Encrypt وفعّل «Force SSL». يحصل NPM على الشهادة ويثبّتها؛ أصبحت خدمتك الآن متاحة عبر HTTPS.
احمِ واجهة الإدارة
أغلِق المنفذ 81 في جدار الحماية وأنشئ Proxy Host مخصصًا للوصول إلى الإدارة عبر نطاق بـ HTTPS، محميًا بقائمة وصول (Access List). لا تترك أبدًا المنفذ 81 مفتوحًا على الإنترنت.
للحصول على شهادة wildcard *.mydomain.com وتغطية جميع نطاقاتك الفرعية دفعة واحدة، استخدم تحدي DNS: في علامة تبويب SSL، اختر مزوّد DNS الخاص بك وقدّم مفتاح API. ثم اربط جميع حاوياتك (Portainer وn8n وتطبيقاتك) بشبكة Docker نفسها التي يستخدمها NPM، بهدف استهداف كل خدمة باسم حاويتها بدلًا من عنوان IP: تبقى التهيئة مستقرة حتى لو تغيّرت العناوين الداخلية عند إعادة التشغيل.
