وكيل Nginx العكسي مع SSL

إذا كنت تقوم بتشغيل تطبيق ويب على منفذ خاص (مثل LocalHost: 3000) ، لا يمكن الوصول إليها مباشرة عبر الإنترنت.واحدة من أكثر الطرق فعالية لفضح هذا التطبيق بشكل آمن هو وضع وكيل عكسي أمامه.

NGINX هي أداة معروفة خفيفة الوزن يمكنها القيام بذلك بالضبط-تلقي حركة المرور الواردة وإعادة توجيهها إلى تطبيقك-مع التعامل مع HTTPS مع شهادة SSL مجانية من Let's Encrypt.

في هذا الدليل ، ستتعلم كيفية:

• قم بإعداد NGINX كوكيل عكسي لخدمة ويب داخلية
  
• تأمينها مع شهادة SSL باستخدام certbot
  
• فهم كل جزء من التكوين حتى تعرف ما الذي تفعله ولماذا

جديد على خوادم الويب؟تحقق من شرحنا على كيف تعمل خوادم الويب.

ما هو الوكيل العكسي ، ولماذا استخدم واحدة؟

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

هذا هو السبب في أن هذا النهج مفيد للغاية:

• يخفي الموانئ والخدمات الداخلية
  لا يحتاج تطبيقك إلى التعرض مباشرة للجمهور.وهذا يقلل من سطح الهجوم ويساعدك على التحكم في الوصول.
  
• يتعامل مع HTTPS لك
  يمكن للعديد من أطر الويب أن تخدم HTTPS مباشرة ، ولكن غالبًا ما يكون من السهل وأكثر موثوقية السماح لـ Nginx بذلك - خاصة عند استخدام شهادات SSL المجانية من Let's Encrypt.
  
• يتيح استضافة خدمات متعددة على خادم واحد
  يمكنك تشغيل العديد من تطبيقات على منافذ مختلفة (مثل 3000 ، 4000 ، 5000) وحركة المرور على أساس المجال أو المسار باستخدام IP عام واحد فقط.
  
• يحسن التسجيل والمراقبة
  يمنحك Nginx سجلات الوصول والخطأ المركزية ، لذلك من الأسهل مراقبة الأداء أو التحقيق في المشكلات.
  
• يوفر التخزين المؤقت اختياريًا ، وموازنة التحميل ، والحد من المعدل
  يمكنك تحسين تدفق حركة المرور وحماية خدمات الواجهة الخلفية مع عدد قليل من الخطوط الإضافية في تكوين Nginx الخاص بك.

حتى إذا كان تطبيقك يمكنه بالفعل التعامل مع حركة مرور الويب ، فإن استخدام NGINX كوكيل عكسي غالباً ما يؤدي إلى تبسيط الإعداد ، ويحسن المرونة ، ويزيد من التحكم.

المتطلبات الأساسية

قبل أن نبدأ ، دعنا نتأكد من أن لديك كل ما تحتاجه:

• خادم VPS أو Cloud Cloud يقوم بتشغيل Ubuntu 20.04 أو لاحقًا: تفترض معظم الأوامر وإصدارات الحزمة المستخدمة في هذا البرنامج التعليمي نظامًا قائمًا على Debian.بينما تعمل Nginx و CertBot على توزيعات أخرى ، قد تختلف عملية الإعداد.
• الوصول إلى الجذر أو Sudo: ستقوم بتثبيت الحزم ، وتحرير ملفات النظام ، وإعادة تشغيل الخدمات - وكلها تتطلب امتيازات مرتفعة.
• اسم مجال مسجل: ستحتاج إلى هذا لطلب شهادة SSL.دعنا نتشفير صحة ملكية مجالك قبل إصدار شهادة.بدون DNS أشار إلى الخادم الخاص بك ، سيفشل التحقق من الصحة.
• DNS تشير إلى IP الخاص بالخادم الخاص بك: تأكد من تحديث سجلات DNS لمجالك.سجل بسيط يشير إلى IP الخاص بالخادم الخاص بك يكفي:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

يمكن أن يستغرق الانتشار بضع دقائق إلى بضع ساعات.

لا تعرف كيفية تكوين DNS الخاص بك؟هنا كيفية إضافة سجل مع معظم المضيفين المجال.

