Home Knowledge base Skyline Cloud كيفية إعداد Nginx كوكيل عكسي (Reverse Proxy) KNOWLEDGE BASE

كيفية إعداد Nginx كوكيل عكسي (Reverse Proxy)

دليل كامل ودقيق لتهيئة Nginx كوكيل عكسي على خادم لينكس — ترويسات الوكيل وWebSockets وHTTPS وموازنة الحِمل والتخزين المؤقت، مع تهيئة جاهزة للإنتاج يمكنك نسخها.

ما الذي يفعله الوكيل العكسي

يقع الوكيل العكسي (Reverse Proxy) أمام تطبيق خلفي واحد أو أكثر ويُمرّر طلبات العملاء إليها. فبدلًا من تعريض خادم تطبيقك (Node.js أو Python أو PHP-FPM أو حاوية Docker) مباشرةً للإنترنت، يتواصل العملاء مع Nginx، ويتواصل Nginx مع تطبيقك عبر عنوان خاص.

يمنحك ذلك نقطة دخول عامة واحدة يمكنك عندها إنهاء تشفير TLS، وموازنة الحركة عبر عدة خوادم خلفية، وتخزين الاستجابات مؤقتًا، وفرض حدود المعدل، وإخفاء البنية الداخلية. وهو النمط القياسي لتطبيقات الويب الإنتاجية — ويتكامل بطبيعته مع خادم VPS أو خادم سحابي من Skyline Cloud، حيث تبقى بياناتك داخل المملكة بما يتوافق مع نظام حماية البيانات الشخصية (PDPL) والهيئة الوطنية للأمن السيبراني (NCA).

يستخدم هذا الدليل مسارات Ubuntu/Debian، لكن كل توجيه ينطبق بشكل مطابق على أنظمة عائلة RHEL.

المتطلبات المسبقة

  • خادم لينكس مع صلاحية sudo (يصلح خادم VPS أو السحابي من Skyline Cloud لذلك جيدًا).
  • تطبيق خلفي يعمل بالفعل ويستمع محليًا — على سبيل المثال على 127.0.0.1:3000.
  • نطاق (مثل نطاق .sa) مع سجل A يشير إلى عنوان IP العام لخادمك.

الخطوة 1 — تثبيت Nginx

sudo apt update
sudo apt install nginx -y

تأكد من أنه يعمل ومُمكّن عند الإقلاع:

sudo systemctl status nginx
sudo systemctl enable nginx

افتح الجدار الناري إذا كنت تستخدم UFW:

sudo ufw allow 'Nginx Full'

الخطوة 2 — إنشاء كتلة خادم الوكيل العكسي

يُحمّل Nginx أي ملف ينتهي بـ .conf من /etc/nginx/conf.d/، وعلى Debian/Ubuntu يقرأ أيضًا من /etc/nginx/sites-enabled/. أنشئ ملفًا مخصصًا حتى لا تمسّ الملف الافتراضي:

sudo nano /etc/nginx/conf.d/app.conf

أضف ما يلي، مع استبدال app.example.com وعنوان الخادم الخلفي بقيمك الخاصة:

server {
    listen 80;
    listen [::]:80;
    server_name app.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_connect_timeout 60s;
        proxy_send_timeout    60s;
        proxy_read_timeout    60s;
    }
}

لماذا تهمّ كل ترويسة

التوجيه الغرض
proxy_pass عنوان الخادم الخلفي الذي يُمرّر إليه Nginx. غياب الشرطة المائلة الأخيرة هنا يُبقي مسار URI الأصلي.
Host يُمرّر اسم المضيف الأصلي حتى يولّد التطبيق روابط صحيحة ويوجّه حسب النطاق.
X-Real-IP عنوان IP الحقيقي للعميل، والذي كان الوكيل ليُخفيه لولا ذلك.
X-Forwarded-For يُلحق كل قفزة وكيل حتى يرى التطبيق سلسلة العميل الكاملة.
X-Forwarded-Proto يُخبر التطبيق بما إذا كان الطلب الأصلي http أم https — وهو أساسي بمجرد إضافة TLS.

الخطوة 3 — الاختبار وإعادة التحميل

تحقّق دائمًا من صحة التهيئة قبل تطبيقها. يلتقط هذا أخطاء الصياغة قبل أن تُعطّل موقعك:

sudo nginx -t

يُفترض أن ترى syntax is ok وtest is successful. ثم أعد التحميل — يقرأ reload التهيئة من جديد بسلاسة مع انقطاع شبه معدوم، بعكس restart:

sudo systemctl reload nginx

زُر http://app.example.com ويُفترض أن ترى تطبيقك الخلفي مُقدَّمًا عبر Nginx.

