خطوات إعداد خادم ويب Nginx وضبط التوجيه العكسي (Reverse Proxy) من الصفر

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

في هذا الدليل نشرح خطوات إعداد خادم ويب Nginx وضبط Reverse Proxy من الصفر على خادم Linux نموذجي، بدايةً من التثبيت وفتح الجدار الناري، مروراً بإنشاء Server Block وربط النطاق، وصولاً إلى تمرير الطلبات إلى التطبيق وإضافة HTTPS واختبار الإعدادات بطريقة آمنة.

ما هو Nginx؟

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

في سيناريو Reverse Proxy يستقبل Nginx الطلب على المنافذ المعتادة للويب ثم يمرره إلى تطبيق خلفي مثل تطبيق Node.js أو Python أو خدمة أخرى تعمل على عنوان ومنفذ داخليين.

ما هو Reverse Proxy؟

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

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

مثال على البنية التي سنستخدمها

لنفترض أن لديك تطبيق ويب يعمل محلياً على الخادم عند:

127.0.0.1:3000

ونريد أن يصل الزوار إليه عبر:

https://example.com

سيستقبل Nginx الاتصال العام ثم يمرر الطلب داخلياً إلى التطبيق على المنفذ 3000. استبدل example.com ونقاط الاتصال بالقيم الحقيقية في بيئتك.

الخطوة الأولى: تحديث الحزم

على توزيعات Ubuntu أو Debian يمكن تحديث فهرس الحزم ثم تثبيت التحديثات المناسبة وفق سياسة الخادم:

sudo apt update
sudo apt upgrade

في بيئة إنتاجية، راجع تأثير التحديثات قبل تطبيقها واحتفظ بنسخة احتياطية وخطة استرجاع عند إجراء تغييرات مهمة.

الخطوة الثانية: تثبيت Nginx

يمكن تثبيت Nginx من مستودعات النظام:

sudo apt install nginx

ثم تحقق من حالة الخدمة:

sudo systemctl status nginx

ويمكن ضبط الخدمة لتبدأ تلقائياً مع تشغيل النظام إذا لم تكن مفعلة:

sudo systemctl enable nginx

الخطوة الثالثة: التحقق من عمل الخادم

بعد التثبيت، يمكنك التحقق محلياً من استجابة Nginx:

curl -I http://127.0.0.1

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

الخطوة الرابعة: ضبط الجدار الناري

إذا كنت تستخدم UFW، اعرض التطبيقات المتاحة أولاً:

sudo ufw app list

ثم اسمح فقط بالخدمات التي تحتاجها. لخادم ويب يستخدم HTTP وHTTPS يمكن أن يتوفر ملف تعريف Nginx مناسب في UFW:

sudo ufw allow 'Nginx Full'

تحقق من الحالة بعد التعديل:

sudo ufw status

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

الخطوة الخامسة: إعداد DNS للنطاق

قبل تفعيل HTTPS يجب أن يشير اسم النطاق إلى الخادم بصورة صحيحة. عادةً يُستخدم سجل A لربط اسم النطاق بعنوان IPv4، وقد يستخدم سجل AAAA عند تشغيل IPv6.

تحقق من أن DNS أصبح يشير إلى عنوان الخادم الصحيح قبل متابعة إصدار شهادة TLS. انتشار التغييرات يعتمد على إعدادات DNS والتخزين المؤقت.

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

قبل إعداد Reverse Proxy، تأكد أن التطبيق نفسه يستجيب محلياً:

curl http://127.0.0.1:3000

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

لماذا يفضل ربط التطبيق بـ 127.0.0.1؟

إذا كان التطبيق لا يحتاج إلى استقبال اتصالات مباشرة من الإنترنت، فإن جعله يستمع على Loopback فقط يقلل تعرض منفذه الخلفي. يتصل Nginx به محلياً بينما يبقى المنفذ غير متاح مباشرة من واجهة الشبكة العامة.

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

الخطوة السابعة: إنشاء Server Block

على Ubuntu وDebian يُستخدم غالباً مجلدا sites-available وsites-enabled. أنشئ ملفاً للنطاق:

sudo nano /etc/nginx/sites-available/example.com

وأضف إعداداً أساسياً مثل:

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1: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_pass؟

التوجيه:

proxy_pass http://127.0.0.1:3000;

يخبر Nginx بتمرير الطلبات التي تطابق location / إلى التطبيق الخلفي. يجب أن يكون العنوان والمنفذ قابلين للوصول من Nginx.

