Nginx Proxy Manager على خادم VPS: مراجعة ودليل إعداد

NPM مقابل Caddy مقابل Traefik: أي وكيل عكسي يناسب خادمك

تنقسم الأدوات الثلاث على أربعة محاور تحدد الاختيار: كيف تهيئها، وكيف تتعامل مع HTTPS، وكيف تتوسع مع عدد الخدمات، وكم تستهلك من RAM في حالة الخمول. إليك المقارنة.

أرقام RAM في حالة الخمول هي ملاحظات تقريبية من مقارنة واحدة لعام 2026، وليست متطلبات ثابتة. يختلف الاستخدام الفعلي باختلاف إصدار الصورة، والميزات المفعّلة، وحركة المرور، والتسجيل.

تنبع معايير الانتقال مباشرةً من ذلك الجدول. إذا كنت تريد لوحة تحكم وتشغّل حفنة من الخدمات التي لا تتغير كثيراً، فإن NPM هو الأداة المناسبة. أما إذا كنت تفضّل التهيئة ككود، أو تريد أصغر بصمة، أو تقدّر ما يوفره Caddy من توفير وتجديد HTTPS تلقائياً دون أي إعداد لـ ACME، فاستخدم Caddy. أنا شخصياً ألجأ إلى Caddy في عمليات النشر أحادية الموقع لأن التعامل مع SSL تلقائي وملف Caddyfile قصير. أما إذا كنت تضيف الحاويات أو تزيلها أو تعيد نشرها بشكل متكرر، فإن الاكتشاف التلقائي القائم على التسميات في Traefik يعني أنك تتوقف عن تسجيل كل مضيف جديد يدوياً.

هناك أيضاً Nginx المجرد مع Certbot، الذي يفضّله بعض المسؤولين للتحكم الدقيق أو للنشر خارج Docker. يمكن لـ Certbot أتمتة تجديد الشهادات، لكنك لا تزال تدير توجيه المضيفات الافتراضية وتهيئة Nginx بنفسك. إذا كان سببك الرئيسي للنظر في NPM هو تجنّب تهيئة الوكيل يدوياً، فمن غير المرجح أن يكون Nginx المجرد هو الأنسب.

ملاحظة واحدة حول الاختيار: تخلص مقارنة byte-guard إلى أن Caddy هو الخيار الأخف في تلك المقارنة، وبالنسبة إلى إعداد جديد أحادي المضيف لعام 2026 فهذا خيار معقول. يفوز Caddy بكونه أخف من NPM، لكن إذا كنت تريد واجهة رسومية تحديداً، فهو ليس أفضل خيار لك.

لمقارنة أعمق جنباً إلى جنب للمحركات الأساسية، راجع مقارنة Caddy مقابل Nginx على خادم VPS.

المتطلبات المسبقة: ما ستحتاجه

قبل النشر، جهّز هذه العناصر. القائمة قصيرة، لكن تخطي أي عنصر وستفشل خطوة الشهادة لاحقاً.

• خادم VPS مع تثبيت Docker وDocker Compose (نظام Ubuntu 22.04 LTS أو Debian 12 مناسب).
• اسم نطاق، مع سجل DNS A (وسجل AAAA إذا كنت تستخدم IPv6) يشير إلى عنوان IP العام لخادمك.
• وصول SSH إلى الخادم.
• المنفذان 80 و443 مفتوحان للإنترنت على جدار حمايتك.
• المنفذ 81 قابل للوصول من قِبَلك أنت فقط، وليس مفتوحاً للعموم (يتناوله قسم الأمان).

إعداد Nginx Proxy Manager على خادمك باستخدام Docker Compose

يقوم هذا القسم بنشر NPM باستخدام Docker Compose. بمجرد أن تُحلّل سجلات DNS الخاصة بك إلى الخادم، يصبح إعداد الحاوية نفسه سريعاً، رغم أن انتشار DNS وإصدار الشهادة قد يستغرقان وقتاً أطول.

يستخدم الإعداد ملف Docker Compose واحداً وأمراً لمرة واحدة لإنشاء شبكة Docker مشتركة. أنشئ دليلاً، وأنشئ الشبكة، وأضف docker-compose.yml الملف أدناه، وشغّل الحاوية.