• تطبيق يعمل على مضيف محلي (على سبيل المثال ، http://localhost:3000): هذا هو التطبيق الذي ستحققه.يمكن أن يكون أي شيء - Node.js ، قارورة Python ، Ruby on Rails ، إلخ. طالما أنها تستمع على منفذ محلي ، يمكنك وكيله.

ملحوظة: إذا لم يكن تطبيقك قيد التشغيل بعد ، فلا بأس - لا يزال بإمكانك المرور عبر الإعداد والاختبار لاحقًا.

• Nginx مثبت: ستعمل Nginx كخادم مواجه للجمهور.إذا لم يتم تثبيته بعد:

sudo apt update
sudo apt install nginx

ثم تحقق من أنه يعمل:

sudo systemctl status nginx

يجب أن ترى "نشط (تشغيل)."

• Certbot مثبتة مع المكون الإضافي Nginx: تقوم CertBot بأتمتة عملية الحصول على شهادات SSL وتجديدها من Let's Encrypt.تثبيته مثل هذا:

sudo apt install certbot python3-certbot-nginx

يتيح هذا المكون الإضافي لـ CERTBOT تعديل تكوين NGINX تلقائيًا عند طلب شهادة - لا يوجد أي تحرير يدوي مطلوب للإعدادات الأساسية.

هل لديك نظام تشغيل آخر؟اتبع هذا الدليل على كيفية التثبيت دعنا نشفير في فيدورا وديبيان

الخطوة 1: إعداد الوكيل العكسي Nginx

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

لماذا هذا يهم

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

• أي مجال (نطاق) يجب أن يستجيب إليه
  
• ماذا تفعل بالطلبات الواردة
  
• أين ترسل حركة المرور وراء الكواليس

إنشاء كتلة خادم جديدة

ستقوم بإنشاء ملف تكوين لنطاقك في دليل مواقع Nginx المتوفر.هذا يبقي التكوينات منظمة ويجعل من السهل تمكين أو تعطيل المواقع الفردية.

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

الصق في الكتلة التالية ، وضبط منفذ المجال والتطبيق حسب الحاجة:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

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

        # Pass important headers to the backend
        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;
    }
}

ماذا يفعل هذا التكوين

• استمع 80 ؛
  يطلب من Nginx الاستماع لحركة HTTP على المنفذ 80.
  
• server_name yourdomain.com www.yourdomain.com ؛
  تطابق هذه الكتلة مع الطلبات المقدمة إلى مجالك.يمكنك إضافة أو إزالة نطاقات فرعية حسب الحاجة.
  
• موقع /
  يمسك جميع طلبات الجذر وإعادة توجيهها إلى تطبيقك.
  
• proxy_pass http: // localhost: 3000 ؛
  هذا هو قلب الوكيل العكسي - يرسل الطلب إلى تطبيق الواجهة الخلفية التي تعمل على المنفذ 3000.
  
• خطوط proxy_set_header
  هذه التفاصيل المحفوظة من طلب العميل الأصلي ، مثل:
  
  • عنوان IP للمستخدم (X-REAL-IP)
    
  • البروتوكول الأصلي (HTTP أو HTTPS)
    
  • اسم المضيف الأصلي
    
• هذه المعلومات مفيدة لتسجيل التسجيل أو التحليلات أو عندما يحتاج تطبيقك إلى إنشاء عناوين URL التي تتطابق مع تجربة الزائر.

تمكين التكوين

يستخدم Nginx روابط رمزية في مواقع تدعم دليل لتفعيل المواقع.حتى الآن ستقوم بإنشاء رابط وإعادة تحميل nginx:

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

تحقق من وجود أخطاء بناء الجملة.إذا كان كل شيء يبدو جيدًا:

sudo systemctl reload nginx

إن الوكيل العكسي الخاص بك يعيش الآن - طلبات إلى http://yourdomain.com سيتم تمريرها إلى تطبيقك على المنفذ 3000.

الخطوة 2: أضف SSL مع Let's Encrypt و certbot

مع عمل الوكيل العكسي على HTTP ، فإن الخطوة التالية هي تأمينه باستخدام HTTPS.يضيف هذا التشفير إلى جميع الاتصالات بين المستخدمين والخادم الخاص بك - حماية بيانات اعتماد تسجيل الدخول وطلبات API والبيانات الشخصية والمزيد.

ستستخدم Let's Encrypt ، وهي سلطة شهادة مجانية ، و CertBot ، والتي تعمل على أتمتة العملية.

لماذا HTTPS مهم

• تشفير حركة المرور لذلك لا يمكن لأحد الاعتراض أو العبث به
  