لماذا نمرر Host وX-Forwarded-*؟

عندما يعمل التطبيق خلف Proxy، قد يحتاج إلى معرفة اسم المضيف الأصلي وعنوان العميل وبروتوكول الطلب الخارجي. تساعد ترويسات مثل Host وX-Forwarded-For وX-Forwarded-Proto في تمرير هذه المعلومات.

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

الخطوة الثامنة: تفعيل الموقع

أنشئ رابطاً في sites-enabled:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

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

الخطوة التاسعة: اختبار إعداد Nginx

قبل إعادة التحميل استخدم دائماً:

sudo nginx -t

إذا أظهر الاختبار أن الصياغة صحيحة، أعد تحميل الإعدادات:

sudo systemctl reload nginx

اختبار الصياغة قبل Reload يقلل احتمال تعطيل الخدمة بسبب خطأ كتابي في ملف الإعداد.

اختبار Reverse Proxy

بعد التفعيل، افتح النطاق أو استخدم curl:

curl -I http://example.com

إذا استجاب Nginx لكن ظهر خطأ مثل 502 Bad Gateway، فغالباً يحتاج الاتصال بين Nginx والتطبيق الخلفي إلى مراجعة.

حل خطأ 502 Bad Gateway

ابدأ بالتحقق من التطبيق:

curl http://127.0.0.1:3000

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

راجع أيضاً سجلات Nginx، مثل سجل الأخطاء في المسار المستخدم على نظامك.

الخطوة العاشرة: إضافة HTTPS

لا يُنصح بتقديم تسجيلات الدخول أو البيانات الحساسة عبر HTTP فقط. استخدم شهادة TLS صالحة واضبط HTTPS للنطاق.

يمكن استخدام أدوات إدارة شهادات موثوقة مثل Certbot في البيئات المناسبة، لكن طريقة التثبيت تختلف باختلاف نظام التشغيل ومصدر الحزم. اتبع تعليمات الأداة الرسمية المتوافقة مع إصدار نظامك.

ما الذي يجب التحقق منه قبل إصدار شهادة؟

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

إعادة توجيه HTTP إلى HTTPS

بعد نجاح إعداد TLS يمكن تحويل زيارات HTTP إلى HTTPS. يمكن لأداة إدارة الشهادة إعداد ذلك في بعض الحالات، أو يمكن تكوين Server Block منفصل يعيد التوجيه.

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

تمرير WebSocket عبر Nginx

إذا كان تطبيقك يستخدم WebSocket، فقد تحتاج إلى إعداد ترويسات Upgrade المناسبة. مثال شائع:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

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

ضبط حجم الملفات المرفوعة

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

client_max_body_size 20M;

اختر القيمة وفق حاجة التطبيق ولا ترفع الحد بلا ضرورة. كما يجب أن تكون حدود التطبيق والبنية الخلفية متوافقة.

ضبط مهلات الاتصال

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

راقب التطبيق وحدد سبب البطء قبل تغيير القيم، ثم اضبط المهلات وفق طبيعة الخدمة.

تقديم الملفات الثابتة مباشرة

في بعض التطبيقات يمكن لـ Nginx تقديم ملفات CSS وJavaScript والصور مباشرة، ما يقلل الحمل على التطبيق الخلفي. يعتمد التنفيذ على بنية المشروع ومسارات الملفات.

احذر من تكوين مسار يسمح بالوصول إلى ملفات سرية مثل ملفات البيئة أو النسخ الاحتياطية أو ملفات الإعداد.

إخفاء الملفات الحساسة

لا تضع الأسرار داخل مجلد عام يمكن لخادم الويب تقديمه. ملفات مثل .env والنسخ الاحتياطية ومستودعات Git وقواعد البيانات المحلية يجب أن تبقى خارج Web Root أو تُحجب بقواعد مناسبة.

أفضل حماية هي تصميم بنية الملفات بحيث لا تكون الأسرار ضمن المسارات العامة أصلاً.

سجلات Nginx

تساعد Access Logs وError Logs في تشخيص الأخطاء ومراقبة الطلبات. على كثير من توزيعات Linux توجد السجلات ضمن:

/var/log/nginx/

راقب حجم السجلات وسياسة تدويرها، ولا تسجل بيانات حساسة دون حاجة. كما يجب حماية ملفات السجل من الوصول غير المصرح به.

تشغيل التطبيق كخدمة

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