أولاً، أنشئ شبكة Docker المشتركة:

docker network create proxy

ثم أنشئ الملف docker-compose.yml :

# docker-compose.yml
services:
  npm:
    image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
    restart: unless-stopped
    ports:
      - '80:80'                 # public HTTP
      - '443:443'               # public HTTPS
      - '127.0.0.1:81:81'       # admin UI, reachable only from the VPS itself
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
networks:
  proxy:
    external: true

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

انسخ احتياطياً كلاً من ./data و ./letsencrypt قبل الترقيات. يحتوي دليل البيانات على قاعدة بيانات NPM والتهيئة المولَّدة، بينما يحتوي دليل Let's Encrypt على مواد شهاداتها.

بعض الأمور حول هذا الملف. تعتمد الصورة افتراضياً على قاعدة بيانات SQLite مخزَّنة في ./data وحدة التخزين. هذه هي الخلفية الافتراضية وهي صحيحة لمعظم عمليات النشر على خادم واحد. إذا كنت بحاجة إلى قاعدة بيانات خارجية، فإن NPM يدعم MariaDB/MySQL وPostgreSQL، ما يعني إضافة خدمة قاعدة بيانات ومتغيرات البيئة المطابقة. بالنسبة إلى خادم واحد، لا يزال SQLite هو الافتراضي الأبسط ما لم يكن لديك سبب واضح لنقل قاعدة البيانات خارج وحدة تخزين البيانات. إن restart: unless-stopped السياسة تعني أن NPM يعود للعمل إذا أُعيد تشغيل الخادم، وهو ما تريده لخدمة تقع أمام كل شيء آخر.

شغّله وتأكّد من أنه يعمل:

docker compose up -d
docker compose ps

الناتج المتوقع: الحاوية npm بالحالة Up، والمنفذان 80 و443 معيَّنان علناً، والمنفذ 81 مرتبط فقط بـ 127.0.0.1. يستغرق أول تشغيل بضع دقائق بينما يولّد NPM مفتاح JWT، ويهيّئ قاعدة البيانات، وينشئ مستخدم المسؤول الافتراضي. إن وثائق الإعداد الرسمية تصف تسلسل التشغيل الأول هذا.

أنشئ نفق SSH من حاسوبك المحلي قبل فتح واجهة الإدارة:

ssh -L 8181:127.0.0.1:81 user@your-vps

ثم افتح http://127.0.0.1:8181 في متصفحك. في التثبيت الجديد، سجّل الدخول باستخدام [email protected] و changeme، ثم استبدل فوراً البريد الإلكتروني وكلمة المرور الافتراضيين. لا تجعل لوحة التحكم قابلة للوصول علناً بينما تكون بيانات الاعتماد الافتراضية نشطة.

بمجرد تغيير بيانات اعتماد المسؤول، أضف أول مضيف وكيل لك:

1. في لوحة التحكم، انتقل إلى Hosts، ثم Proxy Hosts، ثم Add Proxy Host.
2. اضبط Domain Name إلى نطاقك الفرعي (على سبيل المثال cloud.example.com).
3. عيّن Forward Hostname / IP إلى اسم حاوية الخلفية أو عنوان IP، و Forward Port إلى المنفذ الذي يستمع عليه.
4. احفظ. يظهر مضيف الوكيل في القائمة، وتصل الآن الحركة الموجهة إلى ذلك النطاق الفرعي إلى حاويتك.

إذا كنت تشغّل واجهة إدارة Docker إلى جانب هذا، فينطبق النمط نفسه: وجّه نطاقاً فرعياً إلى أداة إدارة الحاويات بالطريقة نفسها، وافعل الشيء نفسه مع أي مكدّس مراقبة Prometheus وGrafana تريد أن يقع خلف الوكيل.

تهيئة HTTPS التلقائي لنطاق فرعي