• يحسن تحسين محركات البحث - تفضل محركات البحث المواقع الآمنة
  
• يبني الثقة - يتوقع المستخدمون رؤية أيقونة القفل
  
• مطلوب للعديد من واجهات برمجة التطبيقات والتسجيلات وأنظمة الدفع

اطلب الشهادة

قم بتشغيل هذا الأمر ، واستبدال المجالات بقيمك الفعلية:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

ماذا يفعل هذا:

• يخبر Certbot باستخدام البرنامج المساعد Nginx
  
• يحدد المجالات التي تطلبها شهادة

سوف certbot:

• قم بإجراء التحقق من صحة المجال عن طريق إنشاء ملف مؤقت في تكوين Nginx الخاص بك
  
• الاتصال دعنا نشفير للتحقق من ملكية المجال
  
• قم بتنزيل شهادة SSL والمفتاح الخاص
  
• قم بتعديل تكوين Nginx لاستخدام HTTPS
  
• إعادة توجيه جميع حركة مرور HTTP اختياريا إلى https

نصيحة: إذا لم يتم نشر DNS الخاص بك بالكامل أو يحظر جدار حماية الخادم المنفذ 80 ، فسوف يفشل التحقق من الصحة.يمكنك اختبار هذا مع:

curl -I http://yourdomain.com

لفهم المنافذ بشكل أفضل ، تحقق من دليلنا كيف تعمل منافذ خادم الويب.

تحقق من التغييرات

بعد اكتمال Certbot ، يجب أن يتضمن تكوين NGINX شيئًا كهذا:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

يجب أن تكون قادرًا الآن على زيارة https://yourdomain.com ومشاهدة موقعك مع شهادة SSL صالحة.

اختياري: قوة https

إذا لم تقم باختيار خيار إعادة التوجيه أثناء إعداد CertBot ، فيمكنك إضافة هذا يدويًا:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

هذا يجبر جميع حركة مرور HTTP على إعادة توجيهها إلى HTTPS ، مما يضمن عدم استخدام المستخدمين بطريق الخطأ الإصدار غير الآمن من موقعك.

الخطوة 3: تحسين إعدادات SSL (موصى بها للإنتاج)

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

إليك مثال محسن:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

ماذا تفعل هذه الإعدادات

• ssl_protocols TLSv1.2 TLSv1.3
  يعطل بروتوكولات أقدم وأقل أمانًا مثل TLS 1.0 و 1.1.
  
• ssl_prefer_server_ciphers on
  دع الخادم الخاص بك يقرر خوارزمية التشفير ، بدلاً من التأجيل إلى المتصفح - والتي يمكن أن تقلل من التعرض لهجمات الشفرات الضعيفة.
  
• SSL_Ciphers عالية:! anull:! md5
  يحدد أجنحة تشفير قوية ويستبعد تلك الضعيفة أو المكسورة (مثل MD5 والأصفار الفارغة).
  
• ssl_session_cache و ssl_session_timeout
  التحكم في إعادة استخدام جلسة SSL ، والتي يمكن أن تحسن الأداء قليلاً دون المساس بالأمان.
  
• ssl_session_tickets قبالة
  يعطل تذاكر الجلسة ، والتي يمكن أن تكون مصدر قلق أمني إذا لم يتم تدويرها بانتظام.

تعمل هذه التغييرات على تحسين درجة أمن SSL الخاصة بك وحماية الزوار من هجمات التصنيف أو خيارات التشفير غير الآمنة.

اختياري: يمكنك اختبار موقعك باستخدام مختبرات SSL لمعرفة كيفية أداء التكوين الخاص بك والحصول على اقتراحات تحسين محددة.

الخطوة 4: (اختياري) إضافة معلمات Diffie-Hellman

بالنسبة للتشفير الأقوى ، يمكنك إنشاء مفتاح Diffie-Hellman (DH) المخصص.هذه الخطوة اختيارية ، ولكن غالبًا ما يوصى بها لبيئات الإنتاج.

قم بتشغيل هذا الأمر لإنشاء مجموعة DH 2048 بت:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

ثم أضف السطر التالي إلى كتلة خادم SSL الخاصة بك:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

لماذا تضيف هذا؟

معلمات Diffie-Hellman تعزز السرية إلى الأمام، وهذا يعني حتى لو تعرض مفتاحك الخاص للخطر بطريقة ما في المستقبل ، فستظل الجلسات المشفرة السابقة آمنة.