مثال عام لفحص خدمة systemd:

sudo systemctl status myapp

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

Reverse Proxy لأكثر من تطبيق

يمكن لـ Nginx توجيه نطاقات مختلفة إلى خدمات خلفية مختلفة. مثلاً:

app.example.com  →  127.0.0.1:3000
api.example.com  →  127.0.0.1:4000

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

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

يمكن أيضاً توجيه مسارات مختلفة داخل النطاق نفسه إلى خدمات مختلفة، مثل توجيه /api/ إلى تطبيق API. لكن يجب فهم طريقة تعامل proxy_pass مع المسار والشرطة المائلة، لأن اختلافاً صغيراً في الصياغة قد يغير URI الذي يصل إلى الخادم الخلفي.

حماية الخادم الخلفي من الوصول المباشر

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

هذا لا يغني عن حماية التطبيق نفسه، لكنه يقلل مساحة التعرض.

تحديث Nginx والنظام

حافظ على تحديث Nginx ونظام التشغيل والمكتبات والتطبيق الخلفي. وجود Reverse Proxy لا يعالج ثغرات التطبيق أو النظام تلقائياً.

في خوادم الإنتاج، استخدم عملية تحديث منظمة تشمل نسخاً احتياطية واختبارات وخطة رجوع عند الحاجة.

نسخ إعدادات Nginx احتياطياً

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

بعد كل تعديل استخدم nginx -t قبل إعادة التحميل.

أخطاء شائعة عند إعداد Nginx Reverse Proxy

• كتابة عنوان أو منفذ خاطئ في proxy_pass.
• فتح منفذ التطبيق الخلفي للعامة دون حاجة.
• إعادة تحميل Nginx دون اختبار الإعداد.
• نسيان تمرير الترويسات التي يحتاجها التطبيق.
• الثقة العشوائية في X-Forwarded-For داخل التطبيق.
• فرض HTTPS قبل التأكد من أن الشهادة تعمل.
• ترك ملفات سرية داخل مجلد عام.
• تجاهل سجلات الأخطاء عند ظهور 502 أو 504.
• استخدام إعدادات TLS قديمة من شروحات غير محدثة.

خطة إعداد Nginx وReverse Proxy من الصفر

1. حدّث الخادم وثبّت Nginx من مصدر موثوق.
2. تحقق من تشغيل الخدمة.
3. اضبط الجدار الناري مع الحفاظ على منفذ الإدارة.
4. وجّه DNS إلى الخادم.
5. شغّل التطبيق الخلفي واختبره محلياً.
6. أنشئ Server Block للنطاق.
7. أضف proxy_pass والترويسات المطلوبة.
8. نفذ nginx -t ثم Reload.
9. اختبر الموقع عبر HTTP.
10. أضف شهادة TLS وHTTPS.
11. اختبر التجديد والسجلات والاتصال الخلفي.
12. راقب الخادم وحدّثه بصورة دورية.

أسئلة شائعة حول Nginx وReverse Proxy

هل Nginx خادم ويب أم Reverse Proxy؟

يمكنه أداء الوظيفتين، إضافة إلى وظائف أخرى. يمكنه تقديم ملفات مباشرة أو تمرير الطلبات إلى تطبيقات وخوادم خلفية.

لماذا يظهر 502 Bad Gateway؟

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

هل يجب فتح منفذ التطبيق 3000 على الإنترنت؟

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

هل Reverse Proxy يحمي التطبيق من جميع الهجمات؟

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

هل أحتاج إلى إعادة تشغيل Nginx بعد كل تعديل؟

في كثير من تغييرات الإعداد يكفي اختبار الصياغة ثم استخدام Reload لتطبيق الإعداد الجديد دون إيقاف الخدمة بالكامل، وفق طبيعة التغيير.

الخلاصة

يتيح إعداد Nginx كـ Reverse Proxy إنشاء نقطة دخول منظمة أمام تطبيقات الويب، وربط النطاقات بالخدمات الداخلية وإدارة HTTPS والترويسات والوصول بصورة مركزية.

ابدأ دائماً بالتأكد من أن التطبيق الخلفي يعمل، ثم أنشئ Server Block واضحاً، واختبر الإعداد باستخدام nginx -t قبل إعادة التحميل. وبعد نجاح HTTP أضف TLS، واحمِ المنافذ الداخلية والملفات الحساسة، وراقب السجلات والتحديثات للحفاظ على خادم مستقر وآمن.