يوفّر لك هذا القسم شهادة Let's Encrypt صالحة وتتجدد تلقائياً لنطاقك الفرعي. المتطلب الأساسي هو الذي يوقع الناس في الخطأ: يجب أن يكون سجل DNS A لذلك النطاق الفرعي مشيراً بالفعل إلى خادمك، ويجب أن يكون المنفذ 80 قابلاً للوصول من الإنترنت، لأن Let's Encrypt يتحقق من النطاق بالاتصال به مجدداً.

بعد إنشاء مضيف الوكيل، اطلب الشهادة:

1. حرّر مضيف الوكيل، افتح علامة التبويب SSL .
2. ضمن شهادة SSLاختر Request a new SSL Certificate.
3. تفعيل Force SSL و HTTP/2 Support. لا تُفعّل HSTS إلا بعد التأكد من أن HTTPS يعمل بشكل صحيح، لأن المتصفحات قد تخزّن السياسة مؤقتاً وتجعل التعافي من خطأ في الشهادة أو تهيئة الوكيل أكثر صعوبة.
4. وافق على شروط Let's Encrypt واحفظ.

افتراضياً، يستخدم NPM تحدي HTTP-01 للأسماء غير الشاملة (non-wildcard)، ويتحقق من كل اسم مضيف مطلوب عبر المنفذ 80. يمكن أن تحتوي الشهادة على عدة أسماء غير شاملة، لكن HTTP-01 لا يمكنه إصدار شهادات شاملة (wildcard). أما الأسماء الشاملة مثل *.example.com فتتطلب تحدي DNS-01 مع مزود DNS مدعوم. بالنسبة إلى إعداد عادي بنطاق فرعي واحد لكل خدمة، فإن HTTP-01 هو كل ما تحتاجه، والتجديدات تلقائية.

تحديد حجم خادمك من أجل Nginx Proxy Manager

NPM نفسه خفيف؛ ومسألة تحديد الحجم تتعلق حقاً بـ NPM مضافاً إليه الخدمات الواقعة خلفه. نادراً ما تكون بصمة الوكيل في حالة الخمول هي القيد. فنسخة Nextcloud أو مدونة Ghost ستستهلك موارد أكثر من الوكيل نفسه.

إليك كيف تعمل الفئات عملياً:

• الحد الأساسي العملي الأدنى: 1 GB RAM و1 vCPU و10 GB تخزين. مشاركة واحدة دليل تحديد الحجم من جهة خارجية يستخدم الحد الأساسي نفسه، لكن تعامل معه كإرشاد تخطيطي وليس كمتطلب رسمي من NPM. فهو كافٍ لـ NPM ونظام التشغيل وبضع خدمات خفيفة، لكنه يترك هامشاً محدوداً.
• مريح: 2 GB RAM و1 vCPU و20 GB تخزين. NPM مضافاً إليه ثلاث إلى خمس خدمات مع متسع للتنفس. هذه هي النقطة المثالية لمعظم المستضيفين الذاتيين.
• ترقية: 4 GB RAM و2 vCPU. لثماني إلى اثنتي عشرة خدمة، أو لإعداد بحركة مرور ذات شأن حيث تريد هامش CPU لإنهاء TLS.

الرقم الذي تحدد الحجم على أساسه هو مجموع التطبيقات المُوكَّلة، وليس NPM. اجمع بصمات RAM للخدمات التي تنوي تشغيلها، وأضف إليها العبء الصغير للوكيل في حالة الخمول، واختر الفئة الأعلى من ذلك مع هامش.

تحديد حجم الخادم هو الجزء السهل. أما تشغيل NPM فلا يزال يعني تجهيز الخادم، وتثبيت Docker، وسحب الصورة، والمرور بإعداد التشغيل الأول ذاك. إذا كنت تفضّل تخطي خطوات التجهيز، فإن سوق Cloudzy يوفّر نشر Nginx Proxy Manager بنقرة واحدة على خادم NVMe VPS. فهو يشغّل الحاوية على خادم جديد، فتذهب مباشرةً إلى لوحة التحكم وأول مضيف وكيل لك. في كلتا الحالتين، فإن فئات تحديد الحجم أعلاه هي ما تجهّز على أساسه.

الأسئلة الشائعة