يستغرق الأمر بضع دقائق لإنشاء مجموعة DH ، لكنها خطوة لمرة واحدة وتستحق القيام بها لتحسين وضعية أمان.

الخطوة 5: إعداد تجديد تلقائي لشهادات SSL

لننتهي من تشفير الشهادات كل 90 يومًا.لحسن الحظ ، يقوم Certbot بتثبيت مؤقت النظام الذي يتحقق مرتين في اليوم للشهادات بسبب انتهاء صلاحيتها وتجديدها تلقائيًا.

يمكنك تأكيد أن المؤقت نشط مع:

sudo systemctl list-timers | grep certbot

يجب أن ترى شيئًا كهذا:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

لاختبار عملية التجديد يدويًا (دون إجراء تغييرات) ، قم بتشغيل:

sudo certbot renew --dry-run

هذا يحاكي عملية التجديد الكاملة ويؤكد أن نظامك جاهز للتعامل معها تلقائيًا.

إذا لم تكن هناك أخطاء ، فسيتم تجديد شهاداتك بهدوء في الخلفية للمضي قدمًا.

الخطوات النهائية والعادات الجيدة

الآن بعد أن تم إعداد الوكيل العكسي الخاص بك وتأمينه مع SSL ، من الجيد أن تختتم ببعض الشيكات العملية وأفضل الممارسات.

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

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

أعد تشغيل التطبيق الخاص بك إذا لم يكتشف التغييرات تلقائيًا
يجب إعادة تشغيل بعض التطبيقات للعمل بشكل صحيح وراء الوكيل.

تحقق من السجلات
يمكنك مراقبة سجلات NGINX للأخطاء أو حركة المرور غير العادية:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

الحفاظ على تحديث nginx و certbot
استخدم Sudo Apt Update && Sudo Apt الترقية بانتظام.تحدد الحزم المحدثة الأخطاء ، وتحسين التوافق ، وقضايا أمان التصحيح.

حالات الاستخدام المتقدمة للوكيل العكسي Nginx مع SSL

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

استضافة تطبيقات متعددة على خادم واحد

إذا قمت بتشغيل العديد من تطبيقات الويب على منافذ مختلفة ، يمكن لـ NGINX توجيه الطلبات إلى كل تطبيق استنادًا إلى مسار المجال أو عنوان URL.

مثال: مجالات مختلفة

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

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

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

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

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

باستخدام Docker؟يتعلم كيفية وكيل تطبيقات Docker متعددة مع Nginx.

وكيل القائم على المسار

بدلاً من ذلك ، يمكنك الوكيل بناءً على مسارات URL ، وهو أمر مفيد إذا كنت تريد جميع التطبيقات تحت مجال واحد:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

ملحوظة: عند استخدام وكيل البرامج القائمة على المسار ، يمكن أن تصبح القطع المقطوعة وإعادة كتابة عنوان URL صعبة-تأكد من أن تطبيق الواجهة الخلفية لديك يمكن أن يتم تقديمه تحت المسار الفرعي.

إضافة الحد من معدل لحماية تطبيقك

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

أضف هذا في كتلة http في /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

ثم في خادمك أو كتلة الموقع:

limit_req zone=mylimit burst=20 nodelay;

يتيح هذا التكوين 10 طلبات في الثانية مع رشقات نارية تصل إلى 20 طلبًا ، مما يؤدي إلى إسقاط الطلبات الزائدة لتجنب غمر تطبيقك.

تحميل الموازنة عبر خوادم خلفية متعددة

إذا كان لديك عدة مثيلات لتطبيقك يعمل (على سبيل المثال ، حاويات متعددة أو VPSS) ، يمكن لـ NGINX توزيع حركة المرور بينها:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

يطلب Nginx Radics Round-Robin افتراضيًا ، ولكن يمكنك تكوينه لطرق أخرى مثل الأقل اتصالات أو تجزئة IP.

لمعرفة المزيد ، تحقق من دليلنا DNS تحميل موازنة.

قطع الأشجار والتصحيح

يمكنك تخصيص التسجيل لتضمين معلومات الوكيل المهمة لاستكشاف الأخطاء وإصلاحها أو التحليلات:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

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

الرؤوس المخصصة وتحسينات الأمن

قد ترغب في إضافة أو تعديل رؤوس HTTP للأمان أو الوظائف:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

هذه الرؤوس تحمي من النقرات ، والاستنشاق MIME ، وفرض استخدام HTTPS.