الخطوة 4 — دعم WebSockets

إذا كان تطبيقك يستخدم WebSockets (دردشة أو لوحات معلومات حية أو خوادم تطوير)، فيجب أن تُمرّر ترويستَي Upgrade وConnection، وإلا فسيفشل الاتصال في تبديل البروتوكول. أضف هذه داخل نفس كتلة location:

        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";

سطر proxy_http_version 1.1; من الخطوة 2 مطلوب حتى يعمل هذا.

الخطوة 5 — إضافة HTTPS بشهادة مجانية

أنهِ تشفير TLS عند Nginx حتى لا يتعامل الخادم الخلفي إلا مع HTTP عادي داخليًا. ثبّت Certbot ودعه يهيّئ SSL تلقائيًا:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d app.example.com

يُعدّل Certbot كتلة الخادم لديك، ويُضيف خادم listen 443 ssl، ويُعدّ مؤقّت تجديد تلقائيًا. تحقّق من نجاح التجديد بتشغيل تجريبي:

sudo certbot renew --dry-run

لتفعيل HTTP/2، غيّر سطر الاستماع في كتلة SSL إلى الصيغة المتوافقة عبر الإصدارات:

    listen 443 ssl http2;

استخدم listen 443 ssl http2; بدلًا من التوجيه المنفصل http2 on; — فالصيغة المدمجة تعمل على جميع إصدارات Nginx الحالية.

الخطوة 6 — موازنة الحِمل عبر عدة خوادم خلفية

لتوزيع الحركة على عدة نسخ من التطبيق، عرّف مجموعة upstream ووجّه الوكيل إليها بالاسم. ضع كتلة upstream في أعلى الملف، خارج server:

upstream backend_pool {
    least_conn;
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002 backup;
    keepalive 32;
}

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

    location / {
        proxy_pass http://backend_pool;
        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_set_header Connection        "";
    }
}
  • يُرسل least_conn كل طلب إلى الخادم الخلفي ذي الاتصالات النشطة الأقل. الافتراضي (بدون توجيه) هو التناوب الدوري (round-robin).
  • يُعلّم backup خادمًا يُستخدم فقط عند تعطّل الخوادم الأخرى.
  • يُعيد keepalive 32 استخدام اتصالات الخادم الخلفي. عند استخدامه، اضبط proxy_set_header Connection ""; لتجنّب إغلاقها مع كل طلب.

الخطوة 7 — تخزين استجابات الخادم الخلفي مؤقتًا (اختياري)

يُقلّل التخزين المؤقت الحِمل على تطبيقك للمحتوى الذي لا يتغيّر حسب المستخدم. عرّف مخزن الذاكرة المؤقتة في سياق http (مثلًا في /etc/nginx/nginx.conf):

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

ثم أشِر إليه داخل كتلة location:

        proxy_cache       app_cache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        add_header X-Cache-Status $upstream_cache_status;

تُبلّغ ترويسة الاستجابة X-Cache-Status بقيمة HIT أو MISS أو BYPASS، حتى تتمكّن من تأكيد التخزين المؤقت من تبويب الشبكة في متصفحك.

استكشاف الأخطاء وإصلاحها

  • 502 Bad Gateway — الخادم الخلفي غير قابل للوصول. تأكّد من أنه يستمع باستخدام ss -tlnp | grep 3000 وأن العنوان في proxy_pass مطابق.
  • 504 Gateway Timeout — خادم خلفي بطيء؛ ارفع قيمة proxy_read_timeout.
  • يولّد التطبيق روابط http:// خلف HTTPS — تأكّد من ضبط X-Forwarded-Proto $scheme وأن تطبيقك يثق بها.
  • راجع السجلّات: sudo tail -f /var/log/nginx/error.log.

الخلاصة

أصبح لديك الآن وكيل عكسي بمستوى إنتاجي: إنهاء TLS، وترويسات عميل صحيحة، ودعم WebSocket، وموازنة حِمل، وتخزين مؤقت اختياري. شغّله قريبًا من مستخدميك ومن بياناتك — تستضيف Skyline Cloud كل شيء داخل المملكة بما يتوافق مع PDPL/NCA، مع دعم عربي محلي وتسعير شفّاف. اقرن هذا الوكيل مع استضافة البريد الإلكتروني للأعمال المُدارة لدينا للحصول على حزمة متكاملة، واستكشف المزيد من الأدلة في مركز استضافة الويب السعودي.

جاهز للنشر؟ أنشئ حساب Skyline Cloud وشغّل خادم VPS خلال دقائق.

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

See author profile
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Skyline Cloud